Speed up your Team by Moving your Development Environments to Kubernetes

Thank you for joining me this late in the afternoon. Hopefully, we only have a couple more sessions before we can all head over to the happy hour boot crawl after party. I'm super happy to be here. Nice meeting you all today.

I'm gonna talk about how you can speed up your team by moving your development environments to Kubernetes. My name is Ramiro. I am one of the founders and maintainers of Okteto. Okteto is an open-source Apache 2.0 project. If you want to connect after the presentation and talk about the environments, Kubernetes startups, or anything in between, there's a QR code to my website. My name is hard to spell, but on that website, you can find Twitter, Mastodon, LinkedIn, and other links.

So, okay, we're here to learn together. I'll go through some things. If you have any questions, I will leave some time at the end. But you know, raise your hand, and I'll try to cover them as we go. The biggest benefit of being here in person is having an interactive session rather than just somebody talking everywhere on Zoom.

I have to say, I'm super excited to be here in Tampa. I normally live in the Bay Area, in Oakland. I am from Mexico, one of the few Latinos in Tech born in Mexico, moved to the U.S., and now work for Okteto from Oakland. It's really good to be here; it's so much warmer and nicer. For anybody who's local, congrats, good choice. It is definitely a place I want to visit again. And you know, thanks to Civo for organizing and picking such a cool venue.

So let's get into this, right? When we're building modern applications, what do we as developers care about? Well, we care about our source code. You need code. We care about our IDE, our configurations, our plugins, extensions, containers, databases, debuggers, tests, dependencies, application configuration, infrastructures as code, security, network infrastructure, and many more things. This is something that has been happening over the last 10-15 years. As applications become more complex, the need for understanding all these components is just growing.

And this is a challenge for all of us in the industry. It's a lot, and especially as you scale up teams, expecting everybody in your team to be an expert in these 11+ things is either unrealistic or possible but at the expense of productivity , of talent and specialization.

This is a topic that I'm passionate about. This is one of the reasons why I started this open-source project. Sometimes building complex applications feels like you are writing code, but you always feel like you're going uphill. There are all these other components. You think your code works, then you go to CI/CD and then discover something or even worse in production. This is one of the biggest challenges today, affecting teams, productivity, morale, and they make people really like going back to the previous session feel like an imposter sometimes that hey I can't do my job right.

And as I was saying earlier, this is a problem that is affecting the entire industry. One of the biggest issues here is that engineers are now spending hours just getting ready to what I call "getting ready to work". Somebody adjusts your team or you know, you take a break and then you go back to work, and setting up your local environment in some places is fairly fast; okay, compose up. But in a lot of these places, you have to get dependencies, data, components, all those 11-12 things I showed on the first slide. And each of them takes time, takes attention, takes focus, and creates this frustration that teams are having. It's a topic that I've seen people talk about. Just in this conference, there's like four or five different talks on this topic, so it's something we're all thinking about.

Another challenge is that because we have so many dependencies between components, a lot of bugs are slipping into production. In most cases, development and production start to look very different. I work with teams where dev environments are running on compose on Docker compose, and then production is running on AWS Lambdas or on Kubernetes. This difference means that you effectively have two products: one on a local machine and the one in production. They're so different; there's a lot of issues that you can only see in production. That is not great. This is creating all these issues.

And what, for me, was kind of the straw that broke the camel's back and what drove me to start Okteto was, you go to a company, and every developer has their own way of building a dev environment. Then forget about standardization, forget about policies, forget about not reinventing the wheel. You go to every dev box, and everybody has a script with 15 different things. Dot files, dependencies, somebody's using NYX, someone's using Arkade, somebody's using Minikube. It becomes this hellish thing to support because nobody can help you.

It becomes challenging to support because nobody can help you like each dev environment is so unique that there's no way to get help, and then when somebody new joins your team, they're on their own. And then have, where we, companies, global banks, where it takes months before a developer can be effective because it's just so hard to kind of get started.

