Microservices and Microservices Architecture
Learn the pros and cons of microservices and how they differ from monoliths.
What are microservices?
The term “microservices” is used to describe a traditional “separation of concerns” pattern within a distributed, networked project. Microservices is an idea that follows an old fundamental UNIX philosophy “of small, sharp tools”. Both concepts build on another foundational computer science pattern of “composition” which means that complex systems are the sum of lower-level composable entities.
Composition occurs through all layers of a software project. At the lowest level, the “unit level”, individual independent code functions interact with each other over a shared interface to create collections or “libraries” of code. At the operating system shell level, shell commands can be composed to create a pipeline of higher-level functionality. Microservices are a level of composition that happens between web services. A Microservice is a web service that is responsible for one piece of domain logic. Microservices interact with each other via simple network protocols like REST to complete actions but they have no knowledge of how other services work internally. This harmonious interaction between microservices is a microservice architecture.
A microservices architecture (MSA) allows software teams to improve their release workflows. Amazon, Netflix, and eBay are among the companies that openly embrace this way of building software and they've contributed back to the community by publishing their own experience and developing tools that can help others to adopt.
The guiding principle of microservices is to build an application by splitting its business components into small services that can be deployed and operated independently from each other.
Developers can then organize in smaller teams specializing in different services, with different stacks and decoupled deployments. This separation of concerns and decoupled independent function enables streamlined agile software development practices like continuous delivery and integration.
Service-oriented architecture (SOA) vs. microservices
Service-oriented architecture and microservices are two types of higher order, web service architectures. Microservices are a lite version of SOA. The distinction between the two architecture types is the bureaucratic classification of service types. SOA has four basic service types: business, enterprise, application, and infrastructure services. These types define the related domain-specific responsibility of the underlying services. Comparatively, microservices only have two service types: functional and infrastructure.
Both architectures share the same set of standards at different layers of an enterprise. The existence of MSA comes down to the success of SOA pattern. Hence, MSA pattern is a subset of SOA. Here the main focus is on the runtime autonomy of each service.
Monolith application vs. microservices
Microservices decouple major business domain-specific concerns into separate independent code bases. A monolithic application architecture can be thought of as the inverse of microservices. A Monolith is one code base that couples all of the business concerns together. Monoliths can be convenient early on in a project's life for ease of code management cognitive overhead, and deployment. This allows everything in the monolith to be released at once.
Many projects initially start out as a monolith and then evolve into a microservice architecture. As new features are added to a monolith, it may start to become cumbersome to have many developers working on a singular codebase. Code conflicts become more frequent and the risk of updates to one feature introducing bugs in an unrelated feature increases. When these undesirable patterns arise, it may be time for a discussion on a migration to microservices.
How microservices architecture works
Consider a hypothetical e-commerce software project as an example. There are some clearly defined domain-specific business features. E-commerce sites have an authentication system for user login, logouts. A shopping cart to persist a list of products the user is interested in. A billing system allows users to pay for their purchases.
In a microservice architecture, these example business domains would be independent services. Take the billing system as a specific example. Depending on company employee count there may be a dedicated “billing team” that owns the development and quality assurance of this billing microservice. The billing microservice would have its own release schedule and deployment playbooks. The billing service would provide a documented and versioned API so other services could communicate and utilize its functionality.
Pros and cons of microservices
+ Horizontal scaling
Microservices are distributed by design and can be deployed in clusters. This enables dynamic horizontal scaling across the service boundaries. If a microservice reaches capacity for load, new instances of that service can rapidly be deployed to the accompanying cluster to help relieve the pressure.
+ Independent team execution
Microservice ownership teams can operate independently of other feature teams in the organization. This allows for more rapid execution and delivery of new functionality.
+ Deeper focus on quality
The separation of business concerns into independent microservices ensures that the service team owning that service is focused on the complete quality deliverable.
- Exponential infrastructure costs
Each new microservice an organization adds to its production deployment comes with its own cost of test suite, deployment playbooks, hosting infrastructure, monitoring tools and more.
- Added organizational overhead
An added level of communication and collaboration is needed to coordinate updates and interfaces between microservices architecture teams.
- Development environment complexity
When a project is broken into multiple microservices it adds a challenge of reproducing the distributed architecture during local development setup.
The future of microservices
Containerization and the deployment of containers is a new pattern of distributed infrastructure. Tools like Docker and Kubernetes are used to package up a service into a complete container, which can be rapidly deployed and discarded. These new infrastructure tools are complementary to the Microservices architecture. Microservices can be containerized and easily deployed and managed using a container management system.
The adoption of microservices should be seen as a journey rather than the immediate goal for a team. Start small to understand the technical requirements of a distributed system, how to fail gracefully and scale individual components. Then you can gradually extract more and more services as you gain experience and knowledge.
The microservice architecture is still fairly young but it's a promising way of developing applications and it's definitely worth looking into but remember that it might not (yet) be a good fit for your team.