Stephan Ewen: Let’s say you’re recording the episodes and then every time an episode is done – no, let’s do an AI thing here, or so.

So you’re building your chat where you can chat with an episode, like “Okay, tell me where did they talk about this”, or “Tell me what episodes talked about these topics”, and so on. So what you’re doing whenever an episode is done - you’re feeding it first through a model that transcribes the audio, then you’re chunking it up, feed it through embeddings models stored maybe in a vector database, and then you have kind of a RAG style way of… You know, when a query comes, create the embedding, look up the similarity search in your vector database, feed it to the model to get the answer… For something like this, if you – let’s say you started just building the flow in let’s say a Node.js application, like in a simpler way; you just said “Okay, here’s the episode.” I have something, it gets uploaded… Let’s say you’re uploading it to an S3 bucket and there’s an event whenever something gets uploaded to this bucket; you have an event that represents this, and then it starts a Node.js script, or something like this. And this script is of the type that if it fails, somebody would have to restart it. Now let’s say you’re trying to implement that with Restate. I would say approach it the following way… The first thing is get a handle of Restate itself; there’s a cloud service that you can use on our site, which has a free tier. Either go there, or just use one of these ways to run it yourself on a single machine with an EBS volume.

[01:22:06.14] Then you have the server there. Then put your Node.js script maybe – you can actually put it on something like Lambda or ECS; just like use a serverless option to host this. And then use the Restate SDK to define the entrypoint and tell Restate “Okay, hey, here’s the service that you now should durably manage.” So Restate will then go there and discover this and understand “Okay, hey, there’s this (what what do we call it?) video transcriber, or video embedder service.” And then Restate knows about this. And then you would go to your Amazon console and say “Okay, for this type of event I want to create a webhook to Restate”, so that it makes an invocation to Restate and says “Okay, this thing has been updated.” You know, the kind of event that would previously call directly your Node.js process or script, you actually make it an HTTP call to Restate, and Restate would then call your process.

You’ve already gained one thing right away. You now basically have a reliable queue in front of it, right? Like, just that if you don’t do anything special. So when the webhook comes, it’s going to be acknowledged back, and Restate has this [unintelligible 01:23:15.22] of your process if it crashes, it will retry this… It will actually give you a nice observability; much more than you would get from your average message queue, about like individual retries, configuration about time-offs and back-offs and timelines and so on.

As a next step, you would actually then go into your script and say “Okay, let’s actually identify the steps where if something fails in this step, or after that step, I don’t want it to go back.” Like let’s say forking the process that does the transcribing, or like calling the LLM to create the embeddings. You introduce then the Restate context that you get by using the Restate SDK and just say, “Okay let me wrap these API calls just with restate.run.” That will capture the results of this durably, and basically turn – you’ve now turned it basically into a workflow.

Let’s say you want to do something like parallelize the different steps. Maybe just typing this one by one through this embeddings model is a little tricky thing… You want to fan out. You could then go and say “Let me try and do the exact same thing I do in a regular Node process and just make a bunch of function calls record, like remember the promises”, sort of a way to promise that all for those in the end join the results, and put those in the database. You can do exactly that in your code. Just, again, anchor this in the Restate context, so you get like this durable parallelization, durable stuff like scatter, gather, and so on. And so you would then incrementally sort rewrite your code to say “Okay, let’s actually make this step durable, let’s make that step durable, and that step durable.”

Say as a next thing maybe one of your folks wants to approve it before it really goes out. So you then possibly – you “Let’s do that in the simplest most possible way”, which is we create an awakeable or a durable promise in Restate and say “Okay, somebody needs to complete this actively”, like send an event, make an HTTP caller to complete this and say “Okay, this is approved, go through” or “No, this is not approved. Abort.” You can then use, for example – you could put the result, the transcription just in Restate, save it, and somebody could look at it from the UI and then say “Okay, yeah, I’m making an API call here to approve this”, and it continues. And so you can then incrementally rebuild your process into durable steps.

As the next thing you could then, for example, take it and migrate it from a long-running process to a Lambda function. Because one of the nice things you have with durable execution is when it’s waiting for something else to happen, it can actually just make this thing go away. Because with durable execution, it knows how to recover back to the place where it was by replaying the history of durable steps.

[01:26:14.28] So you could then say – you know, if you’re on vacation and you approve it a week later, you don’t have some process running and waiting for it. It’s just like, it’s going to go away, and when the approval finally comes, it’s going to come back, use the durable steps to replay back to the point, and then to the remaining steps. And so typically, folks would incrementally then rework their non-durable services; first connect them to Restate to basically get the equivalent of a durable queue, and then incrementally rework it and say “Okay, I want to add durable steps here, maybe parallelization, maybe a signal”, and…

Shay Banon: I’ll start with saying that that’s probably the hardest decision that I’ve ever made at Elastic. So that was a really tough decision. And like any tough decisions, you don’t come to it lightly. You understand the implications, you understand the impact… Also, just on a personal level, open source has been a big part of my life. I was trying to calculate back how many hours I worked on open source while I had another job, and I think since 2004 or 2005 I’ve been basically working like 30 to 40 hours a week, just on open source. Whether I had a job or not. When I didn’t have a job, I would work more. And that’s a lot, and I do it because I love it, I do it because I cherish it, I love the community aspect, I love the engagement, I love building software that is accessible by so many users… And – yeah, I love it.

