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?

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

The code that changes together, stays together.

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.

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,

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!

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.

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.

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,

Part of us wants recognition, so we borrow names from other professions that already have the recognition we as an industry crave.

Sometimes, you can reduce the latency to an acceptable amount by implementing a batch API for fetching multiple objects in a single round trip. But in other situations, the solution is to combine services, replacing expensive IPC with language-level method or function calls.

It’s the decomposition into parts and the relationships between those parts that determine the application’s -ilities.

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.

Traditionally, the goal of architecture has been scalability, reliability, and security. But today it’s important that the architecture also enables the rapid and safe delivery of software. You’ll learn that the microservice architecture is an architecture style that gives an application high maintainability, testability, and deployability.

Moreover, it’s very clear who to contact when a service isn’t meeting its SLA.

you can add people without impacting productivity.

Each team can develop, deploy, and scale their services without coordinating with other teams.

A key characteristic of continuous delivery is that software is always releasable. It relies on a high level of automation, including automated testing. Continuous deployment takes continuous delivery one step further in the practice of automatically deploying releasable code into production

You need to consider employees’ emotions in order to successfully transition to a microservice architecture.

One strategy for creating a microservice architecture is to decompose by business capability. A concept from business architecture modeling, a business capability is something that a business does in order to generate value.

An organization’s business capabilities capture what an organization’s business is. They’re generally stable, as opposed to how an organization conducts its business, which changes over time, sometimes dramatically.

A business capability is often focused on a particular business object. For example, the Claim business object is the focus of the Claim management capability. A capability can often be decomposed into sub-capabilities. For example, the Claim management capability has several sub-capabilities, including Claim information management, Claim review, and Claim payment management.

Network latency is an ever-present concern in a distributed system.

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.

It’s too large for any developer to fully understand

To make matters worse, this overwhelming complexity tends to be a downward spiral. If the code base is difficult to understand, a developer won’t make changes correctly. Each change makes the code base incrementally more complex and harder to understand.

continuous deployment: deploying changes to production many times a day during business hours.

One problem with so many developers committing to the same code base is that the build is frequently in an unreleasable state.

a disciplined team can slow down the pace of its descent toward monolithic hell. Team members can work hard to maintain the modularity of their application. They can write comprehensive automated tests. On the other hand, they can’t avoid the issues of a large team working on a single monolithic application. Nor can they solve the problem of an increasingly obsolete technology stack. The best a team can do is delay the inevitable.

There are numerous definitions of the microservice architecture. Some take the name too literally and claim that a service should be tiny—for example, 100 LOC. Others claim that a service should only take two weeks to develop. Adrian Cockcroft, formerly of Netflix, defines a microservice architecture as a service-oriented architecture composed of loosely coupled elements that have bounded contexts.

The high-level definition of microservice architecture (microservices) is an architectural style that functionally decomposes an application into a set of services. Note that this definition doesn’t say anything about size. Instead, what matters is that each service has a focused, cohesive set of responsibilities.

1.4.3. Each service has its own database A key characteristic of the microservice architecture is that the services are loosely coupled and communicate only via APIs. One way to achieve loose coupling is by each service having its own datastore. In the online store, for example, Order Service has a database that includes the ORDERS table, and Customer Service has its database, which includes the CUSTOMERS table. At development time, developers can change a service’s schema without having to coordinate with developers working on other services. At runtime, the services are isolated from each other—for example, one service will never be blocked because another service holds a database lock.

SOA Microservices Inter-service communication Smart pipes, such as Enterprise Service Bus, using heavyweight protocols, such as SOAP and the other WS* standards. Dumb pipes, such as a message broker, or direct service-to-service communication, using lightweight protocols such as REST or gRPC Data Global data model and shared databases Data model and database per service Typical service Larger monolithic application Smaller service

SOA and the microservice architecture usually use different technology stacks. SOA applications typically use heavyweight technologies such as SOAP and other WS* standards. They often use an ESB, a smart pipe that contains business and message-processing logic to integrate the services. Applications built using the microservice architecture tend to use lightweight, open source technologies. The services communicate via dumb pipes, such as message brokers or lightweight protocols like REST or gRPC.

The microservice architecture has the following benefits: It enables the continuous delivery and deployment of large, complex applications. Services are small and easily maintained. Services are independently deployable. Services are independently scalable. The microservice architecture enables teams to be autonomous. It allows easy experimenting and adoption of new technologies. It has better fault isolation.

You can structure the engineering organization as a collection of small (for example, two-pizza) teams. Each team is solely responsible for the development and deployment of one or more related services. As figure 1.8 shows, each team can develop, deploy, and scale their services independently of all the other teams. As a result, the development velocity is much higher.

As with much of software development, it’s something of an art.

if you decompose a system incorrectly, you’ll build a distributed monolith, a system consisting of coupled services that must be deployed together. A distributed monolith has the drawbacks of both the monolithic architecture and the microservice architecture.

Another issue with using the microservice architecture is that developers must deal with the additional complexity of creating a distributed system. Services must use an interprocess communication mechanism. This is more complex than a simple method call. Moreover, a service must be designed to handle partial failure and deal with the remote service either being unavailable or exhibiting high latency.

a microservices-based application can’t retrieve data from multiple services using simple queries. Instead, it must implement queries using either API composition or CQRS views.

