LinkedIn | FaceBook | Twitter
This is one in a series of posts on when and where to use a distributed architecture design in your organization's computing needs. You can find the main post here: http://blogs.msdn.com/b/buckwoody/archive/2011/01/18/windows-azure-and-sql-azure-use-cases.aspx
“Elastic Scale” is a description of computing where the demands for the compute resources expands and contracts. Normally this involves increased user activity for the system, but the compute functions might also be driven by activity within the code itself. Let’s take a quick look at each.
In a centralized computing model (such as client/server), there is a finite set of resources for Compute and Storage, defined by the limits of the server architecture in place. The compute and storage resources are at a constant, assuming that they are at their maximum levels. In effect, you’re paying for and maintaining a a high level of computing whether you use it or not.
In a distributed computing model (such as “Cloud Computing” and Windows Azure) computing and storage resources can be added - and removed - dynamically. This means that as demand increases, you can add more resources to the pool based on a trigger of your choosing, and establish the ceiling for those resources if you want one. Conversely, as the load decreases, the resources also decrease. In this design, the use drives the capacity you pay for.
The key to implementing a distributed application is to keep it stateless. In a program, “state” is loosely defined as maintaining track of the previous operations within a program. Normally this record is kept in memory during the run of a particular program.
For instance - when you begin a bank transaction, the ATM machine takes your card, accepts your PIN, accepts the money you deposit and the withdrawals you make, and then returns your card, closing out the transaction. It maintains the “state” of your entire process, bookmarked on each end by taking your card and giving it back to you.
In stateless computing, the assumption is that the components within the process will come and go at various times. A good analogy here is e-mail. An e-mail system is made up of multiple parts:
When you compose an e-mail message, none of the other components are aware of your activities. When you send it, your client program is no longer aware of what is happening to the message. When the server receives it, your client software might even be powered off. The “state” is maintained by each component.
To adequately scale your workload, each component should be largely unaware of other components. That means you need to design your code such that it has more of the characteristics of an e-mail system. Keep in mind that even a bank ATM machine transaction can still be coded as a stateless application - I’m using it here as an example. In fact, very few things cannot be created in a stateless way.
You can “persist” state - that is, save it - to storage that each component can access. This is in fact the purpose of the Message Queue storage in Windows Azure. It allows one component to write a message and then leave. The next component can pick up that message and work on it. It’s similar to what you see in a restaurant. The waiter takes your order and drops it off in the kitchen, and the cook looks at each order to prepare it. In this analogy, the “message” is the meal order ticket.
Design Strategies for Scalable Active Server Applications - http://msdn.microsoft.com/en-us/library/ms972349.aspx
Physical Tiers and Deployment - http://msdn.microsoft.com/en-us/library/ee658120.aspx
Great, easy to understand points above.
Kishore Swaminathan, from Accenture would you believe, has some great generci points about elasticity. Sure there is scale but what if everything is elastic?
I like his notion of elastic processes - partnering with other organisations
and the ever just out of touch nirvana of decoupling busniess process from software development.
Elasticity can be argued in terms of waste. Whats the cost (actual, agility or business implication e.g. customer service) or waste if the system is not elastic? And as you elude to whats the cost of alternatives or indeed scaling down.