So that was a really tough decision. And also, it took time to get to it, because you always hope that somehow you won’t have to do it. And hopefully, I don’t know, Amazon will change the name of Amazon Elasticsearch, or somehow we’ll manage to work some sort of like an agreement with Amazon, or something along those lines. But when it gets to a point where so many users just confuse, either because they think you work with Amazon, either because they think that Amazon Elasticsearch is Elasticsearch, or your cloud service, or something along those lines, that we felt like we had to just go and change the license so it will force a change of name and a clear distinction between the two products that was not there. I wish that we didn’t have to do it. I wish that there would have been another way to solve it, and I know a lot of people have a lot of ideas on Twitter on how this could have been solved…

Steven Wu: Yeah. Well, this isn’t exactly a direct answer to your question, but our product is extremely cheap compared to pretty much any other product in the space. I feel like throwing out numbers feels really salesy, but the normal actual charge we see tends to be a literal order of magnitude lower than stuff like Splunk Cloud, which is like a comparable cloud service in terms of functionality.

[00:16:05.09] We see people with cost as a concern, but at least for the kinds of companies that we talk to, none of them really feel that it’s realistic for them to move completely off the cloud. And these tend to be – because our main use case is actually security, our product is marketed as a SIEM, which is like a Security Information Event Management system. And the smallest company that has like a security team of five people is like a billion-dollar company, so that’s like the smallest company that we work with. And for those companies, I think, once they have infrastructure, the inertia and the size of what you have just means that you’re – you can’t move off the cloud so much as you’re just trying to cut cloud costs. So I think what we build fits really nicely into that narrative, because it’s like a cloud service that kind of works alongside and takes advantage of everything available to you in that environment, but it also doesn’t break the bank like pretty much every other logging service does.

Adam Stacoviak: Yeah. This is where I like Warp. I don’t know if it has this feature, because I do use a few machines, but so sparingly that I forget what I’ve done the last time I used it. And so Warp, at least on a single machine - I think you would appreciate this, Jerod, and I know you already use Atuin - is that it does that. So I’m just tinkering on this spare Linux VM I have on Proxmox, because hey, I’m on a podcast talking about TUIs, so I’m gonna install some right. And I want to do it in a way where I can just blow it away, and there you go.

And so I’m logged in and I’m just like “Well, what are some recent commands, just to see if they’re there?” …because I know they’re there. I know how Warp works, but just to see if they’ve actually followed me, even into this different machine… And of course, they’re there. So I have that same feature because of the terminal application I’ve chosen, versus this sub-thing… And I think the one thing that I think Warp is driving towards - and this is zero an ad. They’re not even sponsoring us. I just like them, and Zach’s cool, and I like his team… And I believe it is a version of the terminal the future. There you go.

[00:41:42.07] I think that they’re doing things like team features, which I think would be cool because you can log into Warp and let those things transfer via their cloud service, if they do that. I think that’s what they’re driving towards. I wish they would do that more so as settings, because going between machines - it doesn’t have that. Whereas another tool I use daily is Raycast, and it has that where it cloud-syncs settings. It doesn’t cloud-sync clipboard history and sensitive things. It’s doing things that – like themes, and stuff you really want to have unified between machines. That’s kind of how I look at these tools… Like, even though we’re talking about TUIs, I still feel like Raycast and Warp are kind of similar in that respect, because they’re a layer above the need for a TUI because the application itself has the things in it it needs to give you that history.

There’s other stuff too I’m not even using, like expansions, and snippets… Things I’m not even like – I don’t know, I don’t even know how to use them, honestly. I think some of the tooling –

Ron Evans: Like, nobody’s going like “Oh yeah, we sold Python.” No, it’s like “Yeah, we made this thing with Python, and we sold it for a bunch of money, and…” Well, Python’s really cool. I mean, pick a language: Go, Rust… Any language. The money is not there. The value creation is. It’s creating enormous value. I mean, probably it’s the most… I mean, I will take a giant leap and say the single most valuable asset on Earth, which is consistently undervalued, is the collective all of open source. Like, how much is that worth? It is worth a lot. I know there was a study some university did, trying to figure out “Okay, if there was no open source, how much would it cost to write it all?” It was like a bunch of trillions. Not to mention like “Okay, we’d better get started, because we’ve got – okay, we’ve got a $3 trillion budget, but how are we going to spend it? Like, it took years. It’s not like we’re gonna like “Okay, we know exactly what to do now.” Right? So it’s an emergent phenomenon.

So that does not mean that there’s not ways to do it. But I think it’s not – like, a project which is clearly part of core infrastructure for a bunch of companies is that they’re not planning on selling the cloud-enabled version of themselves in order to make money… Because that’s a lot of – oh, yeah, it’s this cool server that does some thing. You can work on it, and you can stand it up yourself… Or you can use our cloud service. And then the next week somebody’s like “Oh yeah, we could stand up a cloud service.” And they already told people like “Wait, no, not like that…!”