Another challenge with using the microservice architecture is that deploying features that span multiple services requires careful coordination between the various development teams. You have to create a rollout plan that orders service deployments based on the dependencies between services. That’s quite different than a monolithic architecture, where you can easily deploy updates to multiple components atomically.

The code is easier for a developer to understand. The small code base doesn’t slow down the IDE, making developers more productive. And each service typically starts a lot faster than a large monolith does, which also makes developers more productive and speeds up deployments.

each service can be deployed on hardware that’s best suited to its resource requirements. This is quite different than when using a monolithic architecture, where components with wildly different resource requirements—for example, CPU-intensive vs. memory-intensive—must be deployed together.

the developers are free to pick whatever language and frameworks are best suited for that service. In many organizations, it makes sense to restrict the choices, but the key point is that you aren’t constrained by past decisions.

If the trial of a new technology fails, you can throw away that work without risking the entire project.

Here are the major drawbacks and issues of the microservice architecture: Finding the right set of services is challenging. Distributed systems are complex, which makes development, testing, and deployment difficult. Deploying features that span multiple services requires careful coordination. Deciding when to adopt the microservice architecture is difficult.

Moreover, as the company became more successful, the size of the development team steadily grew. Not only did this increase the growth rate of the code base, it also increased the management overhead.

Simple to develop—IDEs and other developer tools are focused on building a single application. Easy to make radical changes to the application—You can change the code and the database schema, build, and deploy. Straightforward to test—The developers wrote end-to-end tests that launched the application, invoked the REST API, and tested the UI with Selenium. Straightforward to deploy—All a developer had to do was copy the WAR file to a server that had Tomcat installed. Easy to scale—FTGO ran multiple instances of the application behind a load balancer.

It won’t be able to create an order if any of those other services are unavailable

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. Later, as things change, it should allow for reversing that progression and sliding all the way back down into a monolith.

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.

with microservices, it becomes possible to establish small, autonomous teams that can assume a level of ownership of their code that isn’t possible with a monolithic approach. The switch to microservices removed the shackles that had prevented the Amazon software teams from moving fast, and enabled the transition to small, autonomous teams.

In this case, assigning an operation to a service that needs the information provided by the operation is a better choice. In other situations, it might make sense to assign an operation to the service that has the information necessary to handle it.

Services in a microservice architecture are organized around business concerns—business capabilities or subdomains—rather than technical concerns.

There are two patterns for decomposition: Decompose by business capability, which has its origins in business architecture Decompose by subdomain, based on concepts from domain-driven design

use the more sophisticated and performant approach of tailing the database transaction log.

Every committed update made by an application is represented as an entry in the database’s transaction log. A transaction log miner can read the transaction log and publish each change as a message to the message broker.

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.

Melvin Conway’s paper How Do Committees Invent, published in Datamation magazine in April 1968, observed that: Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.

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.

Most CMSes are pretty bad even at doing page layout, typically providing drag-and-drop tools that don’t cut the mustard. And even then, you end up needing to have someone who understands HTML and CSS to fine-tune the CMS templates. They tend to be terrible platforms on which to build custom code.

Avoid database integration at all costs. Understand the trade-offs between REST and RPC, but strongly consider REST as a good starting point for request/response integration. Prefer choreography over orchestration. Avoid breaking changes and the need to version by understanding Postel’s Law and using tolerant readers.

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.

Gather together those things that change for the same reason, and separate those things that change for different reasons.

A test suite with flaky tests can become a victim of what Diane Vaughan calls the normalization of deviance — the idea that over time we can become so accustomed to things being wrong that we start to accept them as being normal and not a problem.

Sometimes making one thing slower in exchange for other things is the right thing to do, especially if slower is still perfectly acceptable.

You should assume that your networks are plagued with malevolent entities ready to unleash their ire on a whim.

principal.

Eric Ries tells the story of spending six months building a product that no one ever downloaded.

When we compare ourselves to engineers or architects, we are in danger of doing everyone a disservice.

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.

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.

Microservices are important simply because they add unique value in a way of simplification of complexity in systems.  By breaking apart your system or application into many smaller parts, you show ways of reducing duplication, increasing cohesion and lowering your coupling between parts, thus making your overall system parts easier to understand, more scalable, and easier to change. The downside of a distributed system is that it is always more complex from a systems standpoint. The overhead of many small services to manage is another factor to consider. 

Neal Ford puts it, many of our working practices around deployment and host management are an attempt to optimize for scarcity of resources.

A cynic might suggest that vendors co-opted (and in some cases drove) the SOA movement as a way to sell more products, and those selfsame products in the end undermined the goal of SOA.

If there is too much sharing, our consuming services become coupled to our internal representations. This decreases our autonomy,

I have also seen many a team’s morale and productivity destroyed by having a mandated framework thrust upon them. In a drive to improve code reuse, more and more work is placed into a centralized framework until it becomes an overwhelming monstrosity.

Jon Eaves at RealEstate.com.au in Australia characterizes a microservice as something that could be rewritten in two weeks, a rule of thumb that makes sense for his particular context.

smaller teams working on smaller codebases tend to be more productive.

One of the biggest problems with Microservices is the dependencies and challenges with designing services to not be all-in dependent on each other and the solutions to this.

right

So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.

The evolutionary architect is one who understands that pulling off this feat is a constant balancing act. Forces are always pushing you one way or another, and understanding where to push back or where to go with the flow is often something that comes only with experience. But the worst reaction to all these forces that push us toward change is to become more rigid or fixed in our thinking.

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.

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.

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.