This article is the last of a three-part series describing the design and implementation of microservices. Check out the other articles in the series:
Microservices have a lot to offer today's application development. When implemented properly, they allow applications to change quickly without side effects. But they are not a panacea for all woes in software development. They do come with trade-offs.
In this article, we compare the potential drawbacks of microservices and the benefits you should consider before implementing them.
More operational complexity in exchange for more flexibility
A microservice-oriented architecture (MOA) incurs more complexity to get more flexibility. In a monolithic application, all the parts are in one box, so to speak. Therefore, you can declare dependencies in code and not worry too much about deployment issues. All the parts ship together at deployment time.
With an MOA, all the parts are all over the place on the network. Thus, you have to spend more time "wiring" the microservices together to get the overall application up and running. The wiring involves identifying the network's microservice and enabling authorized access to all the microservices that make up the MOA. This task includes providing credentials so the MOA can access the particular microservice and fiddling with firewall and router settings at the physical level of the application's operation.
The bottom line is that microservices do indeed offer more flexibility in terms of maintenance and upgrade, but that flexibility comes at the price of more complexity.
Trading resources for greater independence
MOAs require a lot of horsepower. Remember, each microservice in the MOA comes with its own runtime environment and data storage. Thus, in some cases, even the most scaled-down microservice can eat up as many resources as a single monolithic application. And that's only on the hardware end of things once the MOA is in production.
In terms of development, each microservice in an MOA requires its own set of developers, source code management system, testing process, and set of scripts to support automated deployment. This all adds up. But it is the price for the independence that microservices provide.
In short, it's a trade-off. Many companies are willing to pay the premium for an MOA to get the operational independence required for faster release cycles.
Reliability requires complex orchestration frameworks like Kubernetes
Implementing a microservices-oriented application is not a matter of creating a few independent services and deploying them to the network along with a configuration file that ties the services together. There is a lot more planning involved.
Fortunately, the complexities of creating, deploying, and supporting an MOA have revealed design patterns that have become well known over the years. In turn, these patterns have been used to create orchestration frameworks that are well suited to supporting MOAs. Probably the best known of these orchestration frameworks is Kubernetes.
Kubernetes makes it so that developers and system administrators can run Linux containers as services on a network within a data center. Kubernetes also provides the capability to wire these services together to create a microservices-oriented application. To quote Kubernetes evangelist Kelsey Hightower, "the data center is the computer."
Kubernetes is a transformational technology. It's also a complex technology that has a significant learning curve. But it can run very large applications with a high degree of reliability. Kubernetes guarantees that once you have configured an MOA, Kubernetes will keep it all going in the face of many dangers. It is not unusual for Kubernetes to run an MOA that has dozens, if not hundreds, of microservices.
Kubernetes is quite a technical achievement. Despite its complexity, you need this type of orchestration framework to run an MOA at scale. An MOA has a lot of moving parts, and any one of them can fail at any time. Keeping it all up and running is beyond human capability. Hence, the trade-off is that to run a microservices-oriented application reliably, you need to incur the complexity of an orchestration framework.
Are MOAs worth the extra labor and price?
Microservice-oriented applications are a compelling approach to software development in today's world. The emergence of TCP/IP and the internet has created networking standards that make MOAs possible. Segmenting applications into discrete, independent microservices creates a high degree of flexibility that enables shorter release cycles. A well-constructed MOA gets better software into the hands of those who need it fast.
But MOAs come with a price. Getting a number of microservices to work together reliably as a microservices-oriented application is a complex undertaking. The trade-offs can be significant, but so are the benefits. MOAs have a lot to offer companies that have applications that need to run at web scale and provide benefits to a large number of users.
Learn more about microservices on Red Hat Developer
Check out the following resources for more tips about building and deploying microservices:
- Download chapters from the upcoming e-book Kubernetes Native Microservices with Quarkus and MicroProfile
- 5 design principles for microservices
- Application modernization patterns with Apache Kafka, Debezium, and Kubernetes
- Distributed transaction patterns for microservices compared
- An elegant way to performance test microservices on Kubernetes
