 ready. Hey, everyone. Thanks for joining us. As you can guess by the slide, the theme of this talk is going to be Western. So I don't know how many of you are into Western shooters and all that stuff. But our talk today is going to be about improving the cloud native development experience. We look at the good way. We look at what bad stuff is happening, which is not good for developers. And then we'll introduce you to the Kubernetes cross plane way, which is the Western style our presentations are on. Hi, everybody. My name is Ramiro. I'm the CEO of Co-founder of Octeto, being part of the cloud native community for a very long time. Very excited to be here as part of this beautiful event and excited to share what we've learned about the experience with all of you. Yep. I'm a developer experience engineer, coincidentally, at Octeto. And I'm also a CNCF ambassador. So without further ado, let's just start. And I want to keep this session interactive. And I know we can't talk, but give me a raise of hands for those of you who know what development experience is. OK, very few hands. How many of you know what user experience is? So many more hands. Cool. So we know how a user experience is like for apps we commonly use, like Instagram or Twitter. We know how the Twitter user experience declined since some events happened. But user experience basically refers to when you use an app, like how easy it is to use, how intuitive it is to understand what is happening. And if you can just do the simplest things, like if you were to post a photo on Instagram and each time for posting a photo, it asked you to log in. That would not be a good user experience. So development experience is kind of similar to that, but replace users with developers. So it's the experienced developers go through when they are developing applications. And this is defined by a lot of things. It's not one single thing. It's defined by what OS you might be on, what IDE you are using, how your environment is set up when you start developing, what things you have to launch. Are you using Docker Compose? Are you running locally? And all of those things make up development experience. But development experience is not a single monolithic idea. One of the things we've learned by working in this space for a very long time now is that you need the same way that you on user experience, you need to understand your users. You need to understand who you are building your developer experience for. In this talk, we're going to be talking about two of the main roles we believe are important when thinking about a cloud native dev experience. One that we call Cindy Lopez, the platform engineer. We can call it the platform engineer. It can be an architect. It can be a DevOps engineer. These people care about automation as a product. They want to make sure that their teams can very easily provision modern infrastructure, full stack environments, but in a self-service controlled manner. The other persona that we'll be covering today is what we call a developer, David. This is your full stack developer. They care about building cool apps. They want to use the latest technologies. They want to be able to go as fast as possible. They want to have very little friction. They don't want things to get in the way. They don't want to stop for process. They don't want to stop for approvals. And they want to be able to focus on the work. They don't want to go to meetings. They don't want to go through several steps to get things done. They want to sit on their desks, focus, get on the flow, and ship cool things for their users. So those two are the roles that we believe are very important. And you'll see them as we go through this. Yep. So throughout this talk, Ramiro is going to play the role of Cindy Lopez. And I will be developer, David. And we'll just approach this development experience and platform engineering thing through that lens. And fun fact about developer, David, is that he made his job, his life, and that's why his name is developer. Do not take inspiration from him, but let's just see how this goes. I'm just today. It's clear I'm going to be wearing my platform engineering hat so you know who is who in this talk. And I'm losing hair, so you already know I'm a developer. They hope I look good. So let's study this with the example of an application. So this company we both are working at is a restaurant company. They have a taco shop. And this taco shop application has a couple of microservices, right? So there's the main UI where customers can go and order tacos or any other food they want. Then once they order, it goes to the queue, to the cooking queue so that the chefs know what to make. And once everything has happened, we generate a bill. Now, Mr. Platform Engineer is going to tell us about how this application looks behind the scenes, what's the architecture like. There's a beautiful application. It serves our customers well. And this is how it looks like real on the platform, on the infrastructure. It's what we believe a very typical cloud native application. It has three microservices as I showed. One for the menu, you put your orders. One for the kitchen, where the kitchen staff can pick up the order and cook it. And then there's a check service so we can charge our customers. It's a very modern application. We want to make sure that our taco operation scales as much as possible. So it uses cloud services. In this example, it runs on AWS. It has an SQS queue because it's an event-based application. It can scale rapidly up and down. And we have S3 bucket to store all the checks because we want our accountants to go after that later and make sure we charge people the right amount. It's very modern. It has microservices on a monorepo in this case, databases, cloud services. And we use DevOps tools. We use Terraform, Helm, Argo to get this from in our source control into production. This has been working for a while. It works really well. And it's getting us a lot of revenue in our very successful taco operation. So how does the experience for this application look like when I want to develop it, right? Like, I am a developer. I do not like cloud consoles. AWS UI already feels scary to me. I do not want to go ahead, learn Kubernetes. So how do I go about, like, you know, maybe I just have to make a simple change on the UI and change the name of the shop. How do I do that, right? And if I want to test something more complex, like I want to see if there is a pop-up button once the bill is generated, I need something, right? I need that queue to be working. I need that bucket to be created for me during development. Otherwise, I will not be able to develop my app in a realistic manner. So these are the things which have broken the traditional development experience where everything was just a monolith and you would run the command and everything would be up and running. So it is these shift to microservices and cloud services and all of that which is asking us, which is asking organizations for an improvement in the development experience and that is why more and more orgs are realizing the need to invest in platforms and platform engineering teams. So as a developer, my needs are that I want to be self-sufficient without having to repeatedly context-switch. What does self-sufficient mean? Self-sufficient means that when I want to create that S3 bucket, I do not want to run to the platform engineer. I don't want to run to Cindy and ask them to create that bucket for me each time, destroy that bucket, download the to-dos or download the bill generated on that bucket. And I also don't want to do them myself because that would mean I'm context-switching a lot. One minute I'm writing code, next minute I'm going to the AWS console and creating things. I don't want to do that. I want to be able to focus all my energy on the code I'm writing because it is well-known that the more context you have to switch, the more tired you get, right? And developers want that. And they complain a lot. They want to be focused. They don't want to do any of the real work because we need more than just that. Dev environments, sure, they're nice, but we have a large company. We need to make sure that rules are followed. We want to make sure that our environments are standard, that they are governed, that we have the right policies in place. We want to make sure that when developers create cloud resources, they have the right labels that when a microservice is deployed, we want to make sure it's deployed in the right cluster with the right size, with the right information because we are building this large orchestration. Our clusters are connected to observability tools, to telemetry, to cost control, to compliance systems and every time a developer spins up something that is missing one of these keys, it just creates more work for me. And that is just not good. Developers should be the ones bearing the brunt, not us platform engineers having to be there and baby seed and check every environment by hand. That is just not modern. So let us look at what a bad development experience looks like before we can understand what a good one is. The first thing which makes development really hard is when your development environments differ from production. Now, this can happen if your developers are developing locally, but people think that once we switch to Docker Compose and developers are doing Docker Compose up, so now they are running in containers. So now, see containers in Dev, containers in Prod, it's the same. No, it's not. You're using Kubernetes in production, you're using Kevano, Open Opa, whatever. There are millions of other tools which add configuration to the application in production, which are just not there during development. And this is why you want your development environments to be exactly like production, because if they are not, you will not catch these things early on in the cycle and then you would have to wait until staging or CI to catch them. So that is the first problem. The second problem is expecting developers to be experts in Kubernetes and AWS and GCP and whatnot. That takes a huge cognitive load, because developers already have a bunch of JavaScript frameworks to keep up with. And adding more cloud things. As DevOps engineers, we often joke about that CNCF landscape and how scary that is. Now, imagine how scary that is to someone who's like a full stack engineer who has just been developing apps and not introduced to the platform side, right? So it is not fair to expect developers to be experts in these areas. And what is not fair is having platform engineers have to manually monitor a JIT app board, have engineers file tickets, and then we have to manually go and create resources every time and then go and check, is the resource done? Can I delete it? When? And it's just not fair for anybody. It creates a lot of overhead. We're busy. We're doing really cool things. I'm writing Jamel, creating amazing things. And this is just something that gets with my day. And it's not enjoyable. It's not effective. And creates a friction in our development process. So the example of what bad experiences we are seeing out there. So now let's talk about what a good experience looks like. Because there is a lot of good stuff that we have been built over the past 10 years of this cloud native movement. The first is that continuous integration and continuous delivery is no longer a new thing. It's now boring technology that we all just always use. Now we have fully automated the push to production. We have Jamel. We have tools to automate the definition, the delivery, the monitoring. We can put this on something like Argo. It just runs there. This is beautiful. It's easy. And it's one less thing for us to do. If you've been on this space 10, 15 years ago, a lot of this was done by hand. It was very easy to get it wrong. It would fail all the time. SSH-ing into a VM was a thing. We're way past that. So that is great. That has created a great experience. The other good thing is that now we have, because now we know how to automatically deploy these environments, multiple environments with multiple responsibilities. You have staging, test environments, reproduction, integration. This ensures that the teams can take their changes, put them in an environment, test them, and they don't have to wait until production to realize that the code they wrote didn't work. Which, take my word, it happens more often than you would think. The third thing which we are doing good is that we are leveraging infrastructure as code tooling. While that solves part of the problem where you don't have to go to AWS to create all of those things, you have them as code and you can run those scripts, that still does not solve the full puzzle, right? Because these infrastructure code tools are also something platform engineers or DevOps engineers are experienced with. Whereas if you ask a developer to run Terraform or OpenTofu scripts these days, you can't expect them to debug those error messages. And I know that I'll always come to Cindy whenever I see an error message because I do not want to deal with that mess. So there are some good things, some bad things. Now we want to introduce you to the Kubernetes cross-plane way, the way which makes things fun for both developers and platform engineers. So the benefits for a developer is that you get a consistent and self-service environment. Keywords being consistent because now we are using Kubernetes and cross-plane and other similar tools which you already use in production. So you are exactly able to make sure that your environment is like production. The problem with Docker Compose or something like that is that while you're still running containers, right, you do not have the surrounding ecosystem. Maybe you're using Helm to inject environment variables in prod. You cannot do that and you have to maintain two separate files for that and that just takes a toll. So if you're using Kubernetes for your development environments, you get consistency between Dev and prod. And the other key important thing when you're designing a platform by this way is that it should be self-serviced. I should not have to go to Cindy because I don't like talking to her. Each time when I want to create an environment, each time when I want to develop, it should be a single command or a click of the button which should get me my environment. And I don't want to talk to developers either, but I do want to make sure that everybody is using the same set of tools, configurations, policies. We spend a lot of time crafting this to make sure that it suits the standards in production, to make sure that they work. When developers are using some other tooling, one, they don't benefit from all this good work we do, and second, they don't know if it's gonna work. Many times you have developers saying, hey, it works on my machine, and then we go to staging, we go to integration, and because they forgot that we have policies and standards, the code didn't work. So that's why it's very important that everybody uses all these standards, all these configurations across the entire software development lab cycle. Not just in production, not just in integration, but all the time from dev, all the way to shipping our code. And even more important, by moving all these environments to Kubernetes crossplane, we don't have to support thousands of homebrew development environments. One of my friends used to work at this company, and she wrote this huge bash file, 10,000 lines, that then developers have been thinking with as a way to build containers and run and pretend that their laptops is Kubernetes, a mix of kind and Docker compose, and God knows what. It worked most of the time, but then she left. And now we have this homebrew system that no one knows how it works. There's no support, there's no community behind. It's just this file that it works sometimes. So not great. Easy to build hard to maintain. Very true, very true. So, this is the way. We're gonna show you the Kubernetes crossplane way of doing things. In the previous talk, now we're gonna show you a bit of crossplane, talk about how you can use it to create pretty much everything you want from deployments to idly to dev environments. So today, we're gonna deep dive into how that looks like. Yeah. So we're gonna mimic how developers harass platform engineers and how platform engineers can save the day and show them the right way. So the setup for this is that I'm a new engineer and I've joined this taco shop company because I've joined as a AI prompt engineer and I want to develop this application. And the thing is, I am not very familiar with Kubernetes. I'm not very familiar with different cloud providers. I'm an expert on JavaScript and TypeScript. So I need to get this application up and I come to Mrs. Cindy here and Cindy, can you please spin up this infrastructure thing I need? I've been told I need to go and create some things in AWS. Can you give me our production AWS credentials? Wait, wait, wait, no, production, AWS. No, no, what do you need again? What do you want? I think there's some bucket and some queue I need to create, but I need to go to the console. So please give me the password. Passwords, yeah, and then you're gonna put it on GitHub and push it to Twitter or something. No, I didn't tell you why I got fired at the previous company, right? Yeah, no, I don't want you to get fired, but I want you out of this way. So you know what? I've been reading about this project called Crossplane. I think it's gonna be good fit here, so I'm gonna help you. I know how the application works because we run it in production. I know that you need an SQS queue, an S3 bucket, a namespace in Kubernetes, Helm charts, and a bunch of microservices. But let's start with the cloud infrastructure. So Crossplane is an open source project out of CNCF that allows you to automate the creation of pretty much anything on Kubernetes. There are three main elements of Crossplane. The first is the composition. The composition is this Jamel, beautiful Jamel file where you define the abstraction for your users. In this case, we have this abstraction called SQS with bucket, where we tell Crossplane that whenever we create this, what we want to create is an S3 bucket, you can see it here. We want to create a SQS queue with a given name with certain configurations and we specify which AWS account, which region, all those things. And at the end, we give it a name called Infra because I don't want developers to wonder about SQS, S3, and do the wrong thing. They create Infra, Crossplane creates the right thing and we're all happy. That is the first component. The second component is this thing called a composite resource definition. This is the API of my platform. This is what I define, what parameters I want to control and what parameters I want to allow developers to pick because they do need to select certain things. In this example, we have two things. We allow them to specify the location and the name, the name of the resources and where it's going to be deployed. However, for location to keep things simple because AWS has a lot of regions and we don't want to end up with Infra in the wrong place, I'm going to limit it to two, EU and US. If you go back to the compositor, you'll see that here, we have a map where we translate EU to a very specific unit AWS and the same for US. So once you have those two things... Do I create a Gira ticket? Once you have those defined? Once you have that, no. Once you have that, you have this Jamel where the developer defines what they need and that's all it takes. So let me show you how that works. Wait, you're saying no Gira? No Gira. No Jamel. No developer bothering me on my day. All good, all good. How will I dump all of my work on you then? So here, we have this demo, so how does that work? Well, now I have my Infra file, so all I need to do is... Would you increase the font size a bit? I'm going to create a name space for you, David. Already exists. And we're going to create the Infra. I'm going to go here, copy my Infra file. I have a sample here, that's easy. And once you have set up crossplane, all you care about that is that Infra file because all of those settings, once done, it's just configured once and leave it. In this case, you see that the Infra was created? You can create that on any name space. This is like any other Kubernetes resource. And behind the scenes, crossplane is going to talk to the AWS API and is going to create all the resources needed. The good thing about this is that we're building a golden pad for developer David. He doesn't have to think about how to do it. He just follows this automation we wrote and everything will create it in the right place, in the right account, the right size, the right label. It's amazing because one thing that I told you before is that golden pads do make it easier for developers to work, but they also make it easy for developers to go away and leave me alone. So everybody wins here. So you now have your SQS queue, you have your SQS bucket, you have your Infra. What else do you need? Well, you have created these buckets and queues for me, but do you see me writing code? No, right? Because my application still needs to run. All of these resources have been created, but where is my application running? Do I run it on my local machine? If I run a Docker compose, how do I connect it? What do you want me to do? Why can't you solve all my problems? Yeah, yeah. Okay, solve all your problems. Yeah, and I'll also cook you dinner and wash your clothes. There's no crossplane plugin for that for now, but maybe one day. Okay, yeah, yeah, you're right. So what we're doing in this company is we're moving our dev environments to Kubernetes. And this is very important. We don't want it running locally because we want to be able to have them standard, controlled, and fully automated. So I really created a namespace for you. David, that is your space. Now I'm gonna deploy your application there. We have Helm, we have containers, we have policies. We want that to be the same as production. So it's gonna run on Kubernetes. Cool thing about this is that there's a lot of open source projects that are helping us automate this. Scaffold, Tilt, Deadspace, Oktero. I happen to be a maintainer of Oktero, so I'm gonna show you how to do it with that tool, but every tool has its good things, its bad, and it's Kubernetes ways, so pick your favorite. So in this case, with Oktero, you have another beautiful YAML file where I tell the tool how I want to deploy your environment. How I'm gonna deploy infrastructure using crossplane, how I'm gonna create secrets that are needed for configuration, and then how I'm going to deploy Helm. You don't need to care about this. This is for the platform teams. For you, a single command. The deploy. A single command, wow. You put your name. Maybe I don't hate you that much now. That's all you need. One command, and it runs. And what's gonna happen is that this tool is gonna deploy your dev environment in Kubernetes. It's gonna look like production, it's gonna use the same configuration, it's gonna use crossplane, all those things. And what's really cool is that once this is up and running, you have your own environment, with a URL that you can share, and if you wanna try things, if you break the services, you're not gonna break staging, you're gonna need production, you're only gonna break your own instance, which means that you can focus on that, iterate fast. With this tool, you can synchronize code, you can do remote debugging, you can do the same thing you can do on your local machine, but faster with more resources because you're in the cloud in Kubernetes, and benefit for us is standardized so that everybody works the same way. So it's running, it even puts you here with URL to go. So if I take this URL, click on it, you can see that we have this specific environment for you, David, on the QDA cluster, ready for you to work, and this is the actual application. So here we can have, let's say we're done, let's celebrate, we're gonna get two Lassies, and maybe some candy, because why not? I click order now, this is exercising the full flow and now it's ready for you to take it, go away, and develop whenever you want to. So remember, octet deploy. That's all you need. One single command, I'm sure you can remember that. Yeah, please just write it in the read me for me. So that's the whole idea, this was what the talk was about, we want there to be one single command or one single click of a button which deploys the entire application, and now that this application is deployed, any code I write on my local machine will get synced with the code running in the cluster. So there's a file synchronization service, and I'll be able to instantly, I'm not kidding, instantly see my changes as soon as I hit save. So it's just like Docker compose, but where your containers are being run just like they run in production on a Kubernetes cluster, and you apply the same configuration, the same policies. If you look closely, we were leveraging the same Helm charts you might be using to deploy to production, and it's not just Helm, it could be customized, or just basic emails, whatever you're using, you can use that and create an environment which is just like production. So this was it, thank you for attending our talk. If you have any questions, we can take them now. I don't know if I have a microphone or if not we'll repeat the questions. All those developer will try to run that command, so each time that intra will spin up, so that won't increase the cost, so how that will be dealt with. So your question is, if you have a lot of services, yes. What happens, right? And developer is working on those services, and each time the new intra will spin up. There's different models you can follow. One of them is, you can have every developer spin up the entire orchestration of services. We've seen users of OCTEDO, our open source project, deploy 10, 50, even 100 microservices. Kubernetes makes it easy. If you set up your requests and your limits correctly, it makes it easy, like Kubernetes was built to run in fat scale. One advantage of these environments is that they're so easy to deploy and destroy that it's not like you're consuming all the infrastructure all the time. That's one model. You can use and both OCTEDO, Tilt and SkaFold, they all support this. The second model, where you can run the full environment in a staging environment. You can run some things locally and some things on your specific namespace. And you can use things like Istio or Envoy to kind of send traffic from your service to staging and back. There are different ways to build this experience. The key here is to understand, going back to the initial slides, your team, what do they need? I prefer to deploy everything on a single namespace because it's just simpler. You don't have a dependency on shared services, but that out of course, time constraints, budget constraints, resource allocation constraints that we have to think about. As well, like all of these open source projects are building it in like this kind of multiple, like kind of choose your own adventure. You can run one service locally, the rest remote, all remote, a mix. It's really up to you, but I've seen run at a very high scale on very well-known companies without like many issues and a super affordable price. That's one of my favorite things about Kubernetes is you can really run super high scale with not that much overhead. So I think we're out of time now. Thank you so much for attending and being a wonderful audience. We were afraid our jokes would bomb, but you guys supported us. Let's take a selfie to show that we actually don't hate each other. So everybody say Dev Experience. One, two. That's a big word. Dev Experience. Thank you so much. Thank you.