About six months ago we had a look at the microservices architecture. We compared it to the common monolithic architectural approach, and presented some best practices for developing microservices. If you missed the blog post, you can find it here.
Revision of Microservices Best Practices
When we develop a microservices architecture, we must keep current best practices in mind. These include:
-
Autonomous. We should ensure that the services are self-contained, autonomous and independent.
-
Separation of concerns. We should write services that are focused on doing one task well. We should split the components based on functionalities, e.g. products, shopping cart, checkout, inventory, etc.
-
Cohesive. The services must be small and cohesive.
-
Loosely-coupled. We must reduce coupling between services.
If we follow these guidelines, the architecture should be easily scalable. It should then be able to handle an increasing workload and number of concurrent users.
Is there anything else we do to make sure that our application can scale well?
The Scale Cube
Martin Abbott and Michael Fisher wrote a book called “The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise”.
In this book, they introduce the idea of the scale cube. The scale cube is a model for scaling applications by segmenting services and defining microservices. It gives us a way of visualising and building robust, scalable applications. The scale cube also provides us a common language to discuss architectural design.
The scale cube consists three axes representing three dimensions of scaling:
-
X-Axis: Horizontal duplication and cloning of services and data.
-
Y-Axis: Functional decomposition and segmentation. This is the microservices approach.
-
Z-Axis: Horizontal data partitioning along customer boundaries (shards/pods).
The scale cube is a best practices design model that can be applied to any application.
X-axis Scaling
X-axis scaling consists of running multiple copies of the application behind a load balancer. If there are N copies then each copy handles 1/N of the load. This is a commonly used approach of scaling an application. Everything is duplicated which ensures that there are no single points of failure.
This is the easiest approach to scaling. It’s simple and fast to implement.
Disadvantages of X-axis scaling include:
- Because each copy of the application can potentially access all of the data, larger memory caches are needed.
- If we have N copies of the application running, we can have N copies of the data sets. Multiple data sets are problematic.
- It doesn’t solve the problem of increasing application complexity. For this we need to use Y-axis scaling.
Y-axis Scaling
Y-axis scaling splits the application into multiple different services. Each service is responsible for one or more closely related functions. This is the microservices approach. In contrast, X-axis and Z-axis scaling run multiple identical copies of the application.
There are a few different ways of decomposing the application into services:
- We can use verb-based decomposition. We define services that implement a single use case such as searching, selecting items or checkout.
- We can use noun-based decomposition. We define services that are responsible for all the operations related to a particular item such as inventory control or customer management.
- We could use a combination of verb-based and noun-based decomposition.
Advantages of Y-axis scaling include:
- Services and transactions scale well.
- High availability. It’s easy to spin up smaller services.
- There is high fault isolation between services.
- Improves cache hit rate.
One of the biggest disadvantages of Y-axis scaling is that it takes more time to design and architect a decoupled solution. The application becomes more complex to understand and develop as the number of services increases.
Z-axis Scaling
With Z-axis scaling each server runs an identical copy of the application. In this way, it’s similar to X-axis scaling. The difference is that each server is responsible for only a subset of the data. Data is partitioned (i.e, sharded) across a set of servers based on some attribute of each record. If we think of a chain of shops or gyms, then attributes such as geographical location or membership level could be used to partition the data.
Benefits of Z-axis scaling include:
- Each server only deals with a subset of the data.
- Response time is improved.
- Cache utilization is improved.
- Memory usage and I/O traffic is reduced.
- Transactions scale well because database requests are usually distributed across multiple servers.
- Fault isolation is improved because failures only make a portion of the data inaccessible.
Disadvantages of Z-axis scaling include:
- Increased data set complexity.
- We need to partition the data in some way. This can lead to problems if we ever have to repartition the data in a different way.
- It doesn’t solve the problem of increasing application complexity. For this we need to use Y-axis scaling.
Conclusion
Have you used the scale cube when developing an application? Was this post useful? Let us know in the comments, and as always, stay safe and keep learning!