Everyone and welcome to Conf 42, cloud native 2022. I hope you all been having an amazing conference so far. In this talk we are going to look at the changes that have taken place in the deployment ecosystem over the last few years and see how they have affected developers. I'm Arsh and I work as a devex engineer at Octeto. I'm also an active contributor to the open source Kubernetes project. So let's get started. In this talk I want to introduced you to Jane a couple of years ago. Jane's life was simple and she got to do what she enjoyed, write code. Most applications had a monolithic architecture and all she had to do was open up her favorite code editor, run a command or two, and she'd have her application up and running. Then she would just write some code, hit save, and see her changes interacted based on that, submit a pull request and things would be good to go. So what happened to our happy dev experience? Containers and kubernetes in the last couple of years, containers made our lives super easy and containerization basically became the norm. Everyone reevaluated how they were structuring their applications. Containers made us realize that instead of working on this one single large application, it is so much more easier to scale an application that is composed of multiple smaller pieces, that is microservices. We also started using container orchestration tools like kubernetes in production to further scale our applications more effectively than was possible before. Now all of this changed these world of a happy developer Jane. Suddenly Jane was having a tough time bringing up her application locally. She could not just now continue developing as she was before. The thing with microservices is that they are interwoven and closely linked to each other. So let's say Jane has to make a change on a particular microservices. The only two options she has available with her are bringing that microservice up locally and working on it. The problem in this case is that she isn't able to see how the change she makes could interact with the other microservices because she hasn't brought them up together. Now this might not be a problem when you're working with two or three microservices, but imagine making a change in an application consisting of 1015 microservices. It is almost impossible to predict how your changes would affect other things if you're working in isolation with a particular microservices. The second option Jane has available is to actually bring up all the microservices and configure things between them so that they all work like the actual application locally. Now mind you that this is no easy task. Jane would have to read and make sense of a bunch of readmes written by infra people or some hacky bash scripts which often break and require debugging. And these readmes and scripts are anyways hard to maintain and keep up to date. And you know what the worst part is? Even when Jane does spend things time bringing up and configuring all the microservices, she still can't be sure that everything would work as it works in production. Reason being that locally bringing up all the microservices is no longer the same thing as how they are brought up in production. Her environments still be won't exactly like the production Kubernetes clusters which run the final application. So what did we do to solve chains wars? We told her hey, work locally on an independent microservice and take these CI CD pipelines. Once you push your changes, we'll run them in the CI against a production environment and let you know if things are working as expected or not. Or we gave Jane access to staging environments where she was like after she was done, she could see her changes brought up like they would be in production and verify if everything is working as expected. But ask yourselves, did we actually solve Jane's problems? No. The workflow Jane was used to was this bring up the entire application she needed for development in a command or two, write some code, see her changes immediately, and iterate, all while being sure that things would work exactly the same in production when she pushes her changes. But the flow we currently gave her is not the same. It is too far from the code writing phase. With this flow, she only gets genuine feedback after she is done committing and pushing her changes. And that too is not instantaneous and takes a lot of time. Like bringing up the environment in CI often takes minutes if not hours if you're working with a pretty big application. So the question still remains, how do we fix things for Jane and make her happy? Before concluding, I want to discuss a solution which has these potential of solving all these problems developers working on microservice based applications face. And that production I feel is cloud development environments. The way they work is that they first deploy your application to a Kubernetes cluster using these same manifests you deploy to production. So the idea is that you deploy your application to the cluster just like you would in production, and then you see the result of the code you write as soon as you hit save to explain this in a bit more detail, let's consider a simple application which has two microservices. Now this is just for explaining like in an ideal world you would have like around ten microservices and things would get complicated. But let's just work with a movies application which has a front end which is interacted with an API. Once you have your application containers running in a cluster, these cloud development environments replace the container for a particular microservice you want to work on with a development container. So if you see the second box, you'll see that if you want to work on the API microservices, we would first deploy both the front end and the API to a cluster, and then we would replace the running API container with a development API container. Now what's special about this container is that it syncs all the code you write with the code which is running inside the cluster. So the changes you make will be moved to the cluster and you could see the results live as soon as you hit save. And the best part is that since this replaced container inherits all the configuration of the original container as well, so the other parts of your application continue to work exactly like these were working before. So that means you are working in an environment which is exactly lives production, and all you had to do was use the same manifests you were already using. How convenient. No? So I think you can now start to see how cloud dev environments solve all the problems we discussed and also provide a better developer experience for cloud native application developers. Con is the problem of developers working in an unrealistic environment, because cloud dev environments use the same manifests as production to bring up your application. Working in an environment which doesn't mimic production is the most common cause of bugs which creep in late in the dev cycle and are hard to debug. The reason they are hard to debug in the first place is that because finding them locally wasn't possible, because if that were the case, they would have gotten caught a lot earlier in the dev cycle. But the fact that they appear later and are tough to replicate locally is what makes them nasty to debug. But if you use the same manifests you use in production when developing locally, then you catch these bugs in your local environment even before you push your changes, and you would have a much easier time shipping features and you can be sure that the changes you push will not have these bugs these second thing is that with cloud dev environments you also get instantaneous feedback like you saw in the previous slide. The code gets synced as soon as you hit save. So you see the result of what you have written immediately. You no longer have to build your application, commit your changes and push them and wait for CI pipelines or just lives. Wait for access to a staging environment to be sure that your code is working. Because once your application is live in a cluster, all you need to do is hit save and then you see the results for your application. Now this speeds up the inner dev cycle, and not only that, but it also gives devs the confidence that what they have written will work in the CI and staging phases. Now I'm not saying that this is like a replacement of CI and staging. Both of them are useful and have their place, but this approach is more close to the developer and therefore it feels just like it was like a couple of years ago when we were not working on microservices and we had these monoliths we could bring up and hit save and see our changes. So it brings back that feeling of getting feedback as soon as you write and not waiting minutes or hours to see how your changes look. The third thing which makes most developers like chain very happy is that with cloud dev environments, devs don't have to spend time configuring things. All the configuration required to bring up a dev environment goes in a single file, and every developer can just bring up the entire application using a single command, which deploys to the cluster and replaces the required microservice container, as shown in the previous slide. So this idea of using dev environments as code makes dev environments much more reproducible and ephemeral. So if things go wrong, you can simply destroy a particular dev environment and spin another up in a matter of minutes. There are other added benefits, like since you are using cloud resources, everything is faster and you no longer have to be limited by the capabilities of your local machine. And the other good part I feel, is that these cloud dev environments do not force you to shift from the tools you've been using. You write code just like you would, except that it's being deployed and run in a cluster. So not only is the process faster and the feedback more genuine, but you do not have to say goodbye to the tools you love, like change your id or anything else. I want to end this talk with a quote which I feel beautifully sums up whatever we have discussed. If everything is happening in the cloud, then why should your dev environments not be there too? Thank you so much for attending and I hope you have a great conference. If you have any questions about the talk or just want to chat. Please don't hesitate to reach out to me.