What does microservice architecture mean for the cloud?
by Tom Nolle
Tom Nolle explains why microservice architecture should not be considered ready-made for the cloud and how developers should approach a combination of the two.
The notion of services is symbiotic with cloud computing because it tends to generate higher levels of componentization of applications, resulting in better agility and the flexibility to replicate or replace failed elements. It seems logical to assume that microservices would be even better, but application architects and planners have to beware of differences in the meaning of the term popular in modern usage. They also need to understand the costs and benefits tradeoff of microservice structures, and be able to converge the two primary meanings of the term into a single development practice through the "strip mall" pattern.
For years, development teams have been moving away from monolithic applications -- giant bundles of code that require considerable management attention just to coordinate the work of developers. Modular software, where applications are collected modules written more independently, is the result of this migration. More recently, the idea that software features could be assembled from reusable components has created an actual separation of these modules into services, and virtualization and the cloud has driven new interest in deploying these services on elastic resource pools. All three of these stages of application evolution seem to point to a notion that more componentization is better, which leads to the concept of microservices.
Microservices are components that represent a highly specialized "nuclear" function, operate independently and often in a RESTful way, and are accessed through a single simple API (often HTTP-based). The fact that they are so independent and functionally specialized means that it's possible to assign microservices to multiple developers and the simple API means that they can be collected easily into an application via calls from a root service (a "storefront") or through a service bus interface.
Complexity of Web apps pushes microservices
One dimension of the microservice architecture push comes from the growing complexity of Web application development. In fact, a microservices design pattern is a storefront component connected to a series of subordinate, functionally independent microservices. This approach offers faster team development and better debugging control than even a traditional modular application assembled in a Java WAR (Web Archive). The more complicated an application is, the more it's likely to benefit from microservice structuring.
But it's the virtualization and cloud application of microservice architecture models that's gaining the most attention. The cloud offers significant benefits in horizontal scaling and microservices are critical in building applications that scale specifically where heavy function use demands, rather than for an entire monolithic application. As applications become more complex, microservices may be essential in making this kind of scaling practical by limiting wasting of resources. But the cloud can also add significant delay to data paths, to the point where application performance suffers. Only proper design can accommodate performance, flexibility and agility.
The best microservice architecture will be a single storefront feeding a collection of single-service subordinates. The decisions made in the storefront component will steer the work to a microservice for completion.
If microservices are nuclear functions, they can be either business-process-based (vertical) or technology-based (horizontal). Most application architects are wary of horizontal service segmentation because it rarely reduces development time or improves debugging versus simply using middleware library tools. It also raises the risk of creating too many API calls.
Every developer knows that the weakness of any service-oriented approach to application design, including microservices, is the overhead created by the loose coupling of the component through network-enabled APIs. In-memory direct calls between modules are faster by orders of magnitude, and the incremental delay of network APIs can add up if many calls are required to complete a logical transaction. That means you have to balance the benefit of microservices in deployment agility and functional separation with the risk affecting worker quality of experience.
Striking a balance with microservices
Striking this balance requires starting with a business process view of an application. Who uses this, how many slightly different ways might the functions of the application be divided based on worker needs, how often is the application likely to be used, and how critical is it that the application's performance be stellar? But also be aware of the logical length of the workflows the application represents, because it's this factor that limits microservice segmentation.
The best microservice architecture will be a single storefront feeding a collection of single-service subordinates. The decisions made in the storefront component will steer the work to a microservice for completion. This structure would not contain a series of microservice "tiles" that fed storefronts from other storefronts or daisy-chained components. These will increase application response time through API delays. That means you'll have to balance the division of applications into small components and the need to chain through many such components to process a single request or transaction.
This structure is a good first step in deciding how "micro" to make a microservice structure. A complex tree structure behind a storefront is an invitation to a long data path for work to follow. The structure can also help visualize an important question, which is whether the microservices behind a given storefront are really independently scalable. If functions are likely to be exercised in groups rather than individually, you've taken componentization into microservices too far; the best approach is to scale as a unit the group of related functions.
Think of a shallow tree of microservices
The challenge this storefront approach poses is that many modern applications involve feeding a single transaction through multiple business systems. Service bus models of transaction workflow are helpful in assuring that related applications are all kept synchronized by processing their common transactions serially. This leads to a strip mall model for microservice adoption; each business application should be structured as a storefront with a shallow tree of microservices behind it. The storefronts themselves should then be linked through service bus flows.
Microservices will add a kind of multi-dimensional workflow notion to cloud applications, a notion that can end up with crossed flows, excessive hops between network-linked components, and performance and stability problems. With proper attention to the details, though, these issues can be contained and the significant benefits of microservices can be realized.
- Learn more about prepping next-gen cloud apps with microservices
- Test your knowledge of microservice architectures
- Discover how to secure REST API endpoints for cloud apps
Dig Deeper on Application programming interface (APIs)
- Editors' Choice for Innovation: OpenLegacy API Platform
- WSO2: What this API management platform can do for developers
- Rethinking modular programming interfaces for microservices