Hey everyone, I hope you've been having a great time at the conference so far. My name is Arsh Sharma and my session is going to be about making DevOps friendlier for developers. So before I start this talk, I want to catch you up all on what the story has been till now. Like before microservices, cloud and all the fancy stuff related to DevOps started coming into picture where we were. So earlier, people who built applications, sorry, people who wrote application code like developers, were different from people who packaged up the application, which were application builders. But Docker popularized the use of containers and that sort of led us to ask the question that hey, now, the developer can itself, they can themselves package the application in a container. So these two kind of people got merged and basically application building got shifted left. Shifted left means became a responsibility of the developers. Now this led to teams which could iterate much more faster because now, because every time you know that there's a dependency on someone and task has to go from one team to the other, there is a delay. But when you sort of merge those kind of teams, you sort of skip that delay. And this is how we started shipping code more faster. And agile culture came to be the norm in the industry. But this was still separated from the ops people whose primary responsibility still was like managing clusters and doing deployments and all the infrastructure side of things. So developers still sort of were not self sufficient in a sense because they had to rely on ops people. But then came DevOps. So DevOps, the idea was to make developers more independent. The idea was that the dependency for developers on other people should reduce so that we are able to ship features and bug fixes much more faster. So the whole goal was that the Ops team now sets up processes which developers can rely on to be self sufficient. And this is where things started to get tricky because we sort of agreed upon two processes which were CI pipelines, CI CD pipelines and staging environments. But these processes didn't exactly solve what they set. But to let's see how things changed for developers, like with these processes. The problem with both these processes was that development still took place in can environment, which was nothing like production. So in production you have all these clusters and kubernetes running, but when you're developing, you're still developing locally in your editor and bringing up services locally, or even if you went the extra step and ran containers, everything was not exactly like it would be in production. So let's say whenever there's a but in the production environment, and now you have to replicate that bug locally. Developers would call upon ops people and try to spin up local kubernetes, clusters and do all of that. But even then it's tough because you can use minikube or kind or something like that, but you can never get the exact same thing you were getting in production locally. So CI CD pipelines and staging environments have their use. They help you ship code better and faster. But still the use does not come into picture when the developer is writing code, that is, they are far from developer like. A developer would have to commit and push these changes for CI pipelines to come into picture. And same for staging environments, you would have to wait for accesses and a build to complete, and then these things come into picture. But when you're writing code, it's just you and your local environment which is problematic and which leads to the feedback loop. The outer feedback loop got simplified because of CI CD pipelines and staging environments. But the inner feedback loop, which is like when you writing code and seeing your changes, that became longer because now you saw your changes locally on your laptop as you coded them out, but you still weren't sure if how they would look in production, because for that you would have to commit and build them and all that sort of thing. Similarly for Ops people. Also, things did not get that easy, right? Because now, like we said, if there was a bug in production and that had to be replicated locally, Ops people would have to configure environments for each developer so that they can now replicate that bug. And these environments weren't replicable. Sure, you could use something like terraform to have a standard thing spin up, but that's just for your infrastructure, right? Not for your application. So developers weren't that happy. Ops people weren't that happy. How do we fix this is the inevitable question to that. I think the best solution I have found is cloud dev environments. And what these dev environments do we'll soon see in a demo. But the whole idea is that if everything is happening in the cloud like production is there, staging environments are there, CI CD pipelines are there. So why shouldn't your dev environments live there too? Because we as an industry have always agreed on the fact that development should happen in an exactly production like environment. And if that's the case, then why haven't we been moving close towards it? Developers should not have to rely on Ops and infrastructure people every time they need such an environment. And this is why we came up with a solution which was Okteto Cli, which is a completely open source project and this is the problem it aims to solve. The way this problem is solved is that the operations team configures an Okteto manifest, which is just like a one time process. And this Okteto manifest contains all the instructions required to spin up a dev environment. Now that includes how to deploy your application, something which Ops people would have to spend like synchronous calls with developers to do that. Now all of that is in a one configuration file and it's easily replicable and reproducible. So what happens is these dev environment gets deployed in a Kubernetes cluster. So your application, all these microservices are deployed to a cluster and then a two way file synchronization service is set up. So what this means is that the code you write gets synced with the code running in the cluster. So this way you are able to seems all your changes as soon as you make them and you get live feedback. And that feedback is in a productivity like environment. So you know that whenever you build it or push it, nothing will fall apart, right? And even if, let's say there are some bugs, you catch them early on, or if there are already existing bugs, then you're able to replicate them because this environment is exactly like the environment which is there in production. So that was the idea. To make it super clear, I'm going to show you a demo of how this works and I'm going to be using this simple application which is a movies application, which is a movies rental application. The source code for this is at forward slash movies. I have it already cloned and I have Okteto Cli installed. And with octo Cli all you have to do is set a context which is basically the Kubernetes cluster you want to use and deploy to. I'm using Okteto cloud, but you can use any cluster like it works with AWS, Google Cloud, any vanilla Kubernetes cluster. And once you do that, all you have to do is run Okteto up. It's one single command. And this common uses this configuration file which I was talking to you about, which the Ops people said it's one time configuration. It tells how to build all the microservices. So let's say these front end microservice, the context for building that is in the front end folder and there it uses all the existing docker files there are, and then how you deploy all the stuff you need using helm. And then there's a dev section which tells how the development for these microservices should happen like what folders should be synced and all port forwarding stuff is here. So let's wait for the deployment to complete. Once the deployment is complete, Okta will prompt you to choose which one of your microservices you want to develop. Let's just keep it simple in this video and make a change on the front end. So I'll choose front end. But these beauty of this approach is that all of these microservices are now deployed to the cloud and are working together. So let's say if you personally wanted to bring up this application, you as a developer would have to bring each of these services up individually. Whereas with things approach all of them are up and deployed in one single command. So once you select which service you want to develop, what happens is there is a container replacement step. The container running in the cluster gets replaced by a dev container. And what's special about things Dev container is that whatever code we write on our local machine gets synced with the code running in the dev container. So that way any change we make here will be reflected live in that environment which is running in the cluster. So that's how you are able to develop in a production like environment. And to see this, like you see we have access to the terminal in that dev container and we also have access to endpoints where we can visit our application. So this is the endpoint where the front end lives. But like I said, this is running in the cluster, running in the cloud cluster. But everything is sort of like how you would be developing locally because it is still at the end of the day like development which is happening on your machine, right. So to do that you would have to first run yarn to install all the dependencies. So let's just go back to our ide and run yarn like you would locally. So all of this is like locally but all of this is happening in the cloud. And then you run yarn start. And what that basically does is start the server where the application is. And if we hit refresh now, we see that our application is up and running. Now like I said, this is just the application running and whatever code you write will get synced. So let's also test that out. And I have things code already written, I'll just uncomment it which is basically a discount coupon. And if we go back here we see that this thing appears, which is the code we just wrote. If we comment it again, go back, hit refresh, it's gone. So I hope you can now see the beauty of this approach how whatever code we write gets synced, and how the inner dev cycle has now reduced and its dependencies on things like CI pipelines and waiting for builds to complete or waiting for ops people to set up environments has reduced significantly. And developers now are much more independent and much more confident when writing code, because you know that if that code works here, it will work in production, it will work in your CI pipelines and your staging environments. So that's the whole idea, that's the whole goal, that we simplify DevOps by giving developers all the tools to be self sufficient and the ops people only have to be responsible for setting up and maintaining these tools. Going back to the slides, just a recap of all the benefits of this approach is like developers can now get to the code writing phase by skipping all the configuration. Like you saw, we only needed to run octeto up. We did not need to bring up front end by writing yarn start and then bring up the back end and then configure the database and all that sort of microservices stuff. All of that was skipped. All you had to do was run one single command of Tetoap and the environment was exactly like production. The feedback is instantaneous. So as soon as you hit save you get to see your results. Whereas with a CI pipeline you would have to wait a few minutes for all the building and deployment to happen. So the goal is that shipping for the cloud, then you have to develop in these cloud as well, because that is how you're going to make less mistakes and ship applications which are much more smoother and much more cloud native in nature. Thanks. This was it. Thanks for watching. If you have any questions, feel free to reach out to me on Twitter at these razorinkyakidad and I hope you have a fun conference ahead.