Danny Avila: [00:25:36.00] Yeah, absolutely. Back to the data ownership, I just think it’s absolutely crucial to have built some kind of pipeline for evaluation as well, especially if you’re really into fine-tuning your own models. And really, it’s crazy to think about, but even the data that we have just casually with these large language models, and if they’re a very capable model, it’s almost like a goldmine for the next model. And just having your own ownership, not just some cloud service… I definitely want to start it off simple, being able to thumbs up, thumbs down, but then being able to integrate complex evaluation tools like you guys already have with the toxicity score, or the translation rating… I think that’s awesome.

Jerod Santo: Redis adopts dual source-available licensing

Another open source project bites the dust. Here’s their explainer:

The success of Redis has created a unique set of challenges. Redis has been sponsoring the bulk of development alongside a dynamic community of developers eager to contribute. However, the majority of Redis’ commercial sales are channeled through the largest cloud service providers, who commoditize Redis’ investments and its open source community. Despite efforts to support a community-led governance model, and our desire to maintain the BSD license, delivering multiple software distributions simultaneously – across open source, source-available, and commercial software optimized for different on-premises and cloud platforms – is at odds with our ability to drive Redis successfully into the future.

When this news first dropped last Wednesday, I quipped: Gentlemen, start your forks. Drew DeVault must’ve been listening. (Probably not literally, but in spirit.) Enter Redict. Drew writes:

Like many of you, I was disappointed when I learned that Redis®1 was changing to a non-free licensing model. This is a betrayal of the free software community, but perhaps not an entirely surprising one. Forks are likely to start appearing in the coming days, and today, I would like to offer Redict to you as a possible future home for your needs, and present its trade-offs as compared to the other forks you’re likely to be choosing from soon.

In short, Redict is an independent, non-commercial fork of Redis® OSS 7.2.4.2 It is based on the BSD 3-Clause source code of Redis® OSS, and all changes from this point onwards are licensed under the Lesser GNU General Public license, LGPL-3.0-only.

Oh, and Microsoft also announced Garnet (a Redis client compatible cache-store) just two days prior to the Redis re-licensing. Fortuitous timing or did they know something?

Rahul Nair: Sure. So Intel Developer Cloud is Intel’s production-ready cloud specifically for AI and machine learning workloads. And of course, when we say AI and machine learning, it’s [unintelligible 00:19:22.01] so many other compute-heavy workloads can run really well on IDC.

So for this particular hack, we provided anyone logging into Intel Developer Cloud registering on IDC as a standard or free tier user - you get a shared Jupyter Hub instance, where you get access to Intel’s data center GPUs, Intel Xeon processors. And I would say this system, for a free tier user, I don’t think any other service provides. I mean, there are many services with a Jupyter Hub frontend, but the amount of compute and the amount of memory and RAM and even file storage that you get in the systems, I’m not seeing a single cloud service provider providing that. And we have seen a lot of people really using it, and giving us feedback on how we could even improve it.

Today on IDC we have a lot of models or LLMs already, and other tens or even hundreds of local models that we are planning to add further to boost this, that are Stable Diffusion models, LLM models, and things like that. Beyond that, for productionizing the workload - Dan, in your case, you’re using the Gaudi 2 accelerators. Those are specifically designed for workloads that request high bandwidth, like LLM and GenAI workloads, and this… I lost my train of thought, but yeah. We have Gaudi 2 accelerators, which we are seeing incredibly competitive, and sometimes outclassing the best out there for your particular workloads.

Along with Gaudi accelerators - those are specifically designed for GenAI and AI workloads - we have general-purpose GPUs, the data center [unintelligible 00:21:01.09] both with 48 gigs and 128-gig versions. So folks in the hackathon, they actually used both our fourth generation Xeon; that is the latest Xeons that we have, which - what it particularly does is that it accelerates your machine learning workloads. We have dedicated instructions in the CPU to sometimes even take your workload to 2x the performance that you got in an earlier generation.

It’s all about making the CPU as efficient as possible, and making it as fast as possible, and still maintaining the general purpose utility of a CPU. But then, like I said, the data center [unintelligible 00:21:42.08] a little bit more generic solution, where you can run your AI workload, [unintelligible 00:21:48.06] HPC workloads. Each of these machines, when you’re productionizing, you get a VM, you get an 8-node [unintelligible 00:21:56.22] system that also clusters the systems available. Then comes the Gaudi accelerators, both – there are single-node machines, and also clustered machines if you want to do pretraining or big fine-tuning. All those cool things. And soon, we’ll have Kubernetes service, object store, file store, all those things coming up… So it’s gonna be great.

[00:22:17.29] What I see is that if you’re building a startup, it would be very difficult to find a performant accelerator cloud like IDC out there. I’m sure that there are different hyperscalers… But this, uniquely for startups, from my personal experience, is a really, really awesome solution.

I’d like to know more from you, Dan. You are one of the first customers of IDC, right? What are the things that you thought that really made you decide to choose IDC, for the performance, and also the team side also?

