| Ph. D. Julio Fernandez Vilas | |
| ¿Any comments? [email protected] | |
After years of talking about scalability (I remember discussing this back in the 90), in less than five years in the IT world we've been talking about scalability (scale-up and scale-out) to speak of elasticity.
And we not only care of growing, we are also concerned about decreasing, because it is what most negative impact has on the costs when the business scenario has changed.
If my company cannot grow, the IT managers will take the risk of not servicing the business, that is, the company will not be able to sell more. Yes, that is a problem, but it is not the worst situation you can deal with. Let’s suppose now that your company has entered a “low-sales” scenario (due to external factors, like crisis or cycle changes); if you cannot scale down IT costs to the new company size (due to an un-accompanying business sales), you could put the company in a risky financial situation, due to the high IT costs.
What do I need to provide optimal IT systems according to business needs? Well, as mentioned, we have to focus on the elasticity, not scalability. While scalability issues focus on solving problems such as provisioning or continuous production, elasticity theories adds scalability the ability to adjust systems to real production demands (whether they mean increasing or decreasing production).
Moreover, elasticity means also a change in the time horizon in respect to scalability. The concept of elasticity when it comes to cloud technologies is referred to minutes or seconds, unlike traditional scalability, which focuses more on the problems of supply-chain, so its time horizon is days or weeks.
Having identified the problem, we can only find the solution. How do I get resilient systems and how do I reconfigure my ability to “run the business” in minutes?
The solution is not new, is the orchestration. We refer to orchestration as a set of elementary tasks that follow a predefined script. So far nothing new, because what matters here is to have previously "written" that set of tasks, writing in the script all the steps to make a provision or un-provision of the service (whether infrastructure, application, database data, etc.).
The orchestration, scripting in fact, is what should allow instant running of procurement processes, which is obviously predefined. The advantages of orchestrating are clear, you can make your responsiveness to business PERFECTLY conform to the needs of business, both to grow and to decrease, and also this is done instantly and automatically.
As discussed in other business cases that we will include in this blog, to have farms that grow and decrease automatically with the production company, is key to reducing costs (whenever we are running under a “pay per use” operating model).
Consider that what you get with this way of working (standardizing and orchestrating) is to change the location of the provisioning problem, it will be moved to the supplier side, which impacts prices the providers set. That is, the service provider must provide elastic peak demand, which is something that the consumer of services is being waged in the cloud. For the business to remain profitable to providers there is only one explanation: economies of scale.
BOTTOM LINE
The enabler/enhancer of elasticity is the orchestration, this is to automate all processes provisioning, deployment, activation and deactivation. Elasticity is in turn the basis for reducing costs and accelerating time to market.
