Faster Development for Cloud Native Applications

A guide to speeding up your development workflow on Kubernetes.

When you move to Kubernetes and enable a GitOps workflow, your inner development loop becomes more complicated. You want to move quickly and ship new features faster, but pushing changes to production without previewing them is dangerous and could cause outages for your end users.

How do you remain productive when hours of your day are consumed with waiting for CI to run?

What is the Inner Dev Loop?

The inner development loop is the process a developer takes from writing their code to committing to a version control system, getting it ready to enter CI and ultimately deploying to production. In traditional monolithic architectures, developers would check out their entire codebase and code locally with “live-reload” in their inner dev loop.

How does Kubernetes change your inner loop?

With cloud native applications, developers now have to manage external dependencies, build containers, and implement orchestration configuration, like Kubernetes YAML. All of these pieces add time to the dev loop and make the developer less productive.

With a slow development loop, the developer spends less time coding and more time toiling over configuration scripts and waiting.

Slow Inner Loop: A Frontend and a Backend Concern

Having a slow inner loop can slow down both frontend and backend teams. Consider the following scenarios:

• A frontend developer has to wait a long time to preview new backend changes on a shared dev/staging environment (e.g. until CI/CD deploys a new version to a dev/staging environment)
• A frontend developer must rely on mocks/stubs/virtual services (and the assumptions that are encoded within them) when coding their application locally. They can only verify changes within a target environment by using CI/CD to build and deploy the app there.
• A backend developer has to wait a long time for CI/CD to build and deploy their app to a target environment in order to verify that their code works correctly with cluster-based (or other cloud-based) dependencies e.g. other services or cloud data stores.
• A backend developer must wait a long time for CI/CD to build and deploy their app to a target environment in order to demonstrate their work to stakeholders or a fellow developer and get feedback.

Solutions to Speed Up Your Inner Development Loop

Hire More Engineers

Expanding your team to help build more features can be a compelling solution, particularly if your organization is in its early stage. This can be productive if your products and features are loosely coupled and team members can work without impeding each other’s productivity.

On the flip side, as the organization and the application architecture become more mature, hiring excess developers will ultimately become expensive and only add additional complexity to your architecture. Coordination costs will increase with every developer hired, and you may find your team slowing down instead of speeding up.

Reduce Integration of Feature Work with Mocks, Stubs, and Service Virtualization

By conducting all project work in long-lived feature branches and limiting the integration of dependencies via the use of mocks and stubs, teams can work quickly in isolation. Care must be taken when coding assumptions into these “dependency doubles”, but done correctly the mocks and stubs can become the well-defined boundary for collaboration.

This approach can be a great tradeoff for rapid initial feature development velocity, but it can result in the dreaded “big bang” integrations, with merge problems and code conflicts between branches and teams.

Build Your Own Tools

Sophisticated teams are often tempted to build their own dev tooling solutions. The “build your own” approach is usually particularly interesting because the solution can be heavily customized to specific problems, constraints and target environments.

As the application and team get more complex, though, the homegrown solution will become harder to maintain. Additionally, as teams grow and evolve, it’s easy for bespoke tools to be abandoned leaving your team without a solution.

Adopt New Technologies

Telepresence is a tool created by Ambassador Labs focused on speeding up a single developer's inner dev loop for Kubernetes. Telepresence gives entire Kubernetes teams more efficient development loops. In addition to the fast feedback cycle, it adds additional features that support easy collaboration among team members. You can see it all in action here.

If this is a problem you’ve faced while adopting cloud native technologies, we’d love to hear about your story and how you’ve addressed it. Please drop us a line on Twitter or join our Slack channel to share your story.

Learn More

• Check out Telepresence
• Learn more about fast, efficient development of Kubernetes microservices