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.

The golden rule: can you make a change to a service and deploy it by itself without changing anything else?

The code that changes together, stays together.

No matter how it looks at first, it’s always a people problem. Gerry Weinberg, The Second Law of Consulting

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.

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.

No matter how it looks at first, it’s always a people problem. ​—​Gerry Weinberg, The Second Law of Consulting

When services are loosely coupled, a change to one service should not require a change to another.

A good architecture will allow a system to be born as a monolith, deployed in a single file, but then to grow into a set of independently deployable units, and then all the way to independent services and/or micro-services.

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.

As strange as it may seem, this decision is one of the options that a good architect leaves open. A system that is written as a monolith, and that depends on that monolithic structure, cannot easily be upgraded to multiple processes, multiple threads, or micro-services should the need arise. By comparison, an architecture that maintains the proper isolation of its components, and does not assume the means of communication between those components, will be much easier to transition through the spectrum of threads, processes, and services as the operational needs of the system change over time.

Making a change across a process boundary is expensive. If you need to make a change to two services to roll out a feature, and orchestrate the deployment of these two changes, that takes more work than making the same change inside a single service (or, for that matter, a monolith).

I urge people not to worry about size. When you are first starting out, it’s much more important that you focus on two key things. First, how many microservices can you handle? … Second, how do you define microservice boundaries to get the most out of them, without everything becoming a horribly coupled mess?

A monolithic architecture is a choice, and a valid one at that. It may not be the right choice in all circum stances, any more than microservices are—but it’s a choice nonetheless.

cohesion and coupling are concerns regarding modular software, and what is microservice architecture other than modules that communicate via networks and can be independently deployed

You should be thinking of migrating to a microservice architecture in order to achieve something that you can’t currently achieve with your existing system architecture.

If you create software that is packaged and shipped to customers who then operate it themselves, microservices may well be a bad choice... The reality is that you cannot expect your customers to have the skills or platforms available to manage microservice architectures. Even if they do, they may not have the same skills or platform that you require.

Microservice decomposition can cause issues with troubleshooting, tracing flows, latency, referential integrity, cascading failures, and a host of other things. Most of those problems are things you’ll notice only after you hit production.

It turns out that an organizational structure that worked well for a Swedish music streaming company may not work for an investment bank. In addition, the original paper showed a snapshot of how Spotify worked in 2012 and things have changed since. It turns out not even Spotify uses the Spotify model.

Discussions around architecture often focus on tools and technologies. Should the organization adopt microservices or serverless architectures? Should they use Kubernetes or Mesos? Which CI server, language, or framework should they standardize on? Our research shows that these are wrong questions to focus on. What tools or technologies you use is irrelevant if the people who must use them hate using them, or if they don’t achieve the outcomes and enable the behaviors we care about. What is important is enabling teams to make changes to their products or services without depending on other teams or systems. Architects should collaborate closely with their users—the engineers who build and operate the systems through which the organization achieves its mission—to help them achieve better outcomes and provide them the tools and technologies that will enable these outcomes.

Each service is meant to represent a domain or subdomain; in many ways, microservices is the physical embodiment of the logical concepts in domain-driven design.

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.

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.

Componentization via services: In microservices, the primary way of componentizing will be via services. This is a bit different from the traditional componentizing via libraries. A library in the Java world is a jar file, and in .NET world, it’s a DLL file.

Smart endpoints and dumb pipes: Each microservice is developed for a well-defined scope. Once again, the best example is Netflix.42 Netflix started with a single monolithic web application called netflix.war in 2008, and later in 2012, as a solution to address vertical scalability concerns, they moved into a microservices-based approach, where they have hundreds of fine-grained microservices today. The challenge here is how microservices talk to each other. Since the scope of each microservice is small (or micro), to accomplish a given business requirement, microservices have to talk to each other. Each microservice would be a smart endpoint, which exactly knows how to process an incoming request and generate the response.

With the microservices-based architecture, each service is designed with its own autonomy and highly decoupled from each other. The team behind each microservice can follow their own standards, tools, and protocols. This makes a decentralized governance model more meaningful for microservices architecture.

With the microservices design, where each distinguished functional component is developed into a microservice, based on their business capabilities, will have its own database—so each such service can scale end to end without having any dependency on other microservices.

Microservices have not substituted APIs—rather they work together.

By breaking our application into individual, independently deployable processes, we open up a host of mechanisms to improve the robustness of our applications. By using microservices, we are able to implement a more robust architecture, because functionality is decomposed, that is, an impact in one area of functionality may not bring down the whole system, we also can focus our time and energy on those parts of the application that most require robustness, ensuring critical parts of our system remain operational.

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.

All event data is completely immutable once published. There is no mechanism that can modify event data once it is published. You can alter previous data only by publishing a new event with the updated data.

