This article is the last part of a three-part series describing the design and implementation of microservices. The first part laid out 5 design principles for microservices, and the second part showed how monolithic applications tend to evolve into microservices.
Microservices have a lot to offer to 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 look at the potential drawbacks of microservices, and considerations you should think about before implementing them.
More complexity in exchange for more flexibility
A microservice-oriented architecture (MOA) incurs more complexity in order 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 not only identifying the microservice on the network but also 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 also 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 increased flexibility comes at the price of increased complexity.
More resources in exchange 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 end up eating 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, its own source code management system, its own testing process, and its own set of scripts to support automated deployment. This all adds up. But it's the price that comes with the independence that microservices provide.
In short, it's a trade-off. Many companies are willing to pay the premium that goes with an MOA in order to get the operational independence required for faster release cycles.
More orchestration in exchange for reliable operation
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's 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 has the wherewithal to guarantee that once you've configured an MOA, Kubernetes will keep it all going in the face of many dangers. It's 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, of which any one 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.
Putting it all together
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 at faster rates.
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