Scale cube and micro-services
The model defines three ways to scale an application: X, Y, and Z.
X-axis scaling is a commonly to scale an application. You simple run multiple instances of the application behind a load balancer.
The load balancer distributes requests amongst the N identical instances of the application.
Z-axis scaling also runs multiple instances of the application. However, unlike X-axis scaling, each server is responsible for only a subset of the data. The router in front of the instances uses an attribute of request to route it to the appropriate instance.
The router uses the
x attribute of the request to decide select one of the
N identical instances of the application. A commonly used attribute is the
userId. Different users are routed to different instances of the application.
X and Z-axis scaling improve the application's capacity and availability. Neither approach, however, solves the problem of increasing development and application complexity. To solve those problems we need to apply Y-axis scaling a.k.a. functional decomposition. Y-axis scaling splits a monolithic application into a set of services.
A service, is a mini-application that implements a set of related functionality such as order management, customer management, etc. A service is called using X-axis and Z-axis when necessary. “For example, the Order Management service is deployed as a set of load balanced service instances.”
This is my high-level definition of micro-services: an architectural style that functionally decomposes an application into a set of services. Note that this definition does not say anything about size. Instead, what matters is that each service has a focussed, cohesive set of responsibilities.
Micro-services as a form of modularity
The micro-service architecture uses services as the unit of modularity. A service has an impermeable boundary that is difficult to violate. As a result, the modularity of the application is much easier to preserve over time. There are other benefits of the micro-service architecture including the ability to deploy and scale services independently.
Each service has its own database
A key characteristic of the micro-service architecture is that the services are loosely coupled. One way this loose coupling is achieved is by each service having it's own datastore.
Now that we have defined the micro-service architecture and described some of its essential characteristics, lets look how this applies to the FTGO application.