Improved Scale and Resource Utilization
Applications today are commonly scaled up by increasing the resources available to one or more deployments of the application, or they are scaled out by increasing the number of instances. Basically, we either put our application on bigger boxes, or create more instances of the application, and then load balance across those instances. In the case of a monolith, if one feature of the application requires additional scale, the application as a whole is scaled up or out.
We can, for example, have a feature that requires a lot of memory to perform its work, and only a few number of instances. Ideally this task would run on a few high memory instances. Another feature in the application might use more CPU or bandwidth and run optimally on a larger number of smaller instances. Because the features are compiled into a single application, we need to deploy the application to resources that satisfy both of these requirements. As the application scales, we may end up with a lot of unused, costly resources using instances that must meet these very different resource requirements.
A microservices architecture allows us to scale features of the application as needed and deploy the features to instances that better match their resource requirements. If the catalog service needs to be scaled up to meet demand, it can be without having to scale the other services that compose the application. If the recommendation service requires a lot of memory, it can simply be deployed to instances with more memory. It’s still possible to deploy the various services to the same instances, but we have the ability to better optimize for cost and scale in our deployments. In Figure 1.2, we can see that Service A is deployed to a small number of large instances whereas Service C is deployed to a larger number of smaller instances.
