Posted on March 09, 2022

Maybe It's Time To Rethink How You've Been Developing?

Cloud-Native Applications Need Cloud-Native Development Environments

We've seen a tremendous change in the way applications get deployed over the last five years. From huge monoliths deployed on self-hosted infrastructure, almost everyone seems to be moving towards a microservices-based architecture deployed on Kubernetes clusters. And for a good reason too!

Cloud and Kubernetes significantly simplified the deployment process and reduced the headache of managing deployment-related tasks. But while we've been busy rushing towards modern deployment practices, I think we forgot to stop and take a look at how we've been developing all this time.

Our traditional ways of development were okay for the traditional deployment methods. But, a change in deployment practices does demand a rethinking of development practices - and it's for the better too! We've all always agreed that it makes sense for the development environment to be as close to production as possible. With Kubernetes in the picture, we're seeing teams struggle to fulfill this. The problem is significantly heightened by the fact that while the pace of deployment has increased, the ability of development environments to keep up has remained unchanged.

Some teams are just not able to provide their developers access to production-like environments during the development phase. These teams then struggle with bugs that often come in notice only after shipping changes and are hard to debug. What makes these bugs particularly hard to fix is the fact that they don't get spotted during development in the first place!

The other kinds of teams we see struggle are those who do recognize that they need to provide developers with production-like environments to test changes, but they've been using ineffective ways of doing so. Their solution often involves building some in-house tooling to provide these environments. More often than not, this ends up being just another "hacky fix" that is not sustainable, maintainable and does not capture the best practices. Some common complaints we hear about such solutions are:

Slower inner feedback loop because of waiting for long CI builds
Loss in developer productivity and high cost of operation because of reliance on staging clusters

Often, full development environments cannot be provided to developers and fit them on their laptops. The old way of having a set development environment that all developers access does not work in a cloud environment.

Remote Dev Environments Change the Paradigm for Developers

So you probably have a hint of what the ideal solution should look like by this point. We need special development environments that replicate production, including all the microservices. Remote development environments are definitely one of the best solutions to these problems.

You might think that a remote dev environment means there's a powerful machine somewhere; you SSH into it and then develop your application using that machine's resources. Well, you wouldn't technically be wrong in assuming that, but modern-day remote dev environments are so much more than this. They still do leverage remote resources, but they give developers easy access to a deployed instance of the application during development. They're extremely convenient, accessible, and offer a wide variety of additional useful features!

Let me explain that more by going over what Okteto's Dev Environments offer.

We use Kubernetes to power all our dev environments so developers can be ensured that what they see during development is exactly what they'll get in production.
Each developer gets access to a personal namespace on a Kubernetes Cluster, and then they can choose to deploy their entire application or any of the particular microservices they might need during development.
Once this deployment happens, Okteto CLI enables developers to connect to the cluster and replace the running container with a "development container". This container sets up a two-way file synchronization service - the code changes made on a developer's local machine get transferred to the container running inside the Kubernetes cluster.
Apart from this, developers also get a terminal that is connected to the cluster, so they can still do things like run tests using this terminal - except that all these actions would be executed on the Kubernetes cluster, so they'll be much faster. This also saves resources on local machines!
Another benefit of using Development Environments is that developers can continue working using their favorite IDEs and tools as if they were developing locally.
Dev Environments enable developers to be productive without being experts in using Docker or Kubernetes. These environments are deployed using the same manifests being used to deploy to production clusters, so they require next to no configuration from developers.

To put it simply, developers can continue writing code on their local machine as if they were developing locally but as soon as they hit save, they see their changes get reflected in real-time on a deployed version of their application. So not only can they be sure that what they see is exactly what they'll get when they push to production - but it's also instantaneous as if they were developing locally!

This also allows teams to have complete control over the pace of development. Development Environments mirror production and can also be set to work with staging environments - they give you complete control over how you want your development cycle to look like while removing all friction from the process!

Developers Love It and Adopt It Across the Organization

So I think you can now start to appreciate why there is a rapid rise in the adoption of remote development environments across multiple organizations. To sum up the utility of Kubernetes based development environments, I would like to quote my friend Daniel from HoneyBook, who recently transitioned their entire dev team to move to using cloud-based development environments:

“Developing for the cloud in the cloud creates a mindset shift that betters how we code”

And it's totally true! We've heard nothing but positive things from our customers who have migrated to these Kubernetes powered dev environments. No need to take my word for it, go check out yourself what monday.com has to say about operating a team of 100+ developers developing using dev environments. And if you want to try out these dev environments, you can take a look at our getting started guide. Or, if you want to know more about how switching to development environments can benefit your team, don't hesitate to book a demo with us!