Cloud Native Computing Foundation Cloud Native DevX Day North America 2021, 30 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: If Your Application is Going to Run in a Multi-Node Cluster, Why Are You Develo... Ramiro Berrelleza

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

If Your Application is Going to Run in a Multi-Node Cluster, Why Are You Developing it in a Single Machine? - Ramiro Berrelleza, Okteto

In the beginning, development was straightforward: You wrote code, you build a binary, and then you run it in your machine to validate that things worked. You went through this a few times, and once you were happy, you would then SSH into a server, copy your binary, and restart a process. Applications have evolved a lot since those times. Architectural patterns evolved from those single binaries into microservice-based orchestrations that span multiple machines. And our deployment toolkits evolved with them: We no longer SSH into servers and copy binaries. We now use sophisticated container orchestrators like Kubernetes and mature deployment practices like GitOps. And yet, we still develop the same way as in those early days. We started okteto, an apache 2.0 open source project, with a clear goal: to help developers go faster by reducing the gap between development and production environments. If your application is going to run in a multi-node cluster, why are you developing it in a single machine? In this presentation, we'll talk about the benefits of moving your development environments to Kubernetes, showcase success stories around adopting this practice, and show you how you can use okteto to make this easier than ever for you and your team.

A

All right: well, this wasn't on purpose, but I also work for octato. That's uh the same company that jacob works at so we'll keep talking about all the wonderful things of uh preview and dev environments.

A

Let me just check this works. All right.

A

A

So um welcome everyone and I'm 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.

B

Excited to do this in front of a live audience. Funnily enough. My last talk was on kufkon 2019 on serverless days, so that was like two years ago in san diego, so so yeah.

A

I'm very excited, and I'm so super excited that we have at devex day. I think it's.

B

We've been focused on the devex world for a while, so 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 on this space. So today my talk is kind of the same line as the talk that the team from influx db gave on if your application is going to run on a multi-node cluster.

B

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 bms containers, kubernetes get ups, we've been moving very fast towards a world where microservices are distributed.

B

Everything is heavily automated, it's meant to scale horizontally and all that stuff. However, if you think about it,.

A

Okay, it's not working anymore.

B

All right, I'm gonna do it from here. uh Development still happens on a laptop, and this is something that, as we at octero talk and talk to more of our customers.

B

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.

B

Docker desktop kind, k3s mini cube, but, as we heard on our on previous talks, there's a lot of like resources invested here, like your application, is not quite like production you're using a lot like cpu and memory, your experience, kind of becomes a sluggish, so no one at the end of the day is like you end up with this deaf version of your application versus production, which is something that is, in our opinion, problematic and- and this is a space I've been working on for a very long time october- started as an open source project around three four years ago.

B

Trying to solve this problem, and 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, has a very large engineering team. It's a very mature um kubernetes shop. They have corners in production, staging full automation, all that stuff, but the dev environments initially were all local developers were using. You know, whatever their favorite tool was docker compose, mini cube to spin up 10, 20 micro services, plus data stores, plus um data, all local, and it's something that it was a challenge for them.

B

They were having a lot of problems around developers, feeling they were not efficient developers having to be experts on their entire stack on everything, from kubernetes container building deployment, all the way to the code, and it was just a challenge for this company- and you know, hours to spin up the environment.

B

A lot of these have 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.

B

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 one that was kind of like the number one concern for this organization was developers felt their machines were very sluggish.

B

They would run all these processes locally and then every time they had to switch from code to slack to you know like their cluster.

B

You know you just take forever and, 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 when we talk to them, and we've talked to a lot of a lot of companies about this, and we kind of were able to summarize what all this like, modern, dev experience looks like and it's what developers are looking for one is they want it to be.

B

Replicable like they want to be able to spin up in a deaf environment as fast as possible, not something that you keep running forever. They want it to be as realistic as possible; they want to. They don't want to have to wait until you know their code makes it to like cicd 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.

B

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 is speed.

B

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 on the stuff that I'll show you today.

B

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.

B

What if we just do the opposite, and instead we make our cuev 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 octet. The company came after the open source project, so we kind of kept the same name, but it's github.com.

B