Solomon Hykes: Honestly, I don’t know, because I don’t understand what the boundaries of open core are. But I guess roughly yes. I would say yes. I mean, the engine is open source, the SDKs are open source, the CLI is open source… So you have everything you need to develop and run these pipelines. You can daggerize to your heart’s content. 100% open source. What happens is then when you run these pipelines in a CI environment, usually it’s a bunch of machines in a data center somewhere, and then you need a control plane, because you have a bunch of engines running pipelines in parallel; you need to coordinate, you need to monitor them, they need to share cache… Caching is a huge part of what makes Dagger great because everything’s cached by default. It’s a property of the dagg.

So everything becomes way faster, very quickly, compared to old-school pipelines. But there’s a data sharing element, so you need to coordinate that, the distribution of the cached data. And then you just want a place to see what’s going on, visualize on the web interface your dagg, and then troubleshoot, collaborate, things like that. So all that is in this commercial product that we’re building. We started rolling it out in the early access, but it’s not launched yet. But it’s a pretty natural line. Basically, it’s purely product design-driven. For any given feature, we just ask “What’s the best user experience? Where does it make sense to put there? Should it be in an individual engine, running on an individual machine? Or should it be a globally shared cloud service?” Like literally, how does it work better? And whatever the answer is, that’s where it goes, and that’s it.

So there’s really, so far - fingers crossed - it’s pretty aligned, and I think… Yeah, we’ll see where it goes from there. The test will be one day we’ll be big enough that a big company will come in and say, “I want to sell my own Dagger control plane, and here’s a pull request to add a plugin support, so that everyone can swap out their control plane. And you better merge it, or I’m going to blog about you and say you’re mean”, and we’re going to say “Thank you for your pull request, but it’s denied. And you’re free to fork, but call it something else.” So we have a very open copyright stance; it’s like a very open license, a real open source license… But we have a very strict trademark policy. By the way, that’s the Red Hat model.

Jerod Santo: OpenObserve is a cloud native observability platform built specifically for logs, metrics, traces and analytics designed to work at petabyte scale. According to its creators: “It is very simple and easy to operate as opposed to Elasticsearch which requires a couple dozen knobs to understand and tune which you can get up and running in under 2 minutes. It is a drop-in replacement for Elasticsearch if you are just ingesting data using APIs and searching using kibana (Kibana is not supported nor required with OpenObserve. OpenObserve provides its own UI which does not require separate installation unlike kibana).”

Interesting, indeed. Here’s a couple choice quotes from the comments section.

User gettodachoppa says “I just tried this 3 days ago… As someone running a homelab, and hadn’t set up logging yet, it was a great find. I didn’t have to learn and combine 3+ log technologies, it’s just a single all-in-one monitoring server with web UI, dashboards, log filtering/search, etc. RAM usage of the Docker container was under 100MB.”

and user SergeAx says “Interesting product, thank you for your effort, definitely want to give it a try! For me, though, setting up a system is not the primary pain point today. FWIW, signing up for a cloud service is not hard.
The problem starts at the ingestion point.”

Alex Gallego: If there wasn’t a Redpanda available, which I think there would be, I think that there’s just like – I know that we have changed the roadmap of other startups. If there wasn’t a Redpanda, probably… If there was a Redpanda, then I would only build a cloud service.

Jerod Santo: If you listened to “LLMs break the internet” with Simon Willison last week, you already know that my a-ha moment during that conversation was realizing language models don’t necessarily have to keep getting larger for most use cases, especially once we start providing them tools to find answers on their own. That’s promising.

In that arena… check out Tabby. It’s a self-hosted AI coding assistant. An open source / on-prem alternative to GitHub Copilot. Tabby is completely self-contained, with no need for a DBMS or cloud service. Has a web UI for visualizing and configuring things, and provides an OpenAPI interface to easily integrate with existing infrastructure.

The AI game is certainly afoot, but it’s clearly the first few innings and if we’re lucky projects like Tabby can move us toward a future that isn’t dominated by a few big tech companies.

Jay Alammar: I mean, definitely, it makes it a lot easier for a much more larger group of people to start experimenting with these models, because it just lowers the barrier of entry so much, and it enables people to not think about moving tensors across GPUs, and watching out for GPUs running out of memory, and updating model weights… It’s just another abstraction, and you can think about it just like every other cloud service out there. So if you want to build a new website, you no longer need to buy a physical machine, ship it to a data center, maybe go physically to that data center and sort of put the code on; it’s been abstracted away as a service you can reliably access. Somebody else has the world’s foremost experts making that service reliable for you, and you can focus on your core business problem, the core sort of product that you want to do, knowing that these other pieces are there, and are being handled by people whose sole job is to maintain the quality, and increase the quality of these models, and the uptime.

This is especially a factor when these models are massive; they need to be on so many different machines and GPUs, and it’s such a hassle to deploy your own models. You need a PhD maybe to really wrap your head around everything that is involved in something like that. And so yeah, it just frees up people to think about, “Okay, this is an API. Think about the frontier, of the next level of services that are now finally possible, that weren’t possible before.” And let’s say we saw new industries come out of these developments in AI.

