Enabling Microservice Success (Sarah Wells) (Z-Library)

Praise for Enabling Microservice Success It may be cliché to say this is Sarah’s magnum opus, but you won’t find a more condensed and inspiring guide to designing, building, and running microservices at scale than this book. The case studies and hard-won experiences jump off the page and allow the reader to avoid many operational traps that are easy to fall into. —Daniel Bryant, architect, technical consultant, and coauthor of Mastering API Architecture Small, empowered teams with aligned autonomy are a feature of high-performing organizations because the rapid feedback and agility that this setup provides helps organizations to be nimble and responsive. This superb book acts as a reference for what to expect when moving to a “fast flow” way of working using small, empowered teams. I love the emphasis on healthy organization dynamics as a key factor for success with small decoupled services, because ultimately success with any modern technology initiative rests on a humane approach with people, not just technology. Essential reading for any forward-looking organization. —Matthew Skelton, coauthor of Team Topologies and CEO at Conflux This book is packed full of great advice and practical tips to give you the best chance of succeeding with microservices. —Sam Newman, independent consultant and author

Sarah Wells has been building and running microservices since before they were cool, and her experience shines through in every chapter. This in-depth book has everything you’ll need to go beyond the theory and make microservices work in the messy real world. —Tanya Reilly, senior principal engineer and author of The Staff Engineer’s Path Sarah distills the core technical and organizational foundations so that the development and management of microservices can be a huge success. When I get asked what a good microservices design and architecture looks like, I can now say: look no further than this book, which is filled to the brim with practitioner guidance. —Suhail Patel, staff software engineer at Monzo Sarah’s hands-on experience permeates this book, providing readers with invaluable insights beyond the fundamentals of building and deploying microservices. Sarah delves into the complexities of evolving and scaling architectures from both technical and organizational perspectives to enable continued delivery and growth of business value. This makes the book essential for engineers and leaders alike embarking on this journey. — Nicky Wrightson, head of engineering at topi Whether you are thinking about moving to a microservices architecture or have one already, this book is essential reading. Sarah distills many years of running microservices architectures and seeing what works—and what doesn’t!—into actionable steps you can take right now, whatever stage you are at. —Anna Shipman, CTO at Kooth Digital Health

Enabling Microservice Success Managing Technical, Organizational, and Cultural Challenges Sarah Wells Foreword by Sam Newman

Enabling Microservice Success by Sarah Wells Copyright © 2024 Sarah Wells. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800- 998-9938 or corporate@oreilly.com. Acquisitions Editors: Melissa Duffield & Louise Corrigan Development Editor: Jill Leonard Production Editor: Clare Laylock Copyeditor: Kim Cofer Proofreader: Piper Editorial Consulting, LLC Indexer: nSight, Inc. Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea April 2024: First Edition

Revision History for the First Edition 2024-03-26: First Release See http://oreilly.com/catalog/errata.csp? isbn=9781098130794 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Enabling Microservice Success, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. 978-1-098-13079-4 [LSI]

Foreword People who build software have always been busy, but we seem to be more time poor every year. The expectations of our users and the organizations we work for become greater as software plays a more important role in our day- to-day lives. Against this backdrop, the mantra of “shift left” has pushed more responsibility around things like usability, testing, security, and operations into teams that in the past would be much more limited in their scope. I don’t mean to suggest that the dismantling of silos in software delivery is a bad thing. The movement toward teams with more end-to-end responsibility that came to the fore with the Agile Manifesto and was turbocharged through DevOps is definitely moving us to a more effective way of building software. But at the same time, it means we’re asking ever more of the people in those teams who are absorbing all these new responsibilities. With all this going on, it is no wonder that people reach for easy answers. When a bandwagon comes rolling along with promises of a brighter future, better hair, and a more magnetic personality, how can we resist? The issue of course is that so many attractive industry trends don’t deliver on that initial hype, and once the bandwagon has disappeared over the horizon, we’re left with the legacy of decisions made in haste. Microservice architectures are no different—while they’ve been great for some people, for others, they’ve left chaos in their wake. Microservices are simple in concept, but the devil is in the details. There are so many aspects to getting the most out of this style of architecture, while also dealing with the complexity it brings. The problem is, getting the most out of microservices often is about nuance. The development of any software-based system requires people and technology

coming together, and with microservices the people and organizational aspects are often greatly overlooked. People assume the answer must be a new programming language, more Kubernetes clusters, or perhaps a new vendor. But this approach results in an orgy of technological overload that ends up looking at less than half of the story. Most of my work revolves around helping teams navigate this world, and I know firsthand how maddening it can be for people when I’m asked questions and respond with the dreaded “it depends.” In most cases, it’s about finding time to stop and think, to break the problem down, to not follow some dogmatic approach but to consider your own context. That’s all well and good, but fundamentally people are still time poor. So having someone who has seen firsthand how to get the most out of microservices lay out some home truths for you, in the way Sarah has in this book, can really help speed things up. This book is all about the nuance, about the multiple different choices that you’ll face in getting from early adoption to some degree of maturity with microservices. It’s rare we’re offered a binary choice in this space, and rarer still that there is one right answer. But what Sarah does so well in this book is lay out the options and explain the context, giving you information to make the right choice for your situation. That doesn’t mean that this is a book without opinions—rather, it is one where Sarah shares her own view, but still gives you the space to think, reason, and pick your own path. In this increasingly busy world, you might find it difficult to justify spending the time to sit down and read a book. But trust me, if you’re struggling with the reality of microservices, the time spent learning the lessons this book shares will be paid back several times over.