And finally, and this is where everything look ends up to, is a bad dev experience. It results on teams that stop innovating, they're only going for the sure thing, and they stop having fun. When developing, and you know, it's a hard job, but if you like it, then you do ambitious things, you do extraordinary stuff. But if you're not having fun, if you're not taking risks, if you don't feel safe to work, if you go for this thing, you start building internal tools, you start like just fixing the box on the backlog, and never pushing new features. And this is how companies or products lose to the competition.

At the end of the day, for everybody who works in an engineering team, it's all about shipping value, and the quicker you ship value, the better your team gets at it, the higher the likelihood that you are gonna be successful. And this is the case on early stage startups, which is where I work right now, all the way to the largest companies in the world. Like, it's the same everywhere.

So, I'm here to talk about how cloud dev environments helps with this. And I always start with this question, right: We're building applications, cloud native applications, that are meant to run on Kubernetes. Why are we not developing there? Why do we have to make this jump from local machines, local processes, to Kubernetes? What if we do the same thing on both sides? And that's what I wanted to show you today.

Cloud dev environments is this new paradigm in development. My company does this; there's many others. Loft, Codezero, 100 presentation earlier today, Virtual Cluster is talking about this a couple of sessions after. It's a new trend where we are moving all these dev workloads into Kubernetes. Different ways of doing it, but what you want to accomplish is a single-click experience, a copy of production, an abstraction for developers not to have to be experts on Kubernetes and infra as code. And finally, the ability to develop, debug, and write code in a way that is a production, what I call a "production-like dev environment," is something as close as possible, and as close as practical, to what production looks like.

And this is what we discuss about cloud dev environment, this is what we mean. Is this ability to just move everything you run in your dev machine, and for some people this means everything from the IDE. In our case with our Okteto project, it's from the code and going forward. And I'll show you in a second how that works, but this is the core idea. Is replace this readme's, replace this local experience, this dev box, with something that is automated, that is defined as code, and that it creates the best abstraction you can for your team and for your needs.

For me, this is where kind of like the key value of cloud dev environments are. This is today the typical feedback loop that a developer building an application in Kubernetes has to go through. You have to write your code, you have to commit, you have to push to a branch, you have to wait for CI/CD to run and build some artifacts. And then, if you're lucky, if you have something like a preview environments, you can see it there. I've worked for very large companies in the past where you have to wait all the way to release to be able to realistically see your changes running on a multi-microservice environment. And this, sadly, is the standard of the industry. Like, we're moving away from this, and I'm very happy that most people now understand how this is terrible, but this is a steel where we see most teams at.

And this is what creates a lot of that frustration I was talking about. You have to go through all this cycle to realize that you had a typo in an environment variable, and that means that your observability is not flowing to Datadog. And that happened to a friend of mine in a very large streaming company, and it's absurd. And then you have to add days and days of work because it's such a long cycle. And that is what we're trying to fight, by giving developers access to all this infrastructure as part of the inner loop.

We want to go from this to something like this, where developers can write code, push it to immediately, talk about Kubernetes, get this very fast experience, be able to create, be able to validate, kind of like shift left as much as you can. And then, once you're done, once you have a certain level of trust that you know things are going to work, then sure, commit, push, go through CI/CD, build your artifacts. There is value in all those things, of course, and then release. But my goal is that by the time you hit that release, you're not kind of crossing your fingers and waiting for this new code path to execute. Like, you should have the certainty that your code is going to work there.

So, enough slides I'm going to show you. This is the application where we use it for some of our demos. We call it the "Boating app". If you've been around long enough, you've probably seen this app in the Docker days. Part of my team used to be at Docker, and they built that app. We then kind of adopted it. It's your typical microservice-based application. It allows you to vote on a favorite item, and then you see the results on the other side.

