Are Microservices Right for You?
The Answer Is… It Depends
How do you know whether microservices make sense for your organization? If you are trying to figure that out, please read on.
What Are Microservices?
Microservices are not magic, but they are an approach to breaking up an application into usable components that can be connected together to form systems. They are called microservices because their components tend to be smaller than the traditional Service-Oriented Architecture (SOA) services popular for more than a decade. An individual microservice:
- Implements a single task within a domain bounded context. This is a fundamental characteristic of a microservice and promotes a high level of granularity and separation of concerns that preserves microservice autonomy and independent deployability.
- Is loosely-coupled and makes use of little or no knowledge of the definitions of other microservices — enforcing separation of concerns.
- Is autonomous and can be developed and modified with less coordination among different development teams — promoting agile development practices.
- Is independently deployable and can be individually tested, rolled out, and rolled back without impacting other microservices — enabling cloud-based automated deployment, scaling, reliability, and failover.
If an application component does not meet these four basic objectives, it is not a microservice — and it cannot deliver all the benefits of the microservice architectural style.
What Are Monoliths?
In software engineering, a monolithic application describes a software application that is designed and/or deployed without discernible modularity. In practical terms, large totally monolithic applications have not been implemented for a long time — though a few probably still exist. Nowadays, when the term monolith is used in comparison to microservices it usually means one of today's most commonly used architectural patterns, the layered architecture, also known as the n-tier architecture pattern.
The layered architecture is popular because it is reasonably easy to understand and use. It decomposes application components into neat layers or tiers, each with its own area of responsibility. It also separates the user presentation from the rest of the application, facilitating the implementation of Web, mobile, and/or desktop GUIs for the same application. With a well-designed persistence layer, it is even possible to maintain a high degree of DBMS independence.
Today’s most popular SOA frameworks, Spring Boot and Jakarta RESTful Web Services (JAX-RS) are layered architectures that can work very well. They are powerful, reliable, and manageable implementations of the SOA pattern. Before the advent of cloud computing, it was easy to argue that SOA was the best architecture for a very wide range of business applications and services. However, for cloud computing, it has some inherent drawbacks:
- At a minimum, its business and persistence layers must be deployed together as a single, monolithic, executable — though its presentation and database layers can be connected by networks to the rest of the monolith.
- Much of its large supporting software framework must be deployed with it.
- The flow of control must travel through each layer from top to bottom (presentation->business->persistence->database) and then travel back up through the same layers.
- Its inherently tight component coupling can have a negative impact on development speed and agility.
What Problems Do Microservices Solve?
Microservice architecture exists to help resolve some fundamental software development, deployment, and runtime problems by:
- Shortening software development cycles and optimizing agile software development and maintenance practices.
- Promoting rapid application feature iteration and simplifying software testing, continuous integration, and continuous delivery.
- Exploiting the automated deployment, scaling, reliability, and fail-over capabilities available with cloud containers and container orchestration.
Ultimately, the idea is that by increasing the isolation between software components, microservices can deliver small discrete parts of a system both rapidly and independently, and by utilizing containers and container orchestration can deliver a high degree of horizontal scalability and fault tolerance across cloud clusters.
What Are the Pro’s and Con’s of Microservices?
There is no such thing as a free lunch! That’s especially true when it comes to software design — where almost every important choice represents a compromise to be weighed in terms of cost versus benefit.
Done right, microservice architecture really can deliver the benefits it promises. It actually can:
- Enable faster, more agile software development.
- Help you iterate application functionality more quickly and with less fuss and bother.
- Open up the real power and capabilities of the cloud for your applications and users.
But, all that comes with a cost. Using microservice architecture demands more software engineering discipline and rigor — more thinking for less coding.
Because microservices require the effective application of software architecture and design, it is important to put to rest some erroneous assumptions about agile software development. Agile does not forbid software architecture and design. The Agile Manifesto says, “The best architectures, requirements, and designs emerge from self-organizing teams”, an eminently useful and practical approach.
One of the trade offs of microservice architecture is that it tends to create more, but smaller, components than SOA. That can increase complexity, which grows exponentially with the number of components. A pretty good formula for quantifying complexity is c = n(n-1)/2, where n is the number of components. This means that traditional hierarchical, top down, configuration and control mechanisms do not work particularly well for microservices. Large microservice deployments require more dynamic and self-organizing configuration and control techniques, which fortunately can also lead to better horizontal scalability and failover capabilities in the cloud.
Microservices and cloud computing will be new to most organizations. It is probably risky to jump directly into the deep end of the pool. It’s usually better to start at the shallow end and take things a step at a time, beginning with small projects — emphasizing learning and communicating as you move into a new way of implementing software. Companies like Amazon and Netflix have been enormously successful using a microservice approach, but they did not get there overnight.
How Do I Decide?
If your company can answer “true” for any of the following statements, then you can benefit from microservices:
- Digital Transformation really is an important part of our business strategy.
- We really do need to exploit the automated deployment, scaling, reliability, and fail-over capabilities available with cloud computing.
- We really do need to be faster and more agile in software development and application feature iteration.
- We really are willing to innovate and change how we do things.
- We really cannot continue with the status quo.
If you cannot answer “true” for some of these statements, you are probably better off doing the best you can with SOA and one of the major SOA frameworks. Within their limitations, they really can and do work well.
If you would like to know more about the principles of Agile development, we recommend looking at Principles Behind the Agile Manifesto.