The strongest microservices use cases in the cloud

Breaking down microservices use cases

The first use case that should be reviewed is using microservices to facilitate cloud adoption. Most development teams recognize that application architectures for optimum use of public and hybrid clouds are different. Few are prepared to outline just what those differences are and how orderly deployment, secure and compliant operations and full efficiency of hosting can be realized. Microservices offer a path to a new application model that is easily hosted in the data center, even in monolithic form, and still easily moved to a cloud platform.

Microservices go beyond service-oriented architecture (SOA) in defining a service model that’s dynamic in terms of binding services. A microservice is a unit of functionality designed (if properly done) to be stateless and scalable and, at the same time, to be connected in a coload sense, a tightly coupled sense or a loosely coupled sense. You can integrate microservices and core application components into a single machine image, replicating the services and avoiding the issues of component connection and integration. The same microservices can be extended as controlled shared services using an API manager that replicates the SOA mechanisms for security and then exposed in RESTful form where governance permits. That range of options is unparalleled in application design, and it’s a perfect on-ramp for cloud computing.

The second microservices use case focuses on taking a more business-centric look at classic SOA targets through microservices. Microservices, to be efficient, demand that application architects team up more with enterprise architects to identify reusable business functions to turn into microservices. That’s an important, and valuable, departure from the traditional SOA model where services were defined based primarily on technical considerations. Companies have realized recently that there needs to be more business-based assessment of IT elements and componentization but have been hazy on how to start.

A good microservices strategy begins by identifying the business functions of applications and then mapping common or very similar functions across applications. These functions become the targets for microservices creation, though it’s important to expect that some will have to be generalized to maximize reuse and some may map to a series of microservices rather than a single one, based on technical goals, like stateless behavior and scalability.

Microservices use case number three is using microservices to take advantage of cloud elasticity and scalability. Enterprises know that the primary benefit of the cloud really isn’t lower compute cost but rather more efficient and effective operation, yielding improved business agility and application quality of experience. The problem is that it’s not always clear how you take advantage of cloud features to attain those benefits. Microservices are the best answer.

Elasticity or scalability means expanding or contracting application resources to match workload and respond to failures. This means structuring applications so that the “bottleneck” components of applications can have multiple copies instantiated and workloads can be balanced among the copies. Microservices illustrate how to build components to make this process easy, and the same API managers used to apply security/governance practices to microservices can also be used for load balancing and instance management.

This use case can also be viewed as a way of moving applications to container-based deployment, an increasingly important goal for enterprises looking at cloud computing. Because microservices are relatively small functional elements, they lend themselves to the low-overhead model of containers, and there’s been significant work done to demonstrate the optimum marriage of the two technologies.

The last, and perhaps most sophisticated, of the microservices use cases is creating the event-driven enterprise. Application design has long been based on the notion of an application as a series of components linked through a static workflow, usually supported via a message/service bus. The view of enterprise IT as a set of responses to business events is an alternate model with more potential impact on both IT and the business overall than either componentization or cloud computing. However, event-driven enterprise processes are also a profound departure from traditional design and a challenge for architects and developers.

Finding a use case that works

Microservices support an event-driven approach to business IT more directly than any current technology development. Fine-grained microservices implemented as stateless functions can be pushed outward toward the worker as needed, and this opens a totally new model of application design, one where components of functionality are marshaled as needed and pushed to a pathway between the worker point of origination and the information repository where company data is collected.

Most companies will find one of these use case areas of microservices relevant, and many will find that several of them (perhaps even all of them) apply. When you add that to the fact that microservices don’t automaticallyaddress these points, it becomes clear that use cases are a guide to applying microservices but not necessarily a roadmap. The smartest thing to do is to look at all the points above and prioritize them in terms of immediate and long-term importance. Then, order the microservices features associated with each of the important points, and decide which specific microservices capabilities are most important.

Microservices are still in their infancy, and it’s easy to make a mistake with them because best practices in any given area are still immature. That means that, as valuable as microservices will be, and are today, they are still a riskier strategy than something supported by more users over a longer period. Take your time in assessing the use cases, and develop your own microservices strategy carefully to prevent early errors that will prove difficult to correct.