The application has three services. It's polyglot just for fun. There's a Java, Spring service to take the votes, a Go worker that picks up the votes from a Kafka queue and places them in a Postgres database, and another service - a Node service using Express - that displays the results, streaming them through a websocket to your browser. It's somewhat over-engineered, but it's a way to show people the different patterns you can have with cloud-native applications. The same thing goes for databases and all regular apps, which is something we often see.

Everything is housed in a monorepo because, why not? The whole thing is online. I'll share the link at the end, but if you go to github.com/okteto/microservices-demo or just "demo", you'll see it there. Everything I'll demonstrate today works with an open-source product. We also have a free SaaS if you want to try that out later. For those of you watching the recording, you can find it there.

Moving on, this is the CLI. It's an Apache 2.0 open-source project. It's a binary, specifically a Go binary, that runs on ARM, Intel, Windows, Linux, and Mac. If you like it, please star it, subscribe, or open issues. You download this binary, and once you have it on your local machine, you run either "okteto deploy" or "Oteto up" to launch your dev environment and synchronize your code. For today's demo, we also have a commercial product that I'll use mainly because it has a more visual UI. However, everything I'll show can be done using the open-source project. The commercial product is also free for small teams. This is what dev environment management looks like. I'm going to revert to the repo.

Okteto works using a YAML file. In this file, you specify how to build your application, which artifacts you want to build on demand, and which ones you'd pull from any artifact repository, like Artifact Hub. You guide okteto on deploying your application (in this case, we're using Helm) and how you wish to develop it. The goal is two-fold: Firstly, to have a representation on your repository of what your dev environment looks like so that anyone who clones this repository and deploys the dev environment will get the same images, dependencies, and scripts. Secondly, we aim to use the same artifacts you'd use in production. Although some adjustments might be needed, like perhaps using smaller nodes or a different database setup, the objective is to minimize differences between dev and production as much as is practical.

Lastly, "Dev" is where you mention things relevant during development but not in production, such as code synchronization, hot reloading, remote debugging, or injecting environment variables for specific use cases, like tokens for private npm instances.

Once set up, there are two main commands to remember. Over here in VS Code, I have everything ready. The command is "okteto deploy". This allows for a shared cluster where each developer gets a namespace. This approach ensures that any developer can maintain multiple dev environments across different branches or states. Running on Kubernetes, developers can also share, scale, reset, or destroy these environments, tasks which are typically hard to do on a local machine.

So in this case, I have a namespace with my name. This will create the namespace if needed. Then, I just do "Okteto deploy". "Octet deploy" will redirect the auto manifest, build my images. You can configure Okteto to use BuildKit, to use scanning code, or to use your local Docker daemon. In this case, it's configured to use a remote build service running on my cluster, making it a bit faster. As you can see, it's using Maven, but nothing has been downloaded to my local machine, another big advantage of this kind of environment.

However, cooking-show style, I have another namespace ready. Here, you can see I have another environment up and running. What I showed you before, I have Kafka, Postgres, and my three services, all deployed by just running the deploy command. Looking here, I have some endpoints, SSL-secured end to end. If I navigate to this endpoint, you can see the application running end to end. This looks simple, but it's the entire architecture we showcased earlier - the voting and result system. In this voting scenario, you choose which conference you prefer, "Navigate" or others. Well, since we're at "Navigate" and they're providing drinks, let's cast some votes there.

When I vote, I'm validating that my code works end to end. Clicking the vote button sends a POST request to a Spring service, which communicates with a Kafka queue, then with my worker processor, and finally with a database. It's an end-to-end verification that your code functions as intended.

Visually, I have multiple environments, allowing me to keep different branches. This means I can share this link with anyone. Pull out your phone, go to the link, and vote. We're observing many new mechanics in sharing these environments, in sharing your progress as you code rather than just when you're finished. One of my goals for the next few years is to persuade people that commits should not be the sole unit of sharing. Why wait until your code is committed or until you have a PR to share your progress?

