5 steps to bring DevX automation to your company
Get the guide ā†’
āœ•

Announcing the Launch of Okteto CLI 2.0!

I think you'll agree that, as developers, we enjoy innovating and working on exciting new features more than anything else. We'd get some coffee and play some music, and a few hours later, there is a new cool feature to be released! Then we collect user feedback and iterate. It's just a lot of fun, isn't it? I have worked in a few startups before (Elasticbox, Tutum, Docker), and this is how it goes when you're starting a new project - you feel productive! But as the company grows and the application gets more complex, the development workflow becomes full of friction, and fast iteration becomes impossible. What was all fun earlier starts turning into a developer's nightmare of spending long hours configuring things instead of being able to write code.

Our Motivation Behind Okteto CLI

The main thing which motivated us to start the open-source Okteto CLI project in 2019 was how tedious developing microservices had become in the present-day era of cloud-native applications.

Let's say your application consisted of 10 different microservices. You basically had two options:

  1. Either run all these services locally with tools like Docker Compose.
  2. Mock some of these dependencies locally, push your changes and wait for your PR to merge in order to do manual end-to-end testing relying on some sort of integration environment like staging.

The former requires a lot of configuration every day trying to bring up these services and takes away time that could've been spent working on features. It also adds unwanted overhead to your machine to the point where everything gets so slow that you feel frustrated all the time.

The latter makes the feedback loop way longer than it needs to be. You need to push your code and wait for the CI to build your container images and redeploy your containers - all of which take minutes, if not hours. And only after all this can you test your changes realistically.

Long story short, all the existing ways of development led to a huge loss in developer productivity and were frustrating to deal with on a day-to-day basis.

As developers ourselves, we were very well aware of these problems, and we wanted to provide a solution for everyone to develop applications - using the modern way! This is why we started Okteto CLI as an open-source project back in 2019. The project has grown significantly since then and has a lot of active community members. We also just recently hit 2000 stars on GitHub šŸ˜Ž

In case you're not familiar with what Okteto CLI does, let me give you a brief introduction.

Remote Development Environments

As you just read above, while innovation boomed in DevOps and deployment solutions, software development remained more or less stagnant. Our solution to that was Okteto CLI which providesĀ remote development environments that feel like local.

Let me explain this in more detail:

  • AĀ remote development environmentĀ means your containers run in a remote cluster instead of in your local machine - implying everything is faster and takes up almost no resources on your laptop.
  • By "feel like local,"Ā I mean that you can still continue coding on your favorite IDE locally. Your local code changes are synchronized into the remote containers allowing you to see them live on the deployed applicationĀ as soon as you hit saveĀ locally!

File synchronization is a core component of this solution. With Okteto CLI, there is no need to rebuild your container images and redeploy your application every time you change in a single line of code - goodbye to spending time configuring microservices and waiting hours to see what your changes would look like in production.

Okteto ā¤ļø Open Source

Ever since we started Okteto CLI, we knew open source was going to play a huge part in what we do. We spent a lot of time collecting feedback from our community members who belonged to companies of all different sizes because we knew this was a problem almost all companies were struggling with. The feedback we got during the initial phases helped us shape Okteto CLI the way it is today. Some common things we heard post the v1 release of Okteto CLI included:

  • Okteto CLI should be taking care of not just file sync but also building containers and deploying the application. Developers didn't want to write a new set of manifests to deploy their applications; they wanted Okteto CLI to work smoothly with whatever manifests they might be using currently for deployment - be it Docker Compose files or Helm charts, or Kubernetes manifests.
  • Developers shouldn't require any Docker or Kubernetes knowledge to use the Okteto CLI - we already have enough JavaScript frameworks to keep up with; don't add more stuff! šŸ˜› The process should be as simple as having all application manifests preconfigured for developers in Git repositories, and they should be able to build, deploy and develop their applications with a single command.
  • Okteto CLI should be able to power Development Environments regardless of where the Kubernetes cluster has been deployed - be it EKS, GCP, AKS, Okteto Cloud, Docker Desktop, K3s.

What's new in the Okteto CLI 2.0

Today we present to you Okteto CLI 2.0 - where've we addressed much of the feedback we received to date. I don't want to go over the changelog in this blog, but I do want to take the time to point out some really important quality of life changes we've added.

First, if you already have a Docker Compose file, you just need to run the okteto up command, and you will have spun up your Development Environment with your containers running in a remote Kubernetes cluster. It is that simple! We literally reduced the process to one command :)

For Helm applications, or if you need to complement your Docker Compose file with Kubernetes dependent resources, you can configure an Okteto manifest. But this isn't the same old manifest you used to write with Okteto CLI 1.0. The new Okteto manifest has sections to define how to build your container images, deploy your application, and develop on a given microservice.

With the new Okteto CLI, developers don't need to know how to build and deploy their applications. Run okteto up, and it will automatically build and deploy your application when needed before synchronizing your code into your containers.

Finally, the Okteto CLI 2.0 is now a fully isolated client-side tool that works with any Kubernetes cluster, be it Okteto Cloud, EKS, GKE, or even Minikube!

Wanna give the new release a try? Check out ourĀ updated Getting Started Guide to bring you up to speed.

So What's Next?

We not only plan to continue our commitment to investing in open source but, in fact, aim to double down on that promise with the launch of Okteto CLI 2.0. We firmly believe that the future of cloud-native application development is remote development environments.

Okteto CLI is our solution to solving this problem at scale, and open source is at the heart of it. Solving this problem and stepping into this new way of application development requires continuous community support and feedback, which we've been very grateful to receive. With the new release, we also aim to make the contribution process around Okteto CLI more friendly for new contributors to the project! If you too believe that remote development environments are the way to go,Ā join our communityĀ and help us shape the future of development!

Pablo Chico de GuzmanCTO & Co-founder View all posts

Okteto Raises a $15M Series A To Disrupt How Software Teams Develop Modern Applications

We are excited to announce that Okteto has raised $15M in Series A financing. The round was led by Villi Iltchev from Two Sigma Ventures, with participation...

February 23, 2022
Avatar of Ramiro BerrellezaAvatar of Ramiro BerrellezaRamiro Berrelleza

Making Your CLI More Accessible Using Fig

No matter how many times I use kubectl or docker in a day, I just can't seem to remember the exact subcommands and what they do. I often find myself using...

March 23, 2022
Avatar of Arsh SharmaAvatar of Arsh SharmaArsh Sharma