 All right, well, this wasn't on purpose, but I also work for Octeto. That's the same company that Jacob works at. So we'll keep talking about all the wonderful things of preview and dev environments. Let me just check this works. All right. So welcome, everyone, and it's so excited to be here at DevEx Day. I have to say that it's after a year and a half of giving talks on Zoom. I'm super excited to do this in front of a live audience. Funny enough, my last talk was on KubeCon 2019 on serverless days. So that was like two years ago in San Diego. So yeah, I'm very excited. And I'm also super excited that we have at DevEx Day. I think we've been focused on the DevEx world for a while. It's really cool to see more and more companies investing on this and really taking care of this is something super important for team efficiency. So I'm very excited to see more and more people on this space. So today, my talk is kind of the same line as the talk that the team from InflexDB gave on if your application is going to run on a multi-node cluster. Why are you still developing on a single machine? And this is something that probably everybody on this room knows. But you know that production has evolved in the last 10 years, you know, VMs, containers, Kubernetes, GitOps. We've been moving very fast towards a world where microservices are distributed. Everything is heavily automated. It's meant to scale horizontally and all that stuff. However, if you think about it, development still happens on a laptop. And this is something that, as we at OCTEDO talk to more of our customers, this is something that keeps happening where a lot of teams have spent a lot of resources trying to make their local machine look like a cluster. And you know, this is the approach we've all done for a very long time, Docker Desktop, KIND, K3S, Minicube. But as we heard on previous talks, there's a lot of resources invested here. Your application is not quite like production. You're using a lot of CPU and memory. Your experience becomes sluggish. So you know, and at the end of the day, it's like you end up with this deaf version of your application versus production, which is something that it's, in our opinion, problematic. And this is a space I've been working on for a very long time. OCTEDO started as an open source project around three, four years ago, trying to solve this problem. Today, when I talk about this company, it's a case study. I can't mention names, the privacy, but it's a public company. It has a very large engineering team. It's a very mature Kubernetes shop. They have containers in production, staging, full automation, all that stuff. But their deaf environments initially were all local. Developers were using whatever their favorite tool was, Docker Compose, Minicube, to spin up 10, 20 microservices plus data stores, plus data all local. And it's something that it was a challenge for them. They were having a lot of problems around developers feeling they were not efficient, developers having to be experts on their entire stack and everything from Kubernetes, container building, deployment, all the way to the code. And it was just a challenge for this company. And hours to spin up an environment, a lot of these environments, because they were so complex, they became this kind of artisanal thing where they were kept built by hand, kept very static. Everyone was very afraid to rebuild them. The cost was very high because you had to rebuild all these artifacts. And they were having a lot of production-only issues because Dev and Prod didn't look like. And more importantly, and this was kind of like the number one concern for this organization was, developers felt that their machines were very sluggish. They would run all this process locally. And then every time they had to switch from code to Slack to their cluster, you just take forever. And this experience made them kind of feel bad. They felt like they were being held behind by their tools. They were not able to go as fast as they were thinking. And we talked to them, and we've talked to a lot of companies about this. And we were able to summarize what all this modern Dev experience looks like and what developers are looking for. One is they want it to be replicable. They want to be able to spin up a Dev environment as fast as possible, not something that you keep running forever. They want it to be as realistic as possible. They don't want to have to wait until their code makes it to CI, CD, or staging, or even production to know if it works. And number three, and for me the most important one, they want a fast experience. And this is kind of what we learn as we talk to all these companies, is fast experience is the most important thing. If you, as a developer, cannot see your changes in a second or less, eventually, you're going to stop using whatever experience you have, and you're going to go gravitate towards something faster. It doesn't matter if it's not realistic. It doesn't matter if it's on demand. Like developers value speed. We all value speed a lot more than any other sort of comfort. And it's something interesting, and it's one of the things that has been guiding a lot of the work we've been doing on the stuff that I'll show you today. So as we spoke with all these organizations, kind of we kept thinking about this question, which is, instead of forcing our local machine to look like a cluster, what if we just do the opposite? And instead, we make our cube clusters to behave like our dev machines? This is kind of like the question that made us start this open source project. It's called OCTEDO. The company came after the open source project, so we kind of kept the same name. But it's github.com slash OCTEDO. OCTEDO, if you're interested in the experience, the environments, star, follow, all that stuff, it's a community effort. And the main principle behind OCTEDO and behind this motion is this is what your typical flow looks like when you're using a local cluster. There might be some optimizations, but you're writing code. You have to build your containers, redeploy them, wait for the image to be pulled if it's a remote cluster or in your local registry, deploy, then you test, and then you go back and write code. And this might take, if it's super optimized, you don't use something like Scaffold, or you know, it's in local registries, whatever, it might take two, three seconds. But if you think about this, if you have to wait three, four seconds every time you wanna test a code change, how many times a day are you gonna be doing this? If once you do this like 50, 60, 100 times, that's hours waiting for things to build. And that is kind of the core problem we've seen kind of going back to developers' volume and speed as the problem. And this is one of the big things that OCTEDO is set to solve. Is the idea that in one site, we want developers to use clusters as development environments. We know there's value there. We know there's a lot of like, reusability, reducing this queue behind dev and prod, all that stuff. But we also want to make it fast. And that is kind of like the space that the OCTEDO CLI is covering. So how does it work? Very high level, there's two components. There's a CLI that you install locally, a binary, and there's a manifest that you create that kind of like tells OCTEDO how does your dev environment look like? And in our case, the idea here is that you have a very small manifest that just explains some developer dev time overrides you wanna apply on any queue application that's running. You have your API, your front end running on Kubernetes. And you can just have this manifest telling OCTEDO, hey, when I'm developing on the API, I wanna use different image because I need some tools there. But I wanna set up some environment variables. I wanna cache for my dependencies. Very simple. And then you run OCTEDO up and this is kind of what your dev environment now looks like. You have your local machine with your source code. You have a copy of your application running on an in-space kind of similar to what the InfluxDB team mentioned. And you have OCTEDO synchronizing the code between your local machine and this remote environment. On top of that, you can do things like a remote terminal, like changing how you build and restart your process. Everything with the idea of giving you this very fast experience where developers write one line of code, press save, they see the results on Kubernetes. With OCTEDO, it's all about code synchronization, process hot reloading. So you don't have to rebuild containers. You don't have to replicate. You can go as fast as you can by simply like writing code and seeing the result. We've been working on this for about two, three years now. We started the open source project in 2018. It's an Apache 2 project. And this is kind of like the guiding lights for this project and kind of for this idea around helping developers expand their environment from the local machine to the cluster. It works on any Kubernetes project. You have this manifest that I already kind of show you where you override dev time things because at the end of the day, no matter how much we want it to be the same, there are changes between production and development. Another guiding light for us is that with OCTEDO, you have the ability to, as you deploy a complex application, only develop on one, two, three components, whatever you need, while leaving the rest of your application. And this includes ingresses, databases, security, network configurations, whatever else your application might have. The same as it is on production. And this for us is one of the things that it's key to having a great dev experience is the ability to kind of isolate the parts of the system you're working on while the rest just looks like production. And this has a ton of benefits around end-to-end testing, validating that your code works, all that stuff. Something else we invested early on, and we're talking about this for lunch with some of you, is the ability to integrate other cloud native tools like Billkit or like registries as part of the cycle with the idea that the more we move to the cluster and the easier it is to make it like for developers, the faster you go. Like we have one command on CLI, octetobilt, that you can connect to any Billkit instance you have running on a cluster. And now instead of using your local Docker instance, it's a pot on your cluster doing your Docker builds where you have a persistent cache where you don't have to fight for CPU with your local machine and all that stuff. And this is an example of things that we're kind of like fully integrating to give you this fast experience. And at the end, it's all about fast code synchronization. It's the idea that you write code locally, it gets reflected on your remote dev environment in less than a second and you iterate. You write code, see the results, run your tests, whatever you need, but never leave this fast inner flow independently of whether you are on your local machine on a remote dev environment. And so far we're getting some fantastic feedback on this. We have over 6,000 developers using this open source project. Some of them use them for hobby projects on their own, all the way to public companies. I was talking before using this across organizations with hundreds of engineers. And to them not giving a demo because I wanted to focus more on the dev experience and what we've learned through the development and implementation of octet in these organizations. And the first thing, and I think it's a topic that we keep hearing today is Kubernetes is a great solution for deploying infrastructure at a very high scale and at speed. And this is not new. We know this from production. We know that we can now deploy hundreds and thousands of services on clusters all around the world. But at least until a few years, I never thought about this as something that developers would also benefit from. And kind of what Jacob was saying on the previous talk, you can spin up a multi-service orchestration, 20, 30, 50 services per developer with a very small footprint and with very little overhead. That's something that before could not be done. I cannot imagine spinning up 20, 30 VMs on a vCenter. It's a lot more overhead. What we Kubernetes is super simple and it's super fast, especially once you get into optimizations around pretty fetching images, making your images super small with things like KO. It's just a different world and that's something to consider as we build new Dev experiences. Number two is that namespaces are a great boundary for most Dev environments. When we talk to companies and we talk to developers, a lot of people are of the idea that, hey, I need a cluster per developer because I want to isolate everything there. And that is true if you're building things like operators, if you have to customize CRDs or any of these kind of more global resources in Kubernetes, which I do hope eventually they'll also be namespaced, but right now they're not. So you're kind of stuck with that. But for everything else, the reality is that the namespace is a pretty good boundary, especially if you're careful around requests and limits. Like in some of our deployments, we have companies running clusters with like 20, 30 nodes where 150 developers each has a namespace with a copy of the application and every application is 20, 30 services. So you're talking about 500, 1,000 pots, 2,000 pots running on a cluster. And this is a GKE cluster with 10 nodes, like nothing fancy. And that's something that to me is fantastic, is the idea that namespaces are a boundary, they do get some security. It's not super secure, but enough for like a friendly team not to kind of like delete each other's dev spaces. And it's fast, like spinning up a namespace and deploying and bringing it down is like super easy. Another finding that was really interesting is that it's not trivial, but it's simple to move most workloads to a cluster. Like in our case, we started with like code synchronization, then we started moving things like container builds. Racers, of course, were already on the cluster. But this idea that the more things you move to your cluster, the faster your cycle goes because you have less things to war in your local machine. Some teams are now using Gitpod or Coder to even have the Cloud IDE on the cluster. It's something else that also there seems to be a trend, not the biggest fan, but there is a clear trend on the market on that. But it's really about like dev experience and the efficiency is the less things you run on your local machine, the more things you can run on Kubernetes, the faster your machine is gonna go, the faster the experience will go and the more things you can use. And one of the questions on the previous talk was, what about data? And that's one of the really cool kind of like experiments we've done lately, which is the idea that now, because everything is in the cluster, you can do things like use volume snapshots and persistent volume claims to do things like a clone on demand of a database that's running on staging for every developer. It's a scenario that we put together with some of our early adopters to give every developer a copy in this case of an e-commerce store with data, with transactions, with users. And it all takes like a minute to provision on a Kubernetes cluster. And again, with like not a lot of overhead and very easy to scale up as developers go. And that's kinda my other topic, which is moving to the cluster, moving your dev environment to your cluster allows you to scale up horizontally rather than vertically. A lot of us have to spend time like building bigger machines, right? You have your latest MacBook with more RAM, with more CPU, or you're building your own kind of like local server with as much space, whatever you need. There's a limit to how many CPUs in memory you can have, but there's no limit to how many pods you can spin up. So if you kinda scale up your dev environment horizontally, where you have every service on a pod across as many nodes as you need, and you're kinda like developing in this way where you're targeting one service at a time or two or three, but not all of them, it's a lot easier to build this really fast dev experience. And going back to like managing, especially at scale, it's a lot easier. Like smaller pods are to a certain degree, right? Millions of pods is not easy, but 10,000 pods, 20,000 pods are small are a lot easier to deal with than 400, 500 VMs that are gigantic and that you have to rebuild every few months. I used to work at Atlassian before and my team there had this VM based dev environment that was never updated because it was really hard to have to rebuild this VM and pre-install everything. And now we have a lot of users of Okteto. Every time you do Okteto up, they rebuild their dev environment and it's a new one and it takes seconds. So it's something really cool. And I guess it's something that we're all here for the same reason, but we all know that a great dev experience is fundamental. As we build this new generation of tools, like having a bash script that does everything for you does not longer cut it. It cuts it for the people in this room, but as you want to involve more and more people from your organization and benefit from this, you have to think of higher abstractions and that's kind of what the previous talk we're talking about. Not everyone needs to be an expert in Kubernetes. Like if you have a front-end team, why do they care about containers? Your DevOps team, sure, your backend team maybe, but there are other functions that should not care. So as you build the experiences, this is very important is it has to be polished. You have to think of the names you're using for your CLIs, for your verbs, for your actions. That's something else that we learned through this process with Okteto and we're not there yet. There's definitely a lot of things to learn, but I feel like as an industry, we're tracking in the right direction. And finally, I've mentioned this twice, but I want to really, really repeat this. If fast inner flow beats anything else, if you're going to focus on one thing, as you build a dev experience, as you move to remote environments, it has to be fast. If it's not fast, no one's going to adopt it. Even the before developers were all really good at finding other ways of doing things and if it's not fast, you're going to create your own system, you're going to hack it this way or another, and then you're going to lose all the other benefits I was talking about. So it's really important to really take this into consideration. And I'd like to wrap things up. This is what this company looks like after they started using the Okteto CLI. The first thing that changed for them is that now they can spin up a new dev environment in Kubernetes in less than a minute. And this includes creating a namespace, deploying 20, 30 microservices now with databases, having data on the databases, creating an ingress, all that stuff. They just run a command where they will deploy their home-based environment. Okteto gets in the way and it just applies everything instantly, including data. And that's a big thing, right? Because now your dev environments are even more realistic because it's not just the latest code, it's the latest code, but you have your data, you can test migrations, all that stuff. Another great thing about this is that now developers think of dev environments as something that is free, which means they can just deploy them, turn, tear them down. You don't have developers spending time kind of tinkering why my dev environment is not starting. Every time there's a new branch, delete the environment, launch a new one. And that is, it's not obvious, but it's a big productivity gain because developers are no longer scared to try risky stuff because they know that, hey, if I break my environment, no big deal. Delete the namespace, spin up a new one, and back to where it was. And that is something that we've seen really on locks, creativity, productivity, developers. Even in some cases, they can launch multiple dev environments, one per feature, you can go from one to the other. It's a lot of really cool benefits as you can move things away from your local machine into this kind of cluster-based dev environments. And in our case, I think for us, as creators of this open-source project, the fact that as people use it, you see them using it every day, it's pointing us towards, hey, this has legs. This is something that we as an industry can move towards. And I think we heard the same thing from the other talk on how you're not gonna be able to force developers to adopt tools, like those days are gone. You can have your CTO come and scream at you and tell you that you have to do things X, Y, and C. The moment she's gone, you're gonna go back to whatever you feel is better. So building tools and tracking usability and how long developers stay on your tool, it's a great testament to like, hey, this works. And in our case, it's been fantastic to see some of our early adopters use Oktero for five, six, seven hours per day, which is like their entire work day because they see this value. And that's something that we as a project, we're always looking for people to use it, collaborate, help us. And we're just getting started. Definitely this motion towards remote dev environments is to me, super exciting. And we're looking for more people who are excited and wanna contribute. And some of the next things we're kind of like building here is single commands, deploy, test, integrate everything together. Integration with IDEs is something else that we built this kind of early BS code plugin that some people really like. There's a lot of work to be done there. We wanna be able to integrate with Gitpod, with Coder, with the JetBrains Suite, all of that. Definitely like dev experience is something we are continuing to refine and make it easier. One of the big challenges for us today is how do we make these kind of tools available for a non-Cupernetis expert audience? All the developers in the world who don't care about Kubernetes, they're building solutions and value for their own customers and they just want a way to be faster. That is a challenge because as you start building tools, like we are experts in Kubernetes, we know what a pod is, we know Qtcl, but there's a huge number of developers out there who don't care about this at all. And all they care about is I wanna be efficient, I wanna go fast, I wanna make sure my thing works. So that's a challenge that's something we're looking forward to kind of like as our tools and other tools in the ecosystem evolve is to be able to cater to that audience and kind of move away from just experts. And that takes me to my final point here, which is we're kind of exploding and talking to other teams and other people building similar tools. It's like, what if five years from now, there was a standard in how you define a Dev environment in code? Like there's a few different products doing this, so that's something else that if there's interest in the industry, I would love to talk about this more, whether it's through CNCF or just a bunch of companies agreeing on standards, there's different ways to go around this, but I think there's a lot of potential on this sort of things of like kind of like standardizing what a Dev experience should look like for anyone building a microservice-based application, a serverless application, any of these topics. And definitely, as I talk about the standards, it's not just Octetal, there's a lot of other companies and open source projects working on this topic of kind of helping you move your workloads to remote Dev environments. Octetal is one of them, but there's also telepresence that we heard of before and I think Daniel is speaking next on this.