So, step one: I have the environment up and running. I can destroy it when needed. Step two: I'll work on it. This is where the next aspect, "okteto up", comes into play. "okteto up" reads the manifest I showed earlier. It asks you which service you'll be developing. We believe you should work on one service at a time. One core idea is to avoid overloading developers with massive cognitive burdens. For instance, if you have a hundred microservices, not every developer needs to consider all of them. Instead, they should focus on the task at hand. In this instance, I want to change the voting service, so I'll select "vote". Everything else remains the same, but Okteto will apply overrides for the voting service and create an SSH terminal for me, allowing remote debugging, file synchronization, and more. Soon, you'll see it starting a command.

Oh, I chose the wrong service. I meant to use the "result" service because it's Node, which is easier. But you can see how easy it is to switch from one service to another, whether it's Java or Node. It's completely transparent. There are images that have already been built. One thing you can do with Okteto is you can define a container image just for development. In this case, my container image has the entire Node runtime, while my production image only has the necessary differences. This one has NodeMon, the debugger pre-installed, and other tools. So here we are on the result, and if I go here...

I'm gonna go to the other service, you'll see it's still running end to end. I apply more votes, and as you notice, it's changing because it's syncing live. I'm testing the entire flow on Kubernetes. Nothing is running on my local machine. I don't have this version of Node installed. But I can make a change here, for example, change "Navigate" to "ReInvent". When I refresh, I see "Navigate" and "ReInvent". I don't need to rebuild my containers. I'm just thinking in terms of code. It's a simple example, but for many teams using these concepts, it's become the standard of development. It's faster. I can even attach a debugger. You'd see in a moment how it works with my demos.

And when you go through the result, you can debug it step by step. No more relying solely on print statements, which I've been doing for the past decade. This showcases the idea of end-to-end development on Kubernetes, without running anything locally. The same happens with IntelliJ on Java, which is independent of the IDE stack. Just like before, I'll use the vote function. It'll synchronize with the voting service, which is a Spring service on Java. I'm using IntelliJ to demonstrate how well it integrates. What we're building here is a development experience. It has to be user-friendly and flexible. From my experience in open source and developer tools, if your tool doesn't align with developers' actual processes, it's a difficult sell.

In this instance, using IntelliJ and Maven, I'm not reinventing the wheel. You can use any tool you prefer, be it Helm, Kustomize, or Docker Compose. But as before, everything is running end to end. I can also attach a debugger and set breakpoints. Let's see on here when you're posting and then you see it's connected. And then when I post a vote, it breaks. You can see the context, you can make any changes. The one service was in Java and node, this is in Java. I don't have a JDK, I don't have any of these things locally because everything is coming from Kubernetes. Go ahead.

That is, that is a good question. Does it require a custom run config? So, what we're doing here is we're leveraging remote debugging capabilities. So the JVM has remote development capabilities. So if you go... let me see if I remember where it is... If you go to the settings, let's go here... I always forget with IntelliJ where it is. This one? Oh yeah, yeah, right. Yeah, you're right. Edit. All we're telling them is "Hey, localhost and this port." And then in Okteto, if I go back to the YAML...

You see that with Okteto, when I define my development, I told them that for the boat service, I want to forward four to five zero zero five. Same thing would go, it's a different branch, but here for "go", this one's using delve so it's two three four five. And this is using what is now becoming a standard, which is every major programming language now has an interface for remotely attaching a debugger. And this, in my opinion, is the easiest way because you don't have to install any components in the cluster.

One thing that Okteto does, that is very different and for us was also a key design decision, was anybody who has access to a Kubernetes cluster can run this tool. You don't need to be an admin. You don't need to unify the network. If you're going to install the full thing, like you get a nice UI, an admin user, yeah, that's a different story. You need an admin. It's a Helm chart, you put it. But for this flow of like Okteto up, develop, when you're done, Okteto down, that's all you need.