[31:47] AI writing assistance, for example, is a type of industry where there’s so many companies now that didn’t exist before… And these companies just in general rely on APIs, and they can focus on really creating the best domain knowledge for them to help out their customers. So it really helps in the specialization and sort of that abstraction of not having to worry about this lower layer in the stack, where others are sort of handling it for you, and fine-tuning becomes as easy as uploading a text file, rather than a process of babysitting a model for a week to see what happens. And so that definitely increases the cycle of experimentation, but also the ease of deployment accelerates, let’s say, the coming of the next generation of products that are just now possible.

Florian Forster: Let’s see… A thing I can definitely disclose right there is the – we are strongly considering opening additional regions, because we see now where traffic is originating from, and we are considering to expand our footprint on that end… And also a thing that will land in our cloud eventually is a feature I did not disclose yet. It’s basically an event API. It’s a simple API; you can basically fetch everything that changed in Citadel, with the whole body to it, like first name changed to whatever, because that gives the developer a great way of backpressure processing of things that changed, so they get a proper change track of everything.

And that thing - I mean, the event API will land at one point in our cloud service, but that needs some rigorous testing to be sure that all the inner fencings of our cloud service work out well, not that customers see the wrong data, and stuff. So that’s a thing. And we are experimenting with different CPU profiles in our cloud service to reduce some of the latency we see, especially during hashing operations… it’s one small [unintelligible 00:59:55.17] But there is like a limitation in Cloud Run’s offering; you can’t have really high CPU containers without high memory, and we don’t need so much memory. Normally, Citadel uses 500 megs of memory; we don’t use more. The rest is being handled by the storage layer and caching.

So yeah, that’s a thing that needs untangling… So either we can use resources better, or we can somehow influence to have more CPUs in there, to get better latency. Yeah, that’s an ongoing experiment. We always try to wiggle out some things.

Lars Wikman: I certainly think my choice of Elixir influences how I want to set things up a lot. Whenever I explore sort of doing multi-language ecosystems, or it’s like “Oh, yeah, I need this tool from this language, and this tool from this language, because it would be infeasible to reimplement”, then the ops start shifting. The shape of the plan starts changing. It doesn’t have to change much sometimes, but it’s like “Oh yeah, you need this Node server thingy standing up here.” “Alright.” “ You probably want to put NGINX in front of that.”

There’s also – depending on the work your machine is doing, Elixir has a machine learning project now. And if you’re doing machine learning, of course, that really affects your ops, and it could be a good reason to use this sort of Elastic Cloud Service, because if you want to train models on really fast hardware, you probably want to rent that, rather than pay $10,000 for one tensor card. It’s just sort of cost-prohibitive to set that up, and there’s a lot of sort of shipping data back and forth… And I can see why people do that in the cloud a lot of the time. And Elixir and Erlang, as you know, are not ideal for number crunching. And this is something I’m probably going to do a small write-up about soon, but Python is not ideal for number crunching.

Ryan Dahl: Yeah… Mostly because I don’t have a Twitter. I need some outlet to write somewhere, and very, very occasionally I’ll dash off something tinyclouds.org. Yeah, JavaScript containers - so we’re building this serverless system called Deno Deploy, and we’re doing this as a business; this uses the same technology that we’re building Deno on. The concept with Deno Deploy is that you are not – most cloud providers, you’re basically writing Linux programs. You’re writing a Linux server. Maybe it’s in Python, maybe it’s in Go, maybe it’s in JavaScript with Node, maybe it’s in Deno… But at the end of the day, you’re packaging it up in a Docker container, shipping it off to DigitalOcean, to Fly.io, you’re using AWS Lambda, but like the abstraction layer that you’re working at is ultimately a Linux abstraction. And maybe you make that as thin as possible, maybe you make that Alpine Linux, but ultimately, you have this Unix system that you’re working within. And that starts becoming a little weird after some time, because you realize that almost everything that your application is doing is in JavaScript. Essentially, a lot of these API servers are taking incoming requests, maybe doing some authentication, making an outbound connection to a database, maybe calling out to some other APIs, kind of gluing together the responses somehow, sending that back to the user. And the Unix part of it is shrinking and shrinking, and the business logic, JavaScript part of it is growing and growing. And at some point, you realize, what’s the Linux part of this actually doing for us? Isn’t this just an unnecessary complication? And I think in particular for us JavaScript users who are used to opening Chrome, opening Chrome DevTools, having this little shell in there where you can type JavaScript is pretty similar to your terminal where you can type shell script. And shell script is kind of similar to JavaScript in a way.

[22:10] And you start thinking - in Chrome DevTools, it’s not Unix in there; there’s no real directory tree, there’s no environment variables, there’s no systemd, there’s none of this Unix stuff. You’re just in this browser world, and it doesn’t matter what operating system ultimately is underneath it if you’re abstracted into this nice, scripty, kind of JavaScript world.

