Elastically and selectively scalable

Since microservices are smaller units of work, it enables us to implement selective scalability and other Quality of Services (QoS).

Scalability requirements may be different for different functions in an application. Monolithic applications are generally packaged as a single war or an ear. As a result, applications can only be scaled as a whole. There is no option to scale a module or a subsystem level. An I/O intensive function, when streamed with high velocity data, could easily bring down the service levels of the entire application.

In the case of microservices, each service could be independently scaled up or down. Since scalability can be selectively applied for each service, the cost of scaling is comparatively less with the microservices approach.

In practice, there are many different ways available to scale an application, and this is largely constraint to the architecture and behavior of the application. The Scale Cube defines primarily three approaches to scale an application:

• X-axis scaling, by horizontally cloning the application
• Y-axis scaling, by splitting different functionality
• Z-axis scaling, by partitioning or sharding the data.

When Y-axis scaling is applied to monolithic applications, it breaks the monolithic into smaller units aligned with business functions. Many organizations successfully applied this technique to move away from monolithic application. In principle, the resulting units of functions are inline with the microservices characteristics.

For instance, on a typical airline website, statistics indicates that the ratio of flight search versus flight booking could be as high as 500:1. This means one booking transaction for every 500 search transactions. In this scenario, search needs 500 times more scalability than the booking function. This is an ideal use case for selective scaling:

The solution is to treat search requests and booking requests differently. With a monolithic architecture, this is only possible with Z scaling in the scale cube. However, this approach is expensive, as, in Z scale, the entire codebase will be replicated.

In the preceding diagram, Search and b are designed as different microservices so that Search can be scaled differently from Booking. In the diagram, Search has three instances and Booking has two instances. Selective scalability is not limited to the number of instances, as shown in the preceding diagram, but also in the way in which the microservices are architected. In the case of Search, an In-Memory Data Grid (IMDG) such as Hazelcast can be used as the data store. This will further increase the performance and scalability of Search. When a new Search microservice instance is instantiated, an additional IMDG node will be added to the IMDG cluster. Booking does not require the same level of scalability. In the case of Booking, both instances of the Booking microservices are connected to the same instance of the database.