So, this is a quick example of what you can do. We have a lot of samples. If you go to `okteto/demo`, you'll see on every programming language, we keep a list of Dev environments that you can just consume. For some programming languages that we have experience with - Holang, PHP, Python, Ruby, Rust, .NET (because I used to work for Microsoft, so I have a soft spot in my heart for .NET) - they're all there. And what you can see is that all of them are fairly simple Docker files. And this is really all you need to use Okteto.

You define a Docker file. We always encourage all of our users to build their own, so you can customize and put the tools you care about. Some of our users in large corporations have their own custom tooling. They're not using Maven; they have something else because it needs to go through some specific hoops, or they want to use a certain proxy. You can put all that in a container.

And then when you define your Dev environment, here in this case, going back to our file, in this case, I'm just telling Okteto, "Hey, use this Dev image that I'm building." And if you go up here and you see there is an image called build Dev, and you go here and there's Dev, you see that we're using the same Docker file, a different target. There are all these patterns that are emerging from our community. It's not really on us, but the idea is this: it's a microservice-aware Dev environment. Use containers, use your existing artifacts, your existing scripts, and enable things like debugging and hot reloading. We don't want developers to have to build containers every time they want to make a change.

Is that Dev Target require you to install any dependencies that are different from Target that allows remote debugging?

One thing we did, and that's why I really see the value of containers as a Dev tool, is because a container is the interface. That means that you can use any framework you want, any tools you want. Typically, what we see with large teams is they start to build their own templates and their own base images. You want everybody in your team to use the same version of JDK or to be in the same version of Node because you don't want some random developer, like me, to use a five-year-old image of Node. You want them to use the latest. Embedded in that is what we've seen as a really cool emerging pattern: now that everything is "code-first", even for Dev environments.

You saw the demo; I didn't run a single build or Kubernetes command. I ran "oktero deploy" and "okteto up". In our team, internally, we use Okteto to develop. This means that our front-end devs, who are really good at React and those things, they don't have to be aware of Kubernetes. They don't have to deal with pods and those things. But they still develop in an environment that is running Kubernetes because our application is meant to run on Kubernetes. Even in the front end, we always find things that, if we hadn't been running on Kubernetes, would go into production like secrets, environment variables, API calls (is it localhost or the full URL?), HSTS issues, certificates, and all that stuff.

Does Okteto provide this Dockerfile with the multi-stage mode?

We give a sample, yeah, and then this is something you can build. This is a standard Docker. In our commercial product, we utilize BuildKit to build the container. There's going to be a fork of BuildKit that's optimized for our Dev use cases, running on your cluster. It's wholly compatible with anything Docker official. Similarly, we also offer a container registry to push the dev images as you construct them. This is an OCI compliant registry standard. If you prefer not to use ours, you can bring your own. For instance, some of our clients opt for a local BuildKit or Docker because they find it faster and favor its caching mechanism. If you set up a certain variable, you can specify using a local build service over a remote one.

Like most Dev tools, you've got to think in terms of composability and discern what fits where. But that's where Okteto comes in. And I can show you more examples, perhaps with Receptor or another tool. I genuinely urge everyone, especially those on a Dev team or those diving into Cloud-native solutions, to start exploring this new paradigm of cloud environments. With a myriad of tools, diverse opinions, and multiple methodologies available, it's a game changer. From our observations with teams ranging from a handful to thousands of developers in our community, the enhancements in performance, usability, and the sheer convenience of self-service is really cool.

Just to dinish, everything I've mentioned is open source. If you're inclined, you can try it out. The question at hand: should I transition my Dev system to Kubernetes? By now, you might be contemplating it. Even if you're not wholly convinced, I hope you're curious to learn more. And, there's this questionnaire we have, partly in jest but grounded in truth. It asks if you're developing an application destined for Kubernetes, or if you're thinking of installing Minikube or K3s on every developer's workstation. Do you have to teach every developer in your organization to know how to use Kubernetes? Can you run your application plus MiniKube, plus Docker Desktop, plus Slack, or Teams, or Meet, or any of those, comfortably on your laptop? And do you want to reduce the difference between dev, staging, and production? Do you value the time of your developers? Do you pay them to tinker with MiniKube or do you pay them to ship value for your customers?

