Cloud-Native Microservices With Kubernetes - 2nd Edition

Microservices

Inspired by the principles of the Twelve-Factor App, Unix/Linux philosophy, and other architectural styles, the microservices architecture emerged as a response to the challenges of building and maintaining large, complex software systems that scale.

Microservices is an architecture for building software systems. It breaks down the different components of the system into smaller, more manageable pieces called microservices. Each has a single responsibility and can be developed and deployed independently of the others.

The microservices approach addresses the challenges identified in Lehman's Laws of Software Evolution.

• The Law of Continuing Change is addressed by making it easier to adapt and update individual microservices without having to change the entire system.
• The Law of Increasing Complexity is addressed by breaking down the system into smaller, more manageable components.
• The Law of Declining Quality is addressed by making it easier to maintain and update individual microservices, with fewer constraints on the overall system, and by providing mechanisms for monitoring and managing the system as a whole.

A microservices architecture also provides additional benefits, including scalability, flexibility, easier testing, and deployment. These advantages make it an optimal technique for building large and complex software systems.

Before the rise of microservices patterns, developers had to deal with monolithic systems. Monolithic applications package all features and modules together into a single, large application. While this approach can work well for small-scale projects, it can become problematic as the application grows in size and complexity. In other words, as the monolithic application becomes larger, it can become harder to maintain and update. Additionally, the different components of the application may start to interfere with each other, causing issues that are difficult to diagnose and fix.

On the other hand, microservices are an architectural approach to building applications in which the different components are broken down into smaller, more manageable pieces. Since each microservice has a single responsibility and can be developed and deployed independently of the others, development and maintenance become easier while enabling faster iteration cycles, more flexible scaling, and improved fault isolation.

On the human side, this architecture enables teams to work independently on different parts of an application, using the programming language, framework, tools, and data stores that they are most comfortable with. When managed correctly, this can lead to significant productivity improvements. Applications can be polyglot, with different microservices written in different programming languages, using different frameworks and tools, and even using different data stores. This ends the "one-size-fits-all" approach and makes technical decisions based on what is best for each microservice, not on personal preferences or team familiarity. It's not a problem if one team prefers Python and another prefers Go; the choice can be made based on the specific needs of each microservice. The Python team and its Go counterparts can work independently as long as they agree on the API. All developers are familiar with APIs, so regardless of the programming language, framework, or tools used, they can communicate and collaborate effectively.

One of the most notable works of documentation around microservices is Chris Richardson’s microservices patterns. These patterns are publicly accessible on microservices.io. Some of the most common ones are described below.

Database per Service

In a microservices architecture, each service should have its own private database that can only be accessed via its API. This approach ensures loose coupling between services. Since services may have different data storage requirements, they can use different types of databases.

The "Shared Database" anti-pattern should be avoided, as it can lead to issues when scaling and maintaining the system.