Microservices and the Scale Cube

Microservices and the scale cube. Model of a cube with x-axis, y-axis and z-axis marked

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!

Leave a Comment

Your email address will not be published. Required fields are marked *

Thank You

We're Excited!

Thank you for completing the form. We're excited that you have chosen to contact us about training. We will process the information as soon as we can, and we will do our best to contact you within 1 working day. (Please note that our offices are closed over weekends and public holidays.)

Don't Worry

Our privacy policy ensures your data is safe: Incus Data does not sell or otherwise distribute email addresses. We will not divulge your personal information to anyone unless specifically authorised by you.

If you need any further information, please contact us on tel: (27) 12-666-2020 or email info@incusdata.com

How can we help you?

Let us contact you about your training requirements. Just fill in a few details, and we’ll get right back to you.