If the answer is yes to at least one of those, you should definitely move your dev environment to Kubernetes. Or at least look at it. Because there's a lot of things you can gain by doing that. And you might wonder, what's in it? Why would I do it? I've given you a technical demo, but now I'm going to put on my PM product hat and sell you on the ROI of cloud dev environments.

Well, they're magical. It just works. And when it just works, you see a team enabled. But in reality, you're able to get a full dev environment up and running in seconds. That alone, thinking in terms of onboarding or working in different projects, is great. If you work for a consulting company with multiple clients, or if you're changing branches, or doing PRs, it's beneficial. It gives your laptop a break because you're running most of the workloads on your cluster.

Something I didn't show here is our hybrid mode. You could run all your services locally and then run all the heavy databases on your cluster. If you're using something like Elasticsearch, Redis, Postgres, or any other database, you could enable a hybrid mode where something runs on Kubernetes and other things run locally. So, you don't have to carry this weight. Where are you getting your data from? Okteto or any other player in the space can help with this.

With environments that mirror production, thanks to running on Kubernetes, developers can leverage various tools. For instance, Viktor from Outbound and I discussed at KubeCon how tools like Crossplane and Okteto can be synergized to create environments comprising containers, AWS databases, and external infrastructure. You can achieve similar results using tools like OPA or KubeScape. All these tools operate within the Kubernetes ecosystem, enabling you to integrate them for Cloud-native, production-like dev environments.

Empowering your developers with these tools before deploying to production.

Your team will experience faster onboarding. I've been meeting with CTOs and engineering founders of large companies. There's a correlation: teams that care about onboarding time tend to care about the full dev experience. When you join a team with a great onboarding experience, you feel better. A company like Darkly aims for every engineer to deploy to production in their first week. If it takes weeks to provision an environment, you can't hit this goal. But if developers can use one command, and a few hours later have their environment ready to tinker with, that changes the game. And to me, this is fundamental for collaboration.

You can collaborate as soon as you write code. I showed you a demo where I changed a line of code and saw the results immediately. That URL was live, and anyone with access to my cluster could see it. This is valuable when involving other personas in your reviews, like PMs, stakeholders, customers, and your product team. PRs are typically just for developers because you only see the code. But if I can send you a live link with my changes at any time, and you can see it on a Jira ticket or any other tool, that becomes invaluable as organizations scale up.

Organizations overhead because, rather than having one cluster per developer or a thousand MiniCube instances that you have to hire someone to maintain, train, and troubleshoot, you have a few dev clusters. You give a developer one or as many namespaces as possible. Kubernetes is really good at running workers at scale, and bin packing for dev environments is relatively easy.

In our SaaS, we have hundreds of clusters, and we host 20, 30, 40 thousand developers. It scales really well. Another advantage is having to troubleshoot again a dev environment that's local. It's not just the infra cost, not just the cloud build versus how much the latest MacBook Pro is going to cost you. You have to train somebody to go and see why MiniCube is not starting. You know, you have a front-end dev that has no clue and no inclination to learn about this Kubernetes thing. They're just like, "Hey, I can't run, help fix it for me." All of this cost adds up. It's not just the infra versus hardware. It's something to think about as well. It's not the main reason, and it should not be the driver, but it's a nice side effect that we've seen in our community as more and more teams and companies adopt some of these concepts.

So, just to wrap it up, how do I get started? If you're thinking, "Yes, I want this for my team, what do I do now?" Well, there are four questions that are good to ask yourselves:

