Microservices Architecture

Microservices are small, focused on doing one thing well and autonomous services that work together. Microservices were not invented. They emerged as a trend, or a pattern from real-world use case.

The benefits of microservices are many and varied.

Technology Heterogeneity: Link to heading

With a system composed of multiple, collaborating services, we can decide to use different technologies inside each one. This allows us to pick the right tool for each job, rather than having to select a more standardized, one-size-fits-all approach that often ends up being the lowest common denominator.

If one part of our system needs to improve its performance, we decide to use a different technology stack that is better able to achieve the performance levels required. We may also decide that how we store our data needs to change for different part of our system. For example, for a social network, we might store our users interaction in a graph-oriented database to reflect the highly interconnected nature of a social graph, but perhaps the posts the users make could be stored in a document-oriented data store.

With microservices, we are also able to adopt technology more quickly. With a monolithic system we can not adopt new technology very easily.

Resilience: Link to heading

If one component of a system fails, but that failure doesn’t cascade, you can isolate the problem and the rest of the system can carry on working. In a monolithic service, if the service fails, everything stops working. With a monolithic system, we can run on multiple machines to reduce our chance of failure, but with microservices, we can build systems that handle the total failure of services and degrade functionality accordingly.

Scaling: Link to heading

With a large, monolithic service, we have to scale everything together. One small part of our overall system is constrained in performance, but if that behavior is locked up in a giant monolithic application, we have to handle everything as a piece. With smaller services, we can just scale those services that need scaling, allowing us to run other parts of the system on smaller, less powerful hardware.

Ease of Deployment: Link to heading

A one-line change to a million-line-long monolithic application requires the whole application to be deployed in order to release the change. That could be a large impact, high-risk deployment. In practice, large-impact, high-risk deployments end up happening frequently due to understandable fear. Unfortunately, this means that our changes build up and build up between releases, until the new version of our application hitting production has masses of changes. And the bigger the delta between releases, the higher the risk that we’ll get something wrong!.

With microservices, we can make a change to a single service and deploy it independently of the rest of the system. This allows us to get our code deployed faster. If a problem does occur, it can be isolated quickly to an individual service making, fast rollback easy to achieve. It also means we can get our new functionality out to customers faster. This is one of the main reasons why organizations use these architecture.

Organizational Alignment: Link to heading

Many of us experienced the problems associated with large teams and large codebases. We also know that smaller teams working on smaller codebases tend to be more productive.

Micro-service allow us to better align our architecture to our organization, helping us minimize the number of people working on any one codebase to hit the sweet spot of team size and productivity.

Composability: Link to heading

One of the key promises of distributed systems and microservices architectures is that we open up opportunities for reuse of functionality. With microservices, we allow for our functionality to be consumed in a different ways for different purposes. This can be especially important when we think about how our customers use our software.

Optimizing for Replaceability: Link to heading

Monolithic services are too big that it becomes risky to rewrite or replace that with a better implementation.

In microservices, with our individual services being small in size, the cost to replace them with a better implementation or even delete them altogether, is much easier to mange.