When discussing microservices, it is better to start with the question of size. Evidently, software systems are growing in size in response to increasing demands from users. The number of features, their complexity and sophistication grow and so do the lines of code in software projects. Even in well-structured living systems, the size of components and their number is getting bigger over time. Given limited human mental capabilities, the proportion of the system that is understood by a single programmer shrinks, which leads to the increased number for developers in the team. Bigger team size leads to the growth of the communication overhead and so less time for writing code, leading to the need for additional developers, which introduces a self-reinforced cycle. 

The traditional monolithic way to build systems as a single project with a single deployment module or executable and a single database is therefore becoming less and less efficient, and ultimately just makes it impossible to deliver working software in a timely manner. An alternative approach is to split the monolith into separate projects, called microservices, that can be developed independently.

Microservices look like the only feasible alternative to the monolithic approach, and are therefore becoming more and more popular. But, what are they precisely? According to http://microservices.io, microservices—also known as the microservice architecture—is an architectural style that structures an application as a collection of loosely-coupled services, which implement business capabilities.

What does it mean? In essence, this is what would happen to the well-structured application if one would tear it apart and make an autonomous application from each module responsible for single business feature.

The autonomy in this definition applies on multiple levels:

• Codebase and technological stack: The code of the service should not be shared with other services.
• Deployment: The service is deployed independently of other services both in terms of time and underlying infrastructure.
• State: The service has its own persistent store and the only way for other services to access the data is by calling the owning service.
• Failure-handling: Microservices are expected to be resilient. In the case of failures of downstream services, the one in question is expected to isolate failure.

These aspects of autonomy allow us to reap a number of benefits from a microservice-based architecture:

• Continuous delivery even for very complex applications
• The complexity of each service is low because it is limited to a single business capability
• Independent deployment implies independent scalability for services with different loads
• Code-independence enables polyglot environments and makes the adoption of new technologies easier
• Teams can be scaled down in size, which reduces communication overhead and speeds up decision-making

Of course, there are downsides to this approach as well. The most obvious drawbacks are related to the fact that microservices need to communicate with each other. To name a few important difficulties:

• Unavailability of habitual transactions
• Debugging, testing, and tracing calls involving multiple microservices
• The complexity shifts from the individual service into the space between them
• Service location and protocol discovery require lots of effort

But don't be scared! In the reminder of this chapter, we'll build just a single microservice so we won't be affected by these weaknesses.