If you're interested in, like the experience of environments, you know star, follow all that stuff. It's a it's a it's a community effort and and the main principle behind octahedra behind this. This motion is this is what your typical dev uh flow looks like when you're using a local cluster, there might be some optimizations but you're writing code. You have to like build your containers, redeploy them, wait for the image, the image to be pulled.

B

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, within 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 want to test uh test at code change, how many times a day. Are you going to be doing this?

B

If, once you do this, like 50 60 100 times that's hours, waiting for things to build and- and that is the kind of the core problem we've seen kind of going back to developers valuing speed as the problem- and this is one of the big things that octet 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.

B

We know there's a lot of like reusability, reducing this cue 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 octet of 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 of shadow.

B

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 def time overrides. You want to apply on any q application. That's running! You have your api, your front end running on kubernetes and you can just have this manifest telling octet, oh hey, when I'm developing on the api.

B

I want to use different image because I need some tools there, but I want to set up some environment variables. I want a cache for my dependencies very simple and then you run octet up and- and this is kind of what your uh the environment now looks like you have your your local machine with your source code, you have a copy of your application running on a namespace kind of similar to what the influx db team mentioned, and you have octeto synchronizing the code between your local machine and this remote environment.

B

On top of that, you can do things like a remote terminal like changing what how you build and 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 octeto, 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.

B

We've been working on this for about two. Three years now we started the open source project in in 2018. It's an apache 2 project, and this is kind of like the guiding lights for for this project and kind of for this idea around helping developers expand their environment from the local machine to the cluster it has. It works on any kubernetes project.

B

You have this manifest that already kind of show you where you overwrite depth time things, because at the end of the day, no matter how much we want it to be the same, there are changes between um production and development.

B

Another guiding like for us is that with octo, 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.

B

Whatever else your application might have the same as it is on production and- 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 as we invested early on and we'll talk about this uh for lunch with some of you is the ability to integrate other cloud native tools like build kit 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 and cli octator build that you can connect to any bill kit instance.

B

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, um it's all about fast code synchronization. It's the idea that you write code locally.

B

It gets reflected on your remote dev environment in less than a second and you dedicate you write code, see the results, run your tests, whatever you need, but never leave this fast interflow independently of whether you are on your local machine on 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, like hobby projects, you know on their own um all the way to like public companies.

B

I was talking before using this across organizations with like hundreds of engineers, and you know today, I'm not giving a demo, because I wanted to focus more on on the dev experience and what we've learned through the development and kind of like implementation of octet in this 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 add speed, and this is not new. We know this from production.

B

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 in the on the previous talk, you can spin up a multi service, orchestration, 20, 30, 50, server services per developer, with a very small footprint and with like very little overhead. That's something that before could not be done like. I cannot imagine spinning up 20 30 bms on a on b center.

B

It's it's a lot more overhead, but with kubernetes, it's super simple and it's super fast, especially once you get into optimizations around, like pre-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.

B

Number two is that namespaces are a great boundary for most of 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 and kubernetes, which I do hope, eventually, they will also be namespaced, but right now, they're, not so you're kind of stuck with that. But for everything else.

B

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 with octal. We have companies running clusters with like 20 30 nodes, where 150 developers each has a namespace with a copy of the application, and a replication is 20 30 services, so you're talking about 500, a thousand pots, 2 thousand pots running on a cluster, and this is- and this is a gke cluster with 10 nodes like nothing, nothing, fancy, and that's something that to me is it's fantastic.

B

This idea that name spaces are a boundary. They you 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- and it's fast like spinning up a namespace and deploying and bringing it down, is like super easy another finding- and it was really interesting- is that it's not trivial, but it's 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.

B

Racers, of course we're already on the on the cluster. But this idea that the more things you move to your cluster, the more the faster your cycle, goes because you have less things to warn your local machine. Some teams are now using git, pod or coder to even have the cloud the rde on the cluster. It's something else that also it's. There seems to be a trend and not the biggest fan, but there is a clear trend on the market on that.

B

But it's really about like that 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's gonna go, the faster.

B

The experience will go and the more things you can use and one of the questions on the previous um talk was what about data and that's one of the really cool um 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 and snapshots, and um persistent volume claims to do things like a clone on demand of a database. That's running on staging for every developer.

B

This is 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 kind of 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.

B

A lot of us have spent time like building bigger machines. Right you have you order the 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 and memory you can have, but there's no limit to how many pods you can spin up.