And what we’re trying to do with Deno Deploy is really raise the abstraction layer for a cloud service. And so instead of providing JavaScript inside of a Unix container, we’re just providing the JavaScript. And so you can start thinking of servers written in JavaScript as being their own kind of container, rather than packaging this up with Node inside of a Docker container. As long as you’re comfortable being explicitly JavaScript, you can kind of just live in this browser worldview. And this has a lot of nice benefits, right? Your JavaScript server package, if you use Deno, is very small; on the order of kilobytes, where you essentially just zip up your JavaScript source code. And this is quite small. So our deployments happen in, I don’t know, five seconds or so… The cold start time for this, because we’re not booting up a Linux instance and starting up other stuff, there’s just less involved.

Adam Wiggins: [58:17] Yeah, absolutely. Those kinds of integrations, whether it’s classic files, let me drop in an Excel sheet, or a video, or something like that… Or whether it is more of a cloud service, a Figma, or whatever. I think Notion probably gets the closest on this… And in many ways, Notion is the big success story for the tools for thought world to date, where they do manage to bring together multimedia of all different kinds, and the text blocks, and the linking, and all that sort of thing. But again, it is – well, there’s not an infinite canvas; it is a classic, page-based, top to bottom, it’s text-oriented first and foremost, rather than visual or spatial, or sketch… You can’t start with a sketch, and then start to add text. The place you really start with Notion is text.

So I think Notion is great product, and it’s obviously been very successful, but we think that if you can imagine a world where there is a proliferation of tools for thought that are in the same vein as Notion, but explore totally different directions, such as visual and spatial in the direction we’re going, and that teams and individuals have a lot of different choices to choose from, just the way that – you know, I’m a big believer also in just diversity of tools. So I don’t think there needs to be one programming language to rule them all, nor do I think there needs to be one tool for thought to rule them all. One, because you might use different ones in different circumstances, and two, just because you have different ones that just fit with your brain. someone might say “I like Rust, because it just fits my brain.” I say “I like Ruby, because it just fits my brain.”

And you can debate over performance, or what kinds of applications it’s most suitable to write, and those are valid discussions… But a lot of it does come down to taste, and feel, and vibes, and I think that’s also a thing that could and should happen in the tool for thought world. But right now, we have just note-taking apps, and file systems, and then there’s a few early movers, like the Notions and Roams of the world… And I just hope to see much more proliferation of that, so that we all have more choice.

Yonatan Cohen: Yeah, so today you can access quantum computers through the cloud with several players. So IBM, for example, has a quantum cloud service that actually gives you access to great quantum computers. You can log in and you can actually run algorithms… But these are small quantum computers. Of course, they’re still a prototype of the technology. But you can actually run algorithms and you can see how they behave, as well as on simulators. You can compare, and then you can find that your quantum computer is doing not as well as the simulation, because it has a lot of errors; this is the main problem with quantum computers today… But you can do that, and that’s actually very cool.

IBM, for example, they give access to their own computers, but Azure and AWS have launched their quantum services in the last few years that give you access to third-party computers… So many different computers that are built by full-stack quantum computing vendors, like IQM, QCI… These are startups in quantum computing that build full-stack quantum computers, and you can access those machines actually today through the cloud, which is very cool.

And they also give you access to simulators, and you can run on those as well… Which I think is quite amazing, to be honest. I mean, there are certain experiments that I used to do during my Ph.D. at Weizmann Institute only 12 years ago that… It used to take a Ph.D. student maybe three or four years to set up such an experiment and to run it, and now I can just log into one of these cloud platforms and I could run the experiment that just ten years ago it used to take a few years to set up, I can do it probably in a few hours… And that I think is quite amazing.

Nikita Shamgunov: The two jobs that we’re looking right now is a UX designer, and we’re potentially looking to bring a developer relations lead, more of a senior person. We have one fantastic individual, his name is Raouf, who is running our DevRel right now. But what we’re hearing from the board - it might make sense to bring a very senior person to drive the developer relations effort.

So these are the two positions that we are hiring for right now. We are always hiring for engineers; we’ve been blessed. There’s a line of people who want to work at Neon, on our storage and our cloud service… So we feel we’re very fortunate, because the system is open source, it’s written in Rust… So that’s like a system engineer candy. Hopefully, this will stay, but as of right now, we have more applicants than we can process… And we just added nine in the last months.

Ben Ford: Yeah. Okay. Great question. I’ve nerded out on this long enough. So I have a content management system, open source, called strapi.io. That’s where I keep the structure of the website and blog posts and things like that. That is statically rendered into a Jamstack, Next.js site that is hosted on Vercel. Strapi runs on railway.app. Vercel is where I run my front-end systems that’s a statically compiled, very fast to load, optimized HTML build. Vercel also gives you serverless functions on the back end. Just a Next.js thing, you write functions in a certain way in a certain directory in your code, and you’ve got an API endpoint.

Another massive part of this stack is Hasura. So a very important part of this stack is where you keep all of that consolidated data. Hasura is fantastic, because underneath it is a proper Postgres database. So you’ve got all of the affordances that Postgres gives you to make sure that your data is well-formed and foreign keys are pointing in the right direction, and all of that. Then Hasura gives you a free API over the top of that in the form of a GraphQL schema that’s automatically generated.

