Sam Newman on Microservice Ownership, Local Development, and Release Trains

In this episode of the Ambassador Livin’ on the Edge podcast, Sam Newman, independent technology consultant and author of Building Microservices, discusses the concept of microservice ownership, explores how to best approach the local development of a microservice-based systems, and shares his opinions on the release trains model of deployment.

Be sure to check out the additional episodes of the “Livin' on the Edge” podcast.

Key takeaways:

• Although the microservices architecture pattern is widely adopted across the industry, the term “microservices” can mean many things to many people. When reading an article that claims microservices are bad or that engineers should be building “macroservices” or “nanoservices”, take time to understand the related terminology, goals, and constraints.
• An important decision point around embracing a microservices-based architecture is that of ownership. With a weak ownership model, engineers are expected to be able to work on any service across the system. With a strong ownership model, small cohesive teams of engineers are responsible and accountable for specific services.
• Weak ownership can be effective at a small scale. Engineers can iterate quickly across the entire portfolio of services. However, maintaining consistent quality can be an issue, and further collaboration challenges emerge as the number of services increases. Local development machines also typically have to be capable of running any of the services, their dependencies, and associated middleware and data stores.
• Strong ownership of services, as demonstrated by Google, can be effective at any scale. With a smaller codebase (and smaller required mental model) engineers can maintain high quality by encouraging others outside of their team to contribute via pull requests. Localized ownership of services typically means that local developer machines are easier to maintain.
• Language choice also impacts local microservice development environment configuration. It is relatively easy to run multiple Python or Go applications. However, only a few JVM- or CLR-based applications can run simultaneously on a single machine. Here tooling such as Telepresence and Azure Dev Spaces can be useful.
• Making it easy to do the right thing and incentivising engineers to make the best choices is key to rapidly delivering business value to customers. Flakey, non deterministic tests can slow down release cycles. And rewarding short-term hacks can encourage developers to not to continuously improve processes and systems.
• Adopting a “release train model” can be a good stepping stone for the ultimate goal of each service within a system being independently deployable. The release train model should not be seen as the end state when attempting to adopt continuous delivery.
• ‍Progressive delivery is a good umbrella term for “a whole bunch of techniques regarding how we roll out software”. Separating deployment and release of functionality is key to being able to deliver value rapidly and safely. Canary releasing and dark launching are very useful techniques.
• Implementing appropriate observability in applications, the platform, and supporting infrastructure is vital to enable rapid feedback for engineering and business teams. Charity Majors, Liz Fong-Jones, Cindy Sridharan, and Ben Sigelman are people to follow in this space.
• Successfully rolling out system-wide log aggregation is a vital prerequisite (and test) for adopting microservices: “If you as an organization cannot do it. I'm sorry, microservices are too hard for you”.
• The Kubernetes ecosystem is very powerful, but also very complicated for developers to work with. Organizations adopting this technology need to take the time to learn new mental models and choose appropriate tooling in order to implement long-standing best practices like continuous delivery.
• Sam’s “Monolith to Microservices ” book provides a number of useful migration patterns, such as the strangler fig, parallel run, and branch by abstraction.