A Roadmap to Cloud Native Development Nirvana

Cloud native technologies have enabled us to run ever larger and more complex systems at scale. Containers ensure units of deployment are neatly packaged and consistent across runtimes. Kubernetes helps ensure these containers are healthy and available to users under different loads. And monitoring stacks give amazing visibility into the performance and behavior of systems.

But as companies poured resources into adopting these technologies, developer experience (DevEx) was often left by the wayside.

Companies are waking up to the fact that while their production systems are more capable, their delivery processes have slowed. “Head of developer experience” is now a common title, and larger companies even have entire developer experience teams (often but not always overlapping with platform teams).

Which begs the question, what should these teams strive for? What is the new gold standard for developer experience in cloud native development? Who do they compare themselves to? And what tools are available?

At Garden, we’ve been thinking about Kubernetes DevEx from day zero, even if it’s sometimes considered a “Day 2 problem.” Based on what we’ve learned and the teams we’ve worked with, we’ve developed a cloud native development maturity model for teams that run on Kubernetes in production. Each level has pros and cons, and teams need to decide what their sweet spot is.

Level 0: You Have No Production-Like Environments (Before Production)

Perhaps you put all your faith in tight API contracts. Or perhaps you’re just not there yet. Either way, you should have all the resources to deploy your stack to a production-like environment — that’s how it runs in production after all.

Now is a good time to think about shifting those resources left and empowering teams to interact with a fully running system in a sandboxed environment.

Level 1: You Have a Single Staging Environment

You have a single staging or user acceptance testing (UAT) environment where changes are deployed before being rolled out to production. This is a great first step, but chances are that the maintenance burden is high and teams are either stepping on each other’s toes or changes are being queued and slowing your delivery process.

This is surprisingly common, and we’ve worked with a lot of very capable teams whose biggest source of frustration is a queued up staging environment. Or worse, one that doesn’t have a queue but rather different versions overwriting each other.

This can be a big bottleneck, and for most teams, it’s worth advancing to the next level.

Level 2: You Have Isolated Preview Environments in CI

At this level, every pull request creates an isolated, production-like isolated preview environment. These environments can be shared with stakeholders and tested by quality assurance (QA) engineers.

A major benefit is that this opens the door to running proper integration and end-to-end tests. These require isolated production-like environments, and at this level you have them.

This is very useful, but your developers are probably frustrated, stuck in endless loops of commit-push-wait. If an end-to-end test is flaky (as they often are), your devs are pushing empty commits to retrigger the pipeline.

If it’s broken, they’re making a best-guess effort at fixing things and hoping for the best. Depending on the speed of your pipelines, entire days can be lost to this push-and-pray cycle.

Engineers may also struggle to write and maintain integration and end-to-end tests, given the slow feedback loops.

Level 3: You Have On-Demand Isolated Preview Environments for Dev and Testing

This is similar to the previous step except creating the environment is shifted one step further left.

Anyone can now create isolated environments on demand without triggering a CI pipeline. This empowers developers to inspect and interact with their systems as they code. What’s more, they can run integration and end-to-end tests on demand, removing a lot of friction from their workflows.

We’re making great progress, but the problem with this workflow is that spinning up the environment can take a while, especially since code changes likely require a full rebuild. You can work around this by shelling into the running service and making the changes there, but that is sub-par DevEx, and changes will be lost if the pod restarts.

This is still an improvement from having to go through CI, but we can do better.

Level 4: You Develop against Remote Environments

At this level, engineers develop against a fully remote, isolated, production-like environment. They make their code changes locally, and those changes get live-synced to the running services without requiring a rebuild or redeploy.

Usually there’s a trade-off between realism and the speed of the feedback loop — but here you have your cake and you’re eating it too.

URLs to dev instances are also unique, so developers can quickly share their work while it’s in progress or take a peek at what others are doing. It’s great for collaboration as developers can inspect resources and logs in other namespaces and help their teammates.

It takes work to get to this level, but it opens the door to some really interesting workflows and empowers everyone on the team with the tools and capabilities that only Ops had before.

This is where we currently are — and what Garden’s DevOps automation platform helps you achieve. You can read more about some lessons learned in my article about remote Kubernetes development.

Level 5: You Develop in Remote Environments

Now you’re doing some really advanced stuff. Everything is remote, including the code you’re writing. You can work from any device, from anywhere, and your entire environment is carefully curated.

There are a lot of really interesting products like Coder, Gitpod and GitHub Codespaces for remote development. But they lack the automation around building, deploying and testing distributed systems and microservices.

Combine the workflows from Level 4 using tools like Garden with remote development tools like Coder, and you might just reach Kubernetes DevEx enlightenment.

Achieving Cloud Native Development Nirvana

Achieving cloud native development nirvana is as much about the journey as the destination, but tools like Garden can make it easier than you ever thought possible to get to the good part.

If you want a shortcut to Level 5, we’ve created an example project with Garden and Coder so that you can use Garden’s on-demand production-like environments and Coder’s self-hosted remote development platform together. This means you’ll be able to develop a system of any complexity fully remotely with instant feedback that feels local.

Empowering your dev team with the same tools and capabilities you already have in production and CI doesn’t just speed up delivery — it spreads enlightenment.

The post A Roadmap to Cloud Native Development Nirvana appeared first on The New Stack.