SOA mainly uses protocols like SOAP for remote access and Microsoft Messaging Queue (MSMQ), and Advance Messaging Queue Protocol (AMQP) for messaging. Microservices generally use Representational State Transfer (REST) and Java Messaging Service (JMS) for messaging.

Synchronous systems are also known as request/response based. Asynchronous systems are event-based. Synchronous Microservices are not loosely coupled.

In Orchestration, we rely on a central system to control and call other Microservices to complete a task. In Choreography, each Microservice works like a State Machine and reacts based on the input from other parts. Orchestration is a tightly coupled approach for integrating Microservices. Whereas, Choreography is a loose coupling approach. Choreography based systems are more flexible and easy to change than Orchestration based systems. Orchestration is often implemented by synchronous calls. Choreography is implemented by asynchronous calls. The synchronous calls are much simpler compared to asynchronous communication.

What is a good tool for monitoring multiple services at a time? Graphite is an open source database that captures metrics from services in a time series database. By using Graphite we can capture essential metrics of multiple Microservices simultaneously. And we can use a dashboard like- Grafana to monitor these metrics in almost real time. Graphite is also great at handling large amount of data. It can also show the trends from few hours to few months within a few seconds. Many organizations like- Facebook etc. use Graphite for monitoring. Some of the other tools to monitor Microservices are: AppDynamics, DynaTrace, SpringBoot Admin etc.

A few very popular options to evaluate Microservices performance are: AppDynamics NewRelic DynaTrace

don’t violate DRY within a microservice, but be relaxed about violating DRY across all services.

Instead of each team shipping code into some giant repository that somebody else would deploy and run on servers, each team would run their own code as a service that other teams could interoperate with. Because each team was small, the surface area of their service was typically somewhat limited as well. Over time, these became known as “microservices” because each individual service typically did one thing, and did it well.

These microservices were delivered not as a pile of code, nor as a website, but as a web-based API. APIs are well-defined interfaces that enable code to talk to other bits of code. Once a team builds and exposes an API to others, it’s important that they teach other teams how to use it via documentation that’s accurate and up to date.

So your developers start plugging in pieces from specialist providers, and boom—you have a software supply chain. Does it really matter what company’s logo these microservice providers have on their business cards?

Why devote your own developers to microservices that you could instead buy from other companies?

For now, we have a hybrid model. You buy the common stuff where you can and write the rest. The “value add” of your company might be the way you integrate the pieces, and how well you develop the customer-facing software that sits on top of microservices.

Instead of choosing between a monolithic architecture or a microservices architecture, design the software to fit the maximum team cognitive load. Only then can we hope to achieve sustainable, safe, rapid software delivery. This team-first approach to software boundaries leads to favoring certain styles of software architecture, such as small, decoupled services.

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.

you’d learn which buttons did what, so that you could give one another instructions. “Press the red button near the flashing

We have a microservice with a web API,

Node.js is a powerful, open-source, server-side JavaScript runtime environment that enables developers to build scalable and high-performance applications. Leveraging event-driven architecture and non-blocking I/O operations, Node.js allows for efficient handling of concurrent requests, making it ideal for building real-time web applications, APIs, and microservices. With its extensive ecosystem of libraries and frameworks, Node.js empowers developers to create fast, lightweight, and modern applications across various domains.

although this isolation can add some overhead, the resulting simplicity makes our distributed system much easier to reason about,

Because Lambda executes in a custom environment managed by AWS, it can be difficult to work through this cycle. Fortunately, a number of open source third-party libraries have sprung up to fill the need for testing. Ultimately, these tools mimic the “event” and “context” objects, along with their properties and method to simulate the environment in which Lambda functions launch once uploaded.

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!

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,

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.

On the first look continuous deployment (CD), microservices (MS) and containers might seem like three unrelated subjects. After all, DevOps movement does not stipulate that microservices are necessary for continuous deployment, nor microservices need to be packaged into containers. However, when those three are combined, new doors open waiting for us to step through. Recent developments in the area of containers and the concept of immutable deployments enable us to overcome many of the problems microservices had before. They,

You can think of Mountebank as a small software appliance that is programmable via HTTP. The fact that it happens to be written in NodeJS is completely opaque to any calling service. When it launches, you send it commands telling it what port to stub on, what protocol to handle (currently TCP, HTTP, and HTTPS are supported, with more planned), and what responses it should send when requests are sent. It also supports setting expectations if you want to use it as a mock. You can add or remove these stub endpoints at will, making it possible for a single Mountebank instance to stub more than one downstream dependency.

You’ll also need to think differently about how you scale your systems and ensure that they are resilient. Don’t also be surprised if things like distributed transactions or CAP theorem start giving you headaches, either!

