One of the core promises of microservices is development team autonomy, which should, in theory, translate into faster and better decision making. But sometimes, this theory doesn’t translate into reality.

Why is this the case?

There are a multitude of reasons for microservices not working well. Microservices, cloud-native, and Kubernetes are a new approach and culture shift, and there’s a lot of good ways and bad ways to approach the challenge.

One of the keys to success is enabling a consistent developer experience for each microservice from day 0, which is critical for unlocking team autonomy and development velocity.

Bootstrapping a Microservice

Creating microservices should be cheap and easy. This enables app dev teams to quickly build and ship new microservices to address specific business needs without being encumbered by preexisting code. At the same time, this agility and flexibility do come at a cost — applications become distributed, dynamic organisms that can be harder to develop, test, and debug.

Better Developer Experience == Better Customer Experience

In a recent Ambassador podcast, Gene Kim spoke about how a great developer experience is critical to delivering value to customers. By creating a great developer experience, developers can ship more code, which results in happier customers.

We’ve seen a similar trend in organizations that successfully adopt microservices: an emphasis on the developer experience. While it may not be a “strategic” initiative in the organization, usually there’s someone at the company who is passionate about creating a great developer workflow and is able to spend time working on continuously improving that developer workflow.

The Microservices Developer Experience

With a monolith, there’s a common application that is the target for the development workflow. With microservices, there is no longer a single common application. Every new microservice requires a developer workflow. Without due care, it’s easy to have a smorgasbord of microservices, all with poor developer workflows. In this situation, velocity actually decreases since microservices can’t be easily and rapidly shipped. This defeats the entire rationale for adopting microservices in the first place, and development slows.

At the same time, microservices presents an opportunity for improving the developer experience. By optimizing the developer experience of each microservice, teams can build the best possible developer experience for the team (and not the organization), and continue to optimize that experience as the application and team evolve.

Developer Experience, Defined

A developer experience is the workflow a developer uses to develop, test, deploy, and release software. The developer experience typically consists of both an inner dev loop and an outer dev loop. The inner dev loop is a single developer workflow. A single developer should be able to set up and use an efficient inner dev loop to code and test changes quickly. The inner dev loop is typically used for pre-commit changes. The outer dev loop is a shared developer workflow that is orchestrated by a continuous integration system. The outer dev loop is used for post-commit changes and includes automated builds, tests, and deploys.

Engineering a good inner and outer dev loop is key to a great developer experience and unlocking the potential of microservices. So how can an engineer help in building a great developer experience?

The Version 0 Strategy

The version 0 strategy involves shipping an end-to-end development and deployment workflow as the first milestone — before any features are coded. A good test of a version 0 milestone is if a developer on a different team is able to independently code, test, and release a change to the microservice without consulting the original team. This implies a version 0 has a development environment, a deployment workflow, and documentation that explains how to get started and ship. With a version 0 in place, the microservices team then begins with feature development, knowing that their ability to rapidly iterate and ship is already in place.

The Version 0 approach works well for a number of reasons:

• The codebase is very simple, so there is no reverse engineering of obscure dependencies, monkey patches, or any other gremlins to get a working environment
• With no features, there is less pressure from external parties who want to implement changes and adjustments to the roadmap
• A great developer experience accrues benefits over time, so Version 0 maximizes the payback period
• Most importantly, version 0 sets the tone for the microservice, which is that developer experience is important!

Version 0 for Engineers

Any engineer can adopt the version 0 practice (and should!). A development team should have full autonomy over a microservice, which includes the development timeline and workflow! So starting with a Version 0 will help the team rapidly bootstrap the microservice.

Version 0 for Managers

Managers can support Version 0 across the organization by asking engineering teams that are creating new microservices to start with a Version 0. As engineering organizations grow, the organization could choose to assign platform engineers focused on development workflows. These platform engineers should not implement Version 0, but instead provide tools, templates, and best practices to the microservice teams on how best to build a version 0. The Netflix engineering team adopted this approach to developer empowerment.

Summary

Every engineer has felt the pain of a bad developer workflow. A trivial one-line fix takes a half-day to complete. Microservices can exacerbate this problem. The Version 0 strategy is a simple but powerful strategy that will help integrate developer experience into your organization’s development workflow.

This article was originally published on the Ambassador blog.