Scaling out your tier based application in three steps - Now online
Posted 17 March 2008 @ 3:29 am by Nati ShalomA while back I wrote Architecture You Always Wondered About: Lessons Learned at Qcon, where i summarized some of the lessons learned from the Amazon, eBay, Yahoo and LinkedIn architectures, which enabled them to address their scalability requirements.
During that conference I spoke about the limitations of existing tier-based implementations and presented a pattern (Space-Based Architecture) that outlines how one can apply some of these lessons to scale out existing applications in a relatively seamless manner by pushing the complexity to the underlying middleware stack.
The presentation is now available online at InfoQ:
Three steps for turning a tier-based/Spring-application into dynamically scalable services
The theory and principles behind this pattern are based on Lean methodology, which I discussed in Moving to Extreme Transaction Processing using Lean methodology.
- Implement a common cluster for the entire system, including messaging and data. A common cluster eliminates the need for redundancy when we introduce fail-over. It also removes the need for a transaction coordinator, as we are no longer dealing with coordination of two separate sub-systems (we also eliminate the need for idempotency).
- Remove disk I/O from the critical path of the transaction. The state of the messaging middleware and in-flight transactions will be stored purely in-memory. The system will replication to keep a copy of the data in an alternate memory instance for hot fail-over. Synchronization with the back-end database will be a background process using reliable asynchronous replication. This way we guarantee the consistency and availability of the system purely in-memory, without depending on disk storage. This approach has a nice cost-benefit to it as well, as it reduces the need for expensive disks as part of the infrastructure.
- Collocate the business logic with the data. This reduces the network hops as well as the number of moving parts in the system.
- Partition. We split (or "shard") the transactions into self-sufficient units of work.
I hope you'll find it interesting.