Sam Newman Independent consultant and author East Kent, February 2024

Preface Microservice architectures can be a very effective approach to speeding up delivery of value to your organization and customers. If you get it right. Get it wrong and you can end up with a complex mess that makes operation and maintenance very hard and leaves you with small teams trying to support lots of services, some of which they’ve never touched. Adopting microservices goes beyond selecting an architectural approach. To be successful at doing microservices, you need to make cultural and organizational changes. You have to move toward autonomous, empowered teams. That means that many things that used to be someone else’s concern are now the responsibility of engineering teams. You need to think beyond system design, architecture, and implementation. That includes considering how you will build systems that you can successfully operate in production, and how to maintain and manage them for the long term. You need to understand distributed systems architecture and are likely to be more hands-on with at least some parts of your infrastructure. This book will help you with all of that. It gives practical advice on how to adopt a microservice architecture and how to make sure it still works for you once you are several years in, maintaining and sustaining your systems as they mature.

Why I Wrote This Book The focus of this book is how to benefit from microservices for the long term. I want you to avoid getting several years in and looking around to find lots of accidental complexity, with developers spending their time on things that aren’t providing business value. If you’re already at that point, I want to help you tackle that. I built my first microservices in 2013, and I was still there at the same organization building and operating the same systems eight years later. That means I’ve seen the problems, tried to solve them, and been there long enough to know whether those solutions actually worked. During that time, I’ve worked in product development, operations and incident management, and engineering enablement. That’s given me a wide perspective on how to approach microservices. My aim is to help you get to a point where you are using a microservice architecture successfully and sustainably. Who Should Read This Book This book is for senior engineers, architects, and technical leaders who are moving to microservices and wondering what that means for all the techniques and processes they currently use. It is also for those already using microservices who are struggling with the complexity and want to learn how other people have successfully met some of those challenges. I assume you are familiar with the fundamental concepts of software development and architecture, but I don’t assume you already have experience with microservice architecture.

I won’t spend a lot of time on the details of specific technologies, or stepping through how to do things. There are already books that cover these things, and I will recommend them at the relevant points. This book will focus on practical advice but won’t be specific to any one technology, instead focusing on the principles that will help you decide what tools you need. If you’re new to this architectural style, Chapter 1 is an introductory chapter where I cover an overview of what microservices are, the advantages and disadvantages, and the enabling technologies that helped them become widely adopted. If you already feel you have a grasp of that, you can skip that chapter and start with Chapter 2. Navigating This Book Each chapter in this book covers a different topic. If you want to jump straight to a particular chapter, you should find everything you need, but if you read the book from start to finish you’ll see that each chapter builds on those before it. This book is divided into three main parts: Context; Organizational Structure and Culture; and Building and Operating. Let’s look at what they cover.

Part I: Context This sets the context—what are microservices, what does success look like, and are microservices the right architectural pattern for you? Chapter 1, “Understanding Microservices” We’ll start with a full definition of the microservices architectural style. If you are new to microservices, this will give you a grounding, but even if you’ve been using them for a while, it’s worth reminding yourself of the core concepts, including why people adopted microservices in the first place. Chapter 2, “Effective Software Delivery” What defines effective software delivery? This chapter discusses the importance of being able to move fast, working on the highest-value features, building stable and resilient systems, keeping control of risk, avoiding having to start again, and finally, providing an environment where people get to spend most of their time on meaningful work. You can think of this chapter as a guide. I’ll introduce the concepts I’ll be talking about in the remainder of the book to link key themes together before we break them down in detail later. Chapter 3, “Are Microservices Right for You?” Microservices can be a very effective architecture, but they are not the only approach. So, are they the right solution for you? This chapter will help you make that assessment, discussing what you need to have in place to be able to tackle a move to microservices.

Part II: Organizational Structure and Culture To be successful with microservices, you need to do more than adopt the architectural patterns. There are organizational and cultural considerations, and these are the first things to focus on because if you can’t get these right, you will be taking on a lot of additional complexity for not much benefit. This part explores the organizational and cultural challenges. Chapter 4, “Conway’s Law and Finding the Right Boundaries” Conway’s Law says that organizations ship their organization structure: if you have two development groups, you’ll have two systems. This chapter explores the implications. It’s important to get your organizational boundaries in the right place. Chapter 5, “Building Effective Teams” You need a particular type of organizational culture to be successful with microservices: open, learning, and optimized for change. This chapter discusses the culture needed to build effective teams, ones that are autonomous and cross- functional, containing all the skills necessary to design, build, and deploy features. Chapter 6, “Enabling Autonomy” Teams need to be able to move at their own speed, instead of having to wait for someone outside the team to do something. This chapter covers how to support autonomy in teams, what the expectations are of those teams, and how they interact. Chapter 7, “Engineering Enablement and Paving the Road”

