Sam Newman > 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

“The code that changes together, stays together.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“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

“Greenspun’s 10th rule states, “Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp.” This has morphed into the newer joke: “Every microservice architecture contains a half-broken reimplementation of Erlang.” I think there is a lot of truth to this.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“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

“Resilience versus Robustness.
Typically when we want to improve a system’s ability to avoid outages, handle failures gracefully when they occur and recover quickly when they happen, we often talk about resilience. (…) Robustness is the ability of a system that is able to react to expected variations, Resilience is having an organisation capable of adapting to things that have not been thought of, which could very well include creating a culture of experimentation through things like chaos engineering.
For example, we are aware a specific machine could die, so we might bring redundancy into our system by load-balancing an instance, that is an example of addressing Robustness. Resiliency is the process of an organisation preparing itself to the fact that it cannot anticipate all potential problems. An important consideration here is that microservices do not necessarily give you robustness for free, rather they open up opportunities to design a system in such a way that it can better tolerate network partitions, service outages, and the like. Just spreading your functionality over multiple separate processed and separate machines does not guarantee improved robustness, quite the contrary, it may just increase your surface area of failure.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“Getting integration right is the single most important aspect of the technology associated with microservices in my opinion. Do it well, and your microservices retain their autonomy, allowing you to change and release them independent of the whole. Get it wrong, and disaster awaits. Hopefully once you’ve read this chapter you’ll learn how to avoid some of the biggest pitfalls that have plagued other attempts at SOA and could yet await you in your journey to microservices.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“In his book Antifragile (Random House), Nassim Taleb talks about things that actually benefit from failure and disorder”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Riemann is an event server that allows for fairly advanced aggregation and routing of events and can form part of such a solution”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Suro is Netflix’s data pipeline and operates in a similar space. Suro is explicitly used to handle both metrics associated with user behavior, and more operational data like application logs”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Much like with our example of fronting the CMS system with our own code, with a strangler you capture and intercept calls to the old system.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Principles Principles are rules you have made in order to align what you are doing to some larger goal, and will sometimes change. For example, if one of your strategic goals as an organization is to decrease the time to market for new features, you may define a principle that says that delivery teams have full control over the lifecycle of their software to ship whenever they are ready, independently of any other team. If another goal is that your organization is moving to aggressively grow its offering in other countries, you may decide to implement a principle that the entire system must be portable to allow for it to be deployed locally in order to respect sovereignty of data. You probably don’t want loads of these. Fewer than 10 is a good number — small enough that people can remember them, or to fit on small posters. The more principles you have, the greater the chance that they overlap or contradict each other.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Robert C. Martin’s definition of the Single Responsibility Principle, which states “Gather together those things that change for the same reason, and separate those things that change for different reasons.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“If you’re using HTTP, it could populate headers with this information. Shibboleth is one tool that can do this for you, and I’ve seen it used with Apache to great effect to handle integration with SAML-based identity providers.”
― 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

“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

“I would say that in my experience the smarter the PaaS solutions try to be, the more they go wrong”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“A great place to start is to use a tool like the freely available SchemaSpy, which can generate graphical representations of the relationships between tables.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Packer is a tool designed to make creation of images much easier”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“although experience has shown that it is far easier to push out changes to configuration files than alter live database tables. This is often a very sensible approach.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Michael Nygard’s book Release It! (Pragmatic Programmers) shows how the same idea can work wonders as a protection mechanism for our software.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“Eric Ries tells the story of spending six months building a product that no one ever downloaded.”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“A technique I saw used at the Guardian, and subsequently elsewhere, was to crawl the existing live site periodically to generate a static version of the website that could be served in the event of an outage. Although this crawled version wasn’t as fresh as the cached content served from the live system, in a pinch it could ensure that a version of the site would get displayed”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

“The example of a client trying to be as flexible as possible in consuming a service demonstrates Postel’s Law (otherwise known as the robustness principle), which states: “Be conservative in what you do, be liberal in what you accept from others.”
― 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

“If there is too much sharing, our consuming services become coupled to our internal representations. This decreases our autonomy,”
― Sam Newman, Building Microservices: Designing Fine-Grained Systems