Scalability cube
- 1. Scaling IT Systems: The Scalability Cube Reference: The Art of Scalability, by Marty Abbott and Michael Fisherhttps://www.linkedin.com/in/anildivekar/ ne concept ne page O Most IT systems face the challenge of scaling at some point in time. Organisations use various tools / frameworks and architectural options to address this challenge. Before trying to understand all options / details, it might make sense to grasp the big picture on ways of achieving scalability through a classic model. The model distills all options in to 3 dimensions, and hence is known as the Scalability Cube. X Axis: Cloning / Replicating • Each server running the same code, but operating only on a subset (shard) of the data. • Most commonly, the data is split on geography or other significant characteristics like product SKU, customer accounts etc. Pros: • Simple to understand. • Scales well from the transactions aspect. • Can provide fault isolation and enable alignment to geography specific laws like GDPR. • Can improve response time. Cons: • Can be slower to implement. • Can require more automation to manage increased complexity. • Decomposing the system on functional basis, creating high cohesion, low coupling modules / services. • The splits are dissimilar to each other. For example, an ecommerce system can be split in to order service, product search service and so on. Also, each service can have its own non-shared data store. Pros: • Can provide fault isolation and increased availability. • Can enable parts of the system to scale / evolve at different rates / direction, & have independent lifecycles. • Enables organizational scalability due to segmentation of teams based on ownership of code / data. • Can help reduce operational cost through need based commodity infrastructure and optimal provisioning. Cons: • Can be complex to architect. • Can be difficult to operate / monitor. • Most commonly used approach. Use of N identical instances of the application and / or database through cloning / replication. • Using a load balancer, each instance theoretically handles 1/Nth of the load. Pros: • Simple to understand and fast to implement. • Scales well from the transactions aspect. Cons: • Session information difficult to distribute or requires persistence to servers, causing availability or scalability issues. • More cost due to replication / cloning of data and applications. • Impediment to organisational scalability due to difficulties in segmenting teams based on ownership of code and data. Z Axis: Data Partitioning (Split similar things) Y Axis: Functional Decomposition (Split dissimilar things) Starting point. Typically a non- modular single monolith. Highly scalable system. Typically achieved through a combination of X, Y and Z scaling approaches. X Z Y L/B Request US Customers EU Customers APAC Customers Customers Order ServicePayment Service App Instance 1 App Instance N Application Search Service Search Service Search Service