That just cuts down all of the backend programming that you have to do, because you want to build a specific user interface. You can pick a Retool or Appsmith or you can build something yourself in Next.js, and the amount of backend programming you have to do is very minimal, because you just do a GraphQL query. In fact, you can even generate code, typed code if you’re using TypeScript. I might not have mentioned this before but my background is in functional programming and I like types a lot.

So yeah, you can build this quite robust, but very easy to operate system comprised of all these different parts. N8n, you can run as a cloud service, so you can pay N8n themselves to run you that. But if you ever find that you’re putting a load of volume through and it’s costing you too much, you can always run it yourself, again on the same platform, whereas I’ve sometimes seen things like Zapier or Integromat.

In that system, as soon as something gets expensive, you now have a very expensive rebuild job to do. Either you suck it up and you pay several hundred pounds a month, or more sometimes, which is probably worth doing versus the alternative. But that’s money that straight off your bottom line. Or you stop the world and you rebuild it into something that runs on some sort of cloud infrastructure, and that’s obviously expensive in engineering time. Or you do it this other way and you say, “Okay, I can run it myself on my own infrastructure” and you’ll just pay usage on Railway or whatever. Just a Docker container.

Adam Stacoviak: [23:53] One of the things I thought was interesting too as I was doing some research was just the flexibility this model gives to those who use it. You can do a local machine, you can do the cloud service, which is what you were talking about, the platform code, or even as a Docker container. So you really have, from a user perspective, the highest advantage, which is really open source; the mantra behind open source is adoption. I can put something out there, and one person can use it and get value, or everybody can use it and get value. I think that’s kind of interesting, that you’re so flexible that you can do local, cloud service, as you do, or a container, and just giving the user base that kind of flexibility to be so restriction-free.

Shawn Wang: So I try not to do the prediction business, because I got out of that from the finance days… All I’m doing is nowcasting. I observe what I’m seeing now and I try to put out the clearest vision of it, so the others can follow.

I think that it makes sense for them to be replicating the primitives of every other cloud service. So in 2017 they did service compute with Cloudflare Workers. In 2018 they did eventually consistent data store. In 2019 - website hosting; that’s the Netlify competitor. In 2020 they did strongly-consistent data store, with Durable Objects. In 2021 object storage. What’s next on that list? Go on to your AWS console and go shopping. And instead of seven different ways to do async messaging in AWS, probably they’re gonna do one way in Cloudflare. [laughs]

Evan Kaplan: Yeah. So the big transition over the last few years has really been building a cloud-native platform. So we had had a managed service cloud - we still do - that’s pretty successful, and has large customers, like Salesforce, and Google, and that stuff on it. But Paul particularly advocated starting even longer of that the right model for the future is something like an Amazon native database, or an Azure native database in which people are paying for reads/writes/queries, they pay for what they use; if developers find it useful, they build interesting things on it, and they run it in the cloud… And then they only pay for what they use. And his view was that’s the best way to monetize open source. There will always be people in the open source world, of course, who won’t wanna use that, but that’s the best way to monetize if you’re a company. And I think we’re seeing that; certainly, the predecessor for us was Mongo Atlas doing that really well, which now represents I think more than 50% of the revenue, and growing faster than that. And that is a core feature of our business, and that’s going phenomenally well.

And then IOx… The work on IOx was - you know, after 7 years of working on time series storage engines, realizing that there are always gonna be issues around cardinality, and performance, and query performance, and things like that. You could do this way better. So we started the IOx project, and its relationship with Apache Arrow, and the Parquet file format… I thought it was a super-clever way to go about it. We’ve invested in that now for well over two years, and we’re super-excited. That will be an accelerant to the cloud. But we don’t get to just be cloud, because a lot of our business and a growing portion of our business is in IoT. Most IoT architectures have an edge in cloud, sort of a two-tier or even a three-tier architecture of local storage, and analytics, and so building that edge capability and the on-prem capability continues to be in the raw open source… The fact that we continue to produce new open source that people will use at the edge, or in the enterprise, and that sort of stuff - all these things come together into what we view as our competitive advantage, a comprehensive platform. Cloud-native, at the edge, in the enterprise, being able to use this all together, with a common API, and that sort of stuff.

[40:26] So that’s our view of where our tech goes. In terms of where the market goes - to me, that’s what’s super-exciting. Listen - obviously, sensors are getting cheaper and cheaper, we’re sensorifying all the physical world, in every way, shape and form, whether it’s the 12 sensors I have on my body from this Apple Watch, to the Whoop band, to the Oura Ring, to whatever. They’re not slowing down, whether it’s your car, or your home, or your new Tesla Powerwall - whatever you’re doing, we’re seeing the physical world being instrumented in really meaningful ways, and building that sort of in the broader… I think we are well-positioned for that, because the lingua franca of IoT is time series. It’s pressure, volume, temperature, humidity, light, whatever it is… What happened, what happened, what happened, what happened… And that kind of data, super-fast processing in real time… So we’re super-excited about that, and having the vehicles to serve it. So that’s what’s driving our product vision, things like that. And to continue the foundation in open source.

