Microservices Architecture

source: https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices

In summary, the microservice architectural style (MSA) is an approach to develop a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

These services are built around business capabilities and deployable independently by fully automated deployment machines. There is minimal centralized management of these services, which can be written in different programming languages and use different data storage technologies.

Features

The top characteristics of microservices include:

• Applications are developed as a suite of small services, each running as an independent process in its own logical machine (or Linux container)
• Services are built around capabilities: the principle of single responsibility
• Each microservice has a separate code base and belongs to a separate team
• Services can be replaced / upgraded / resized / deployed independently
• Lightweight standard communication is used, often REST calls via HTTP
• Potentially heterogeneous environments are supported

Why Microservices

• Small and focused: Microservices must focus on a unit of work and as such are small. There are no rules about the size of a microservice. One commonly referenced rule is the Two Pizza Team rule, which states that if you can’t feed the team building a microservice two pizzas, your microservice is too big. You want the microservice to be small enough that you can rewrite and maintain the entire microservice easily within a team if you need to.
• A microservice should also be treated like an application or product. It should have its own source code management repository, and its own delivery pipeline for builds and deployment.
• Loose coupling: Loose coupling is an absolutely essential feature of microservices. You must be able to deploy a single microservice only. There should be no coordination for deployment with other microservices. This loose coupling allows for frequent and rapid deployments, thus obtaining much needed functionality and capabilities for consumers.
• Language independent: It is important to use the right tool for the right job. Microservices should be built using the programming language and technology that makes the most sense for the task at hand. Microservices are composed together to form a complex application, and they do not need to be written using the same programming language. In some cases, Java may be the correct language, and in others it may be Python, for example.
• Communication with microservices is done via language-independent APIs, usually a Hypertext Transfer Protocol (HTTP)-based resource API, such as REST. You should standardize on the integration, not on the platform used by the microservice. Language neutrality makes it easier to use existing skills or the most optimal language.
• Bounded Context: What we mean by bounded context is that a particular microservice does not “know” anything about the underlying implementation of other microservices around it. If, for some reason, a microservice needs to know something about another microservice (e.g., what it does or how it should be called), you don’t have a bounded context.

Benefits

• Faster and easier deployment and remediation with smaller services. Take advantage of the “divide and conquer” paradigm in software delivery and maintenance.
• Ability to horizontally extend individual services. Not sharing the same deployment platform with other services allows each service to be extended as needed.
• Choose the right tool, language and technology per service, without having to conform to a homogeneous environment dictated by a shared infrastructure.
• Potential for fault isolation at the microservice level by protecting services from common infrastructure failures due to service failure. When a system is designed to withstand the failure of some microservices, the result is higher availability for the system.
• Goes hand in hand with continuous delivery and integration.
• Fosters DevOps culture with better control over services and less routine infrastructure maintenance.
• More autonomous teams lead to faster/better development.
• Facilitates A/B testing and canary deployment of services.
• Traditional divide and conquer advantages.

Drawbacks

The disadvantages of MSA are the direct results of a higher service distribution. There is also a higher cost for having less common infrastructure. The disadvantage can be listed as follows:

• Network reliability is always a concern.
• Less tooling / IDE support given the distributed nature.
• Cascading failure tracking, monitoring and resolution is complex.
• Quality assurance, especially integration testing, can be difficult.
• Debugging is always more difficult for distributed systems.
• Greater complexity — higher fixed costs and overhead.
• Heterogeneous environments are difficult and expensive to maintain.

DISTRIBUTED MODULARITY

While modular design is a common practice appropriate in just about any circumstance and environment, the logical and physical distribution of modular units varies considerably, depending on the system architecture.
Some factors to consider:

• The number of developers: The ideal size for a development team is between 5 and 10 people, and each team can focus on one or more microservices. In an organization with only 1 or 2 development teams, the argument for decoupling work is less compelling and the resulting overhead may be too costly.
• Can you adapt your staff to DevOps? One of the advantages of MSA is its adaptability to a DevOps methodology and the resulting higher agility. This requires the lines to be blurred between development and operations. Not all organizations are prepared for the cultural shift required.
  Do you have a production-quality cloud infrastructure: self-service, on-demand, elastic, API-based consumption model with multi-tenant billing capabilities? How easy is it for independent teams to deploy services in production?
• Can you afford higher upfront costs? Almost all software methodologies and paradigms seek to maximize ROI and minimize costs. However, costs are not always distributed evenly across different stages of the software lifecycle. Deploying individual services and a distributed architecture increases the complexity and fixed costs associated with the environment.
• Do you have a network that can support the architecture? The distributed nature of an MSA environment puts more emphasis on the network and conversely, a more reliable network is required to support such an architecture.
• How well are you able to troubleshoot system errors? Like any distributed system, an MSA environment can be very difficult to analyze and troubleshoot.