1. Do you care about the IDE? I don't. I prefer to give my teams the flexibility to run their IDE. You saw my demo, I'm switching from VS Code to IntelliJ to Vim to Emacs. Some teams prefer cloud IDE like Gitpod or VS Code Spaces. That is a decision you have to make.
2. How much do you care about parity between production and development? Some of our community members want everything the same: same infra, same databases everywhere. Others prefer a faster, slim environment using tools like LocalStack and container-based services.
3. Do you want to include all dependencies in your dev environment? If you have 100 microservices, do you want to run them all per developer? Some say yes. The largest usage of cloud dev environments I've seen had every engineer deploying 150 microservices. That might seem crazy, but some find it effective.
4. What is your strategy around developers and data? Data is fundamental. Do not give developers access to production. As you move to cloud environments, decide if you want synthetic data like Tonic or real data cleaned up like Browser Dynamics.

As you build your strategy around Cloud events, what ends up happening is that cloud Dev environments become a core part of your developer experience strategy. It's not the only thing that matters, but it becomes a very substantial part. As teams perceive the value of tools like this, they start using them a lot more. You'll see teams that develop exclusively on cloud environments, and they no longer care about the local experience. This doesn't apply to everyone; it depends on the team and a lot of factors. It's something I've seen happen multiple times at well-known companies.

There are a few products in this space. I showed you Okteto today, and being its maintainer, I'm biased, of course. But there are many others in Devspace. Devbox from Jetpack, which uses Nix and has a different approach but also automates deployments. There's Okteto CLI, Telepresence, which is more focused on how you trick the network. Then there's Scaffold, which I think is like the granddaddy of them all. I have strong opinions on Scaffold. I don't like having to build things. But if you prefer traditional build and deploy automation, Scaffold is great. There are other tools too, but these are the five I've used and like the most.

From the commercial side, there are solutions like Gitpod, Jetpack, and Loft. Richmond Loft is giving a talk, I think, right after this one. Okteto, as I showed you, has an open-source product but also an end to end commercial solution. There was a talk by friends here from Code Zero, another commercial solution. Check it out. The four questions I put at the beginning are important because you need to figure them out. Then you can decide which solution is best for you. It's a new environment, a different environment, and a new ecosystem. There's a lot of innovation in this space, so choose what works best for you.

If its about Okteto, I'm happy to talk. If not, know that all these solutions have growing open-source communities. From Discords to Slacks, they're in every conference. I'm super excited to see how the experience and Dev environments are becoming topics at every conference. From DevOps all the way to Re:Invent, it matters a lot. As our applications become more complex, all of us need to solve this problem. Relying on every developer having a makefile, a readme, and a dev.sh isn't effective. Sure, you can do it, but it's not efficient.

If you're considering implementing this, most of us are about building. But if you can, don't build it. Most companies don't benefit from building their cloud Dev environment. Think about it. We've put together a guide, and I did a webinar with friends from Replicated last week. Building these solutions is challenging. If you want to create an exceptional experience, find a good partner, whether open-source or commercial. I'd recommend not starting on your own.

Thank you. If you enjoyed this, please like and subscribe. You can scan my QR code if you want to chat. I'll be around until tomorrow. Do you have any final questions? I know we're running out of time.

It is an edge case. In such scenarios, I believe you still need a local experience. Treat it like any production service. Have an SLA and maintain more than one Dev cluster. With this approach, it becomes an internal production service. Thus, you should treat it with the same protection and care as your production services. Deciding whether to invest in a local solution is a choice you need to make. I don't find it worthwhile. Sure, downtimes may occur, but having dual solutions means your code needs to make assumptions for both development and local scenarios. We've seen cases where a few hours of downtime is tolerable. For instance, AWS goes down occasionally. Do you build your cloud service as backup? Typically, you just wait it out. However, this is subjective, and every team has its viewpoint.

Lastly, we're hiring! If you're passionate about this topic, visit oktetol.com and explore opportunities. Thank you very much.