Building Microservices Quotes

“If you are working in an organization that places lots of restrictions on how developers can do their work, then microservices may not be for you.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“The golden rule: can you make a change to a service and deploy it by itself without changing anything else?”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“if bridge building were like programming, halfway through we’d find out that the far bank was now 50 meters farther out, that it was actually mud rather than granite, and that rather than building a footbridge we were instead building a road bridge.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“No matter how it looks at first, it’s always a people problem. Gerry Weinberg, The Second Law of Consulting”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“No matter how it looks at first, it’s always a people problem. ​—​Gerry Weinberg, The Second Law of Consulting”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“When services are loosely coupled, a change to one service should not require a change to another.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Once launched into production, our software will continue to evolve as the way it is used changes. For most things we create, we have to accept that once the software gets into the hands of our customers we will have to react and adapt, rather than it being a never-changing artifact. Thus, our architects need to shift their thinking away from creating the perfect end product, and instead focus on helping create a framework in which the right systems can emerge, and continue to grow as we learn more.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“An old-fashioned architect would tell people what to do. In the new, modern, decentralized organization, architects are surveying the landscape, spotting trends, helping connect people, and acting as a sounding board to help other teams get stuff done. They aren’t a unit of control in this world; they are yet another enabling function (often with a new name—I’ve seen terms like principal engineer used for people playing the role of what I would consider an architect).”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Organizations have increasingly recognized that if you want to scale your organization but still want to move quickly, you need to distribute responsibility more effectively, breaking down central decision making and pushing decisions into parts of the organization that can operate with increased autonomy. The trick, then, is to create large organizations out of smaller, autonomous teams.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“The problem with blaming people in the aftermath of incidents like this is that what starts as a short-term passing of the buck ends up creating a culture of fear, where people will be unwilling to come forward to tell you when things go wrong. As a result, you will lose the opportunity to learn from failure, setting yourself up for the same problems happening again. Creating an organization in which people have the safety to admit when mistakes are made is essential in creating a learning culture, and in turn can go a long way toward creating an organization that is able to create more robust software, quite aside from the obvious benefits of creating a happier place to work in.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“If you have been in the IT industry for more than 15 minutes, you don't need me to tell you that we work in a space that is changing rapidly.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“don’t violate DRY within a microservice, but be relaxed about violating DRY across all services.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“The need to change our systems to deal with scale isn’t a sign of failure. It is a sign of success.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“This single team finds it easy to communicate about proposed changes and refactorings, and typically has a good sense of ownership. Now let’s imagine a different scenario. Instead of a single, geolocated team owning our catalog service, suppose that teams in the UK and India both are actively involved in changing a service — effectively having joint ownership of the service. Geographical and time zone boundaries here make fine-grained communication between those teams difficult. Instead, they rely on more coarse-grained communication via video conferencing and email. How easy is it for a team member in the UK to make a simple refactoring with confidence? The cost of communications in a geographically distributed team is higher, and therefore the cost of coordinating changes is higher. When the cost of coordinating change increases, one of two things happen. Either people find ways to reduce the coordination/communication costs, or they stop making changes. The latter is exactly how we end up with large, hard-to-maintain codebases.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“I worked on one monolithic system, for example, where we had 4,000 unit tests, 1,000 service tests, and 60 end-to-end tests. We decided that from a feedback point of view we had way too many service and end-to-end tests (the latter of which were the worst offenders in impacting feedback loops), so we worked hard to replace the test coverage with smaller-scoped tests. A common anti-pattern is what is often referred to as a test snow cone, or inverted pyramid. Here, there are little to no small-scoped tests, with all the coverage in large-scoped tests. These projects often have glacially slow test runs, and very long feedback cycles. If these tests are run as part of continuous integration, you won’t get many builds, and the nature of the build times means that the build can stay broken for a long period when something does break.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“So we borrow from other professions. We call ourselves software “engineers,” or “architects.” But we aren’t, are we? Architects and engineers have a rigor and discipline we could only dream of, and their importance in society is well understood. I remember talking to a friend of mine, the day before he became a qualified architect. “Tomorrow,” he said, “if I give you advice down at the pub about how to build some‐ thing and it’s wrong, I get held to account. I could get sued, as in the eyes of the law I am now a qualified architect and I should be held responsible if I get it wrong.” The importance of these jobs to society means that there are required qualifications people have to meet. In the UK, for example, a minimum of seven years study is required before you can be called an architect. But these jobs are also based on a body of knowledge going back thousands of years. And us? Not quite. Which is also why I view most forms of IT certification as worthless, as we know so little about what good looks like”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“There is a type of vulnerability called the confused deputy problem, which in the context of service-to-service communication refers to a situation where a malicious party can trick a deputy service into making calls to a downstream service on his behalf that he shouldn’t be able to.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Part of us wants recognition, so we borrow names from other professions that already have the recognition we as an industry crave.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Tests can be important to support refactoring of code, allowing us to restructure our code as we go, knowing that our small-scoped tests will catch us if we make a mistake.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“I have seen perhaps as many country codes stored in databases (shown in Figure 5-4) as I have written StringUtils classes for in-house Java projects. This seems to imply that we plan to change the countries our system supports way more frequently than we’ll deploy new code,”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“With larger, monolithic systems, there are fewer opportunities for people to step up and own something. With microservices, on the other hand, we have multiple autonomous codebases that will have their own independent lifecycles. Helping people step up by having them take ownership of individual services before accepting more responsibility can be a great way to help them achieve their own career goals, and at the same time lightens the load on whoever is in charge!”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“architects need to shift their thinking away from creating the perfect end product, and instead focus on helping create a framework in which the right systems can emerge, and continue to grow as we learn more.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“although this isolation can add some overhead, the resulting simplicity makes our distributed system much easier to reason about,”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“I get asked this question a lot. My first piece of advice would be that the less well you understand a domain, the harder it will be for you to find proper bounded contexts for your services. As we discussed previously, getting service boundaries wrong can result in having to make lots of changes in service-to-service collaboration — an expensive operation. So if you’re coming to a monolithic system for which you don’t understand the domain, spend some time learning what the system does first, and then look to identify clean module boundaries prior to splitting out services.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Services should also hide their databases to avoid falling into one of the most common sorts of coupling that can appear in traditional service-oriented architectures, and use data pumps or event data pumps to consolidate data across multiple services for reporting purposes.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Two different pieces of technology, Swagger and HAL, try to make this a reality, and both are worth looking at.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Zookeeper itself is fairly generic in what it offers, which is why it is used for so many use cases. You can think of it just as a replicated tree of information that you can be alerted about when it changes. This means that you’ll typically build things on top of it to suit your particular use case. Luckily, client libraries exist for most languages out there.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“You’ll often see posts about people beating the CAP theorem. They haven’t. What they have done is create a system where some capabilities are CP, and some are AP. The mathematical proof behind the CAP theorem holds. Despite many attempts at school, I’ve learned that you don’t beat math”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“You’ll often see posts about people beating the CAP theorem. They haven’t. What they have done is create a system where some capabilities are CP, and some are AP. The mathematical proof behind the CAP theorem holds. Despite many attempts at school, I’ve learned that you don’t beat math.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Which is right, AP or CP? Well, the reality is it depends. As the people building the system, we know the trade-off exists”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems