Microservice use cases

Microservice is not a silver bullet, and it will not solve all the architectural challenges of today's world. There is no hard and fast rule, or a rigid guideline on when to use microservices.

Microservices may not fit in each and every use case. The success of microservices largely depends on the selection of use cases. The first and the foremost activity is to do a litmus test of the use case against the microservices benefits. The litmus test must cover all microservices benefits we had discussed earlier in this chapter. For a given use case, if there are no quantifiable benefits, or if the cost is outweighing the benefits, then the use case may not be the right choice for microservices.

Let's discuss some commonly used scenarios that are suitable candidates for a microservice architecture:

• Migrating a monolithic application due to improvements required in scalability, manageability, agility, or speed of delivery. Another similar scenario is rewriting an end-of-life heavily-used legacy application. In both cases, microservices presents an opportunity. Using a microservices architecture, it is possible to replatform the legacy application by slowly transforming functions to microservices. There are benefits in this approach. There is no humongous upfront investment required, no major disruption to business, and there are no severe business risks. Since the service dependencies are known, the microservices dependencies can be well managed.
• In many cases, we build headless business applications or business services that are autonomous in nature. For instance, payment service, login service, flight search service, customer profile service, notification service, and more. These are normally reused across multiple channels, and, hence, are good candidates for building them as microservices.
• There could be micro or macro applications that serves a single purpose and performs a single responsibility. A simple time-tracking application is an example of this category. All it does is capture time, duration, and the task performed. Common use enterprise applications are also candidates for microservices.
• Backend services of a well architected, responsive, client side MVC web application (Backend as a Service (BaaS)). In most of these scenarios, data could be coming from multiple logically different data sources, as described in the Fly By Points example mentioned in Chapter 1, Demystifying Microservices.
• Highly agile applications, applications demanding speed of delivery or time to market, innovation pilots, applications selected for DevOps, System of Innovation type of applications, and so on, could also be considered as potential candidates for microservices architecture.
• Applications that we could anticipate getting benefits from microservices, such as polyglot requirements; applications that require Command Query Responsibility Segregation (CQRS); and so on, are also potential candidates of microservices architecture.
• Independent technical services and utility services, such as communication service, encryption service, authentication services and so on, are also good candidates for microservices.

If the use case falls into any of these categories, they are potential candidates for microservices architecture. There are a few scenarios that we should consider avoiding in microservices:

• If the organization policies are forced to use centrally-managed heavyweight components, such as ESBs, to host the business logic, or if the organization has any other policies that are hindering the fundamental principles of microservices, then microservices are not the right solution, unless the organizational process is relaxed.
• If the organizations culture, processes, and more are based on traditional waterfall delivery model, lengthy release cycles, matrix teams, manual deployments and cumbersome release processes, no infrastructure provisioning, and more, then microservices may not be the right fit. This is underpinned by the Conway's law. The Conway's law states that there is a strong link between organizational structure and the software they create.