Erik Doernenburg first shared with me the idea that we should think of our role more as town planners than architects for the built environment

To borrow a term from Frank Buschmann, architects have a duty to ensure that the system is habitable for developers too

So our architects as town planners need to set direction in broad strokes, and only get involved in being highly specific about implementation detail in limited cases.

Making decisions in system design is all about trade-offs, and microservice architectures give us lots of trade-offs to make

I have also seen many a team’s morale and productivity destroyed by having a mandated framework thrust upon them

Much of the role of the technical leader is about helping grow them — to help them understand the vision themselves — and also ensuring that they can be active participants in shaping and implementing the vision too.

am a strong believer that great software comes from great people

A loosely coupled service knows as little as it needs to about the services with which it collaborates. This also means we probably want to limit the number of different types of calls from one service to another, because beyond the potential performance problem, chatty communication can lead to tight coupling.

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.

Remember when we talked about the core principles behind good microservices? Strong cohesion and loose coupling — with database integration, we lose both things.

Another principle introduced in REST that can help us avoid the coupling between client and server is the concept of hypermedia as the engine of application state (often abbreviated as HATEOAS, and boy, did it need an abbreviation

I find it odd that people pick JSON because it is nice and lightweight, then try and push concepts into it like hypermedia controls that already exist in XML

I saw used effectively by one of our teams was to delay the implementation of proper persistence for the microservice, until the interface had stabilized enough

I recommend REST in Practice (O’Reilly), which covers the topic of REST over HTTP in depth

Another key to deferring a breaking change is to encourage good behavior in your clients, and avoid them binding too tightly to your services in the first place

This pattern — of implementing a reader able to ignore changes we don’t care about — is what Martin Fowler calls a Tolerant Reader.

This pattern is sometimes referred to as backends for frontends (BFFs)

The danger with this approach is the same as with any aggregating layer; it can take on logic it shouldn

Many implementations of CRM tools I have seen are among the best examples of adhesive (as opposed to cohesive) services.

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.

In his book Working Effectively with Legacy Code (Prentice-Hall), Michael Feathers defines the concept of a seam —

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.

using this approach, which it then open sourced as the Aegisthus project

During this time of churn, changes across service boundaries are more likely, and what is in or not in a given service is likely to change frequently. During this period, having all services in a single build to reduce the cost of cross-service changes may make sense.

Packer is a tool designed to make creation of images much easier

We can focus our efforts, then, on automating the creation and deployment of these images. This also becomes a really neat way to implement another deployment concept, the immutable server

But once we run our deployment process, what happens if someone comes along, logs into the box, and changes things independently of what is in source control? This problem is often called configuration drift — the code in source control no longer reflects the configuration of the running host.

This balance, between production-like environments and fast feedback, won’t be static. Keep an eye on the bugs you find further downstream and your feedback times, and adjust this balance as required.

When PaaS solutions work well, they work very well indeed. However, when they don’t quite work for you, you often don’t have much control in terms of getting under the hood to fix things. This is part of the trade-off you make

I would say that in my experience the smarter the PaaS solutions try to be, the more they go wrong

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.

The more moving parts, the more brittle our tests may be, and the less deterministic they are. If you have tests that sometimes fail, but everyone just re-runs them because they may pass again later, then you have flaky tests

This situation worsens if we fall into the trap of adding a new end-to-end test for every piece of functionality we add. Show me a codebase where every new story results in a new end-to-end test, and I’ll show you a bloated test suite that has poor feedback cycles and huge overlaps in test coverage

Originally just for Ruby, Pact now includes JVM and .NET ports

The work to shadow production traffic can be complex, though, especially if the events /requests being replayed aren’t idempotent.

The term nonfunctional never sat well with me. Some of the things that get covered by this term seem very functional in nature! One of my colleagues, Sarah Taraporewalla, coined the phrase cross-functional requirements (CFR) instead, which I greatly prefer

All too often, considerations about CFRs come far too late. I strongly suggest looking at your CFRs as early as possible, and reviewing them regularly.

If you are interested in reading more about testing, I recommend Agile Testing by Lisa Crispin and Janet Gregory (Addison-Wesley), which among other things covers the use of the testing quadrant in more detail.

Libraries exist for a number of different platforms that allow our services to send metrics to standard systems. Codahale’s Metrics library is one such example library for the JVM

Some of these libraries, such as Hystrix

Teams now measure themselves not in terms of how many points they complete, but instead optimize for how long it takes for code to get from laptop to live

Riemann is an event server that allows for fairly advanced aggregation and routing of events and can form part of such a solution

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

in my earlier publication Lightweight Systems for Realtime Monitoring (O’Reilly).

At the time of writing, OpenAM and Gluu are two of the very few options available in this space, compared to a wealth of options for SAML (including Active Directory, which seems to be everywhere)