You can’t have every skill on every development team. You need to make some distinction between the platform and infrastructure services everyone needs and the products being built. This isn’t a return to dev versus ops: the platform teams should build and run the platform, while the dev teams build and run the services, and the interactions between them need to be as low friction as you can make them, while maintaining a level of security, quality, and cost control that your company would expect. This chapter talks about how to build a paved road: a set of tools and services that make life easy for all your product development teams. Chapter 8, “Ensuring ‘You Build It, You Run It’” You can’t move fast if every service has to be handed over to someone else to run. Services need to be owned in production by the team that wrote the code. That brings benefits: you build things differently when you are the person who might get called at 2 a.m. But it also means that lots of people who’ve never been on call now will be. And you’ll probably have some teams that are too small to run an out-of-hours rota. This chapter discusses how to navigate the changing demands so that on call doesn’t suck.

Part III: Building and Operating The third part digs into the practicalities of building and operating microservices. Each chapter covers techniques for getting the most out of microservices, explaining where they require a different approach to the monolith, and drawing on nearly a decade of experience. Each chapter in this section looks at how to avoid running into trouble, but also what to do to recover if you find yourself in the mire. Chapter 9, “Active Service Ownership” Services need to be strongly and actively owned. And that needs to be by a team, not by a person. Active ownership means that dependencies are upgraded, alerts are monitored, code is reviewed, and security vulnerabilities are patched. This chapter discusses what active ownership involves, and how to get there. Chapter 10, “Getting Value from Testing” This chapter looks at testing microservices. Quick, automated unit tests give a lot of value, but testing in production and good monitoring is often a more effective approach than end-to-end tests in staging, which can turn into fixture maintenance hell. Manual testing needs to be kept to a minimum: it simply takes too long when you move from releasing once a week to multiple times a day. Chapter 11, “Governance and Standardization: Finding the Balance” One of the selling points of microservices is the ability to choose “the right tool for the job.” But being flexible on programming languages or data storage layers increases the

complexity of your estate, reduces your flexibility in moving people to work on the most important thing, and can increase both cost and risk. This chapter discusses how to find the right balance, with a focus on introducing guardrails, choosing well-established technology, and light touch governance. Chapter 12, “Building Resilience In” Microservices are distributed systems and we need to build them differently. This chapter covers how to build resilient services and how to combine them together into a resilient system, covering topics like SLOs, error budgets, caching, timeouts and retries, and chaos engineering. Chapter 13, “Running Your System in Production” Do you have Slack channels that are unusable from the amount of alerts? Or do you have lots of alerts that everyone ignores? Both are bad news. This chapter looks at the operational challenges of microservices and explains how to build observability in and how to make sure you know when there’s a real problem. Chapter 14, “Keeping Things Up-to-Date” With so many different technologies, and so many services, you can spend a huge amount of time upgrading dependencies and migrating from old to new versions of software. This is even worse when there is an urgent security patch that hits hundreds of your services. This chapter looks at how to minimize the impact of all these changes, and how to be effective in managing the changes you do need to make. Appendixes

Finally, at the end of the book, I bring things together. I explain why microservices are the right pick in many cases, and provide you with guidance to help assess whether they would be a good match for you, and whether you have the necessary conditions in place, in terms of structure, culture, tools, and processes, to make a success of them. Finally, I include a short list of recommended reading: the books that are within arm’s reach on my desk as I write this; the posts that are open in tabs of my web browser. Case Studies While I draw on real-life examples throughout the book, I also have some in-depth case studies, from the Financial Times and from other organizations: “Case Study: Shopify’s Modular Monolith” “Case Study: Finding Our Boundaries at the Financial Times” “Case Study: The Evolution of the Organizational Structure at the Financial Times” “Case Study: Supporting Autonomous Teams at the Financial Times” “Case Study: Engineering Enablement at the Financial Times” “Case Study: Incident Management at the Financial Times” “Governance at Monzo” “Governance at Skyscanner”

Conventions Used in This Book TIP This element signifies a tip or suggestion. NOTE This element signifies a general note. WARNING This element indicates a warning or caution. O’Reilly Online Learning NOTE For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in- depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com.

How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-889-8969 (in the United States or Canada) 707-827-7019 (international or local) 707-829-0104 (fax) support@oreilly.com https://www.oreilly.com/about/contact.html We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/enabling-microservice-success. For news and information about our books and courses, visit https://oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly- media. Watch us on YouTube: https://youtube.com/oreillymedia. Acknowledgments