B

So if you kind of scale up your dev environment horizontally, where you have every service on a pod across as many nodes as you need and you're kind of 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 parts, are to ten degree right.

B

Millions of pots is not easy, but ten thousand pots, twenty thousand pots, a small, are a lot easier to deal with than 400 500 vms that are gigantic and that you have to rebuild every few months uh I used to work at a classroom 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 like the users of octato every time they doctor up.

B

They rebuild their live environment and it's a new one and it takes seconds.

B

So it's 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 hey 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 cut 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 well.

B

The previous talk we're talking about not everyone needs to be an expert in kubernetes like if you have a frontend team. Why do they care about containers, your devops insurer, your backend team? Maybe, but there are other functions that should not care. So, as you build the experiences, this is very important. It has to be polished. You have to think of the names you're using for your clies, for your verbs for your actions.

B

That's something else that we learned through this process with octet and we're not there yet there's definitely a lot of like things to learn, but I feel like as an industry, we're tracking in the in the right direction and finally I've. um I mentioned this twice, but I want to really really repeat this: a 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 like remote the environments, it has to be fast if it's not fast, no one's going to adopt it.

B

Even the force developers we're 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.

B

So it's really important to really like take this into consideration and kind of like to to wrap things up. This is what this company looks like after they started using the the octet cli.

B

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 uh deploying 20 30 microservices, now with databases having data on databases creating an ingress all that stuff like they just run a command where they will deploy their home-based environment october, gets in the way, and it just deploys everything instantly, including data, and that's a big thing right, because now you're, the environments are like even more realistic, because it's not just the latest code is the latest code.

B

But you have your data. You can test migrations all that stuff.

B

Another great thing about this is that now developers think of the environments as something that is free, which means they can just deploy them turn turn them down. You don't have ever spending time kind of like tinkering why the 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 it's a big productivity gain, because developers are no longer scared to try uh risky stuff because they know that hey.

B

If I break my environment, no big deal the leader, namespace spin up a new one and back to where I was, and that is something that we've seen really on locks creativity, productivity developers. Even in some cases they can launch multiple environments.

B

One per feature you can go from one to the other: it's a lot of really cool benefits, as you kind of move things away from your local machine into this kind of like cluster based dev environments, and in our case I think for us, as kind of like as creators of this open source project, the fact that as people use it, you see them using it every day.

B

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 from the other talk on how you don't you're not going to be able to force developers to adopt tools like those days are gone.

B

You can have your cto come and scream at you and tell you that you have two 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 on your tool.

B

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 uh use octeto for five six seven hours per day, which is like their entire work day, because they see this value and that's something that you know we as a project, we're always looking for people to use it. Collaborate, help us and and we're just getting started like. Definitely.

B

This motion towards remote environments is to me super exciting and we're looking for more people who are excited and want to contribute, and some of the next things we're kind of like building here is a single command. You know, deploy deploy tests, integrate everything together. uh Integration with ides is something else that we built this kind of like early vs code, plugin that some people really like, but there's a lot of work to be done there. We want to be able to integrate with gitpod with coder with jet, with the jetbrain suite.

B

All of that definitely like dev experience is something we are continuing to refine and- and you know, make it easier. One of the big challenges for us today is how do we make this kind of tools available for a non-kubernetes expert audience? You know 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 fast, be faster. That is a challenge because, as as you start building tools like we are expert coordinators, we know what a pot is.

B

We know cube ctl, 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 want to be efficient. I want to go fast.

B

I want to make sure my thing works, so that's a challenge and something we're looking forward to kind of like as our tools and other tools and ecosystem evolve, is to be able to cater to that audience and kind of move away from just experts and- and that takes me to my final point here, which is we're kind of exploring and talking to other teams and other people building similar tools is like what, if you know 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.

B

So that's something else that, if there's interest in the 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 um on this sort of things of like kind of like standardized standardizing, what a dev experience should look like for you know anyone building a micro service based application, a serverless application any of these topics and- and definitely as I talk about um the standards, it's not just octet, there's there's a lot of other companies and open source projects working on this topic of kind of helping.

B

You move your workloads to remote of environments. uh Octet is one of them, but there's also telepresence that we heard of before- and I think um daniel is speaking next on this.