Adam Stacoviak: [28:02] Yeah, eventually… And that’s the fun part and the hard part, is coming to that same answer… Because I think once you’re unified, which I think you can speak to, because as I said before in the top of the call, I am a fan; I’m a big fan of Sourcegraph, I’ve known Beyang longer than I’ve known you, but I’m also a fan of you as well… And I’m a fan of what you’re doing. It was not always easy to understand what you were trying to do over the years… And I think you do that with a brain discovery, or a product discovery, or how do we deploy this discovery, how do we – we understand the value of code search, we understand the usefulness of code search to every developer, but how do we put it in the hands of developers so it’s actionable? I think that’s the hard part there… Which might lead to another mistake/failure at the product level, which is you went cloud, not self-host first. So you began with cloud, and you didn’t do self-host… Talk about how you (I suppose) engineered the application to be as a service, not as a service, as a cloud service… How did you begin? How did you know it was wrong? How do you know it’s right now?

Jared Watts: Yeah, this experience is being built in our Upbound Cloud service that we’re building. Our startup, Upbound - they’re the creators of the Crossplane project, and we’re building a SaaS product and a whole experience, an enterprise-focused experience around Crossplane. So since we have a complete understanding of what is the package structure, what are the contents, what does it mean to be a Crossplane composite resource and configuration and all that domain-specific knowledge, we’re able to build a rich experience with discoverability and sharing all those types of things in our Upbound Cloud service on upbound.io.

Feross Aboukhadijeh: Yeah, exactly. Your password is just an extra little bit of fluff at the end of the true password, which is the key… But then you have the other problem, which is that users can’t remember the key, so that the app remembers it the first time you type it in, and then you just use your password as a practical day-to-day unlock of the app. So it’s a really cool design. It kind of solves all the problems that you would worry about with the cloud service.

Mitch Wainer: I think we would have done it eventually. I think what all this work, market research or the path that we took just got us to answers a lot faster, and it reduced the time to market, which is really important. There is a timing consideration here with finding product-market fit for any company and any business. We were one of the first, if not the first cloud hosting business offering SSD machines at $5/month. SSD cloud service at $5/month. And Moisey, our co-founder, and Jeff, our other co-founder, they were really pushing this idea because they felt like if this wasn’t gonna work, nothing was gonna work. And it was really our last big swing at the plate. And if we didn’t knock it out of the park, we could have shut the business down.

And Ben came to us - he was the CEO - and said “Listen, if we don’t double acquisition, because we’re cutting our margins in half by offering double the RAM and SSDs - if we don’t double acquisition, we could go out of business here.” Needless to say, we didn’t double acquisition, we 100x-ed acquisition overnight. I was able to get a TechCrunch article written about this new product and the SSD droplet… And we went viral on Hacker News soon after, and we just saw the numbers climb into a whole new stratosphere, from 10-20 signups a day to then 100, 200, 400 new customers a day overnight.

At that point we quickly realized “Okay, well now we have to keep up with demand, we have to raise capital, we have to go out to the investor community and raise more capital to meet the demands of our customer to keep up with this insane growth”, which was a whole separate challenge.

Adam Stacoviak: Yeah, it restricts cloud service providers from offering – this is quotes; it’s what it says. “It restricts cloud service providers from offering our service as a service.” That’s in violation of OSD 6.

John Myers: Yeah, absolutely. Right now the open source packages - and there’s two of them; one of them allows you to get started with synthetic data, and the other one allows you to get started with our traditional transformers, to kind of mutate data in place. Those are Python libraries that are available to anyone, licensed under Apache 2.0. Obviously, you go in using those knowing that it’s Python, and that already is kind of a qualification for a lot of our customers… Which isn’t a problem; we have a ton of researchers and data scientists that live and breathe in Jupyter Notebooks, so they’re able to plug that right in.

Last August we launched a beta of more of our premium features, and that beta basically allows you to use our cloud service to test out our labeling capabilities. Then what we ended up doing was packaging up a lot of our premium capabilities, which include automatic data validation, it does a lot of analysis to make sure that correlations across all your data are held, distributions across your data are held properly… We also released those available as an SDK that you can download through our authenticated API.

[35:52] We had a great about several months of going through that beta, getting a ton of feedback from users, and then what we walked away from that knowing is that what we really wanna do is make this available to engineers everywhere. And engineers everywhere can’t necessarily just download a Python SDK and incorporate it in their pipeline if, let’s say, your entire backend is written in Java. And so how do we drastically simplify what these premium SDKs do? So what we’re building now is the ability to launch Gretel services as kind of containerized capabilities that are backed by REST APIs. So now you can interact with our services purely through a REST API, which is completely language-agnostic. Every engineer at some point has gone through the process of making API calls through remote service, and so now that is kind of the qualification factor.

We wouldn’t have learned everything that we learned if we didn’t have that granular-level capability out there through the beta… So now the entry point will kind of either be you can run Gretel services in your environment, we’re also building a hosted service where we can run and scale these capabilities for you… But it should be as easy as taking your dataset, or taking some records, a lightweight configuration, pushing it to an endpoint, and that endpoint will then trigger a whole bunch of backend work to learn, build a model, or generate data for you. And at that point we really just wanna be a bump in the line in your entire data workflow, to be able to call into these API. So that’s what we’re working on now, is just really simplify that down.