Grounded in the Cloud
Showing results for 
Search instead for 
Did you mean: 

Elasticity and Cloud in the Enterprise


Earlier in the week we discussed the hidden costs for Enterprises looking to adopt cloud computing. Today we’re going to discuss another hyped assumption – the need for elasticity.


One of the benefits of cloud computing is this notion of being able to scale dramatically should the need arise. Then have the ability to switch off servers when you no longer need them. Of course this notion is correct…


…if you’re Facebook or Twitter or a Stock Trading Broker dealing with IPO’s.

But what about if you’re a bank? Or a Legal Firm? Or a retailer?


There are two issues to consider here:

  1. Core vs. context workloads
  2. Scale at the workload vs. macro level

1. Core vs. Context Workloads


When you consider a standard enterprise architecture, broadly speaking you can categorise the IT systems into two areas:


  • Core systems – the systems that run your core business. This could be the systems that run the factory for a manufacturer, the logistics for a shipping company or the mainframe that runs the ATM’s for a bank. If these systems go down, the company is no longer in business.
  • Context systems – the systems that allow the various departments to perform business processes. These include human resources, messaging, payroll and Customer Relationship Management. If these systems go down, you can still hire people, call each other by phone and instruct the bank to run last month’s pay run as an emergency. They may be critical systems, but they’re not core.

Now consider which workloads are going into the cloud first. Yep it’s the context systems. With that consideration in mind, how much has your enterprise grown in the last year? Has it grown10 percent or even 30 percent?


Most organisations are growing in the 4 percent – 12 percent range depending on the industry. So when thinking about scaling your messaging system, short of acquiring another company, it’s unlikely you’ll need the 2000 percent growth rate of the public cloud providers.


But elasticity isn’t only about growth—it’s also about only paying for what you use. It is about de-provisioning systems that you no longer need.


When was the last time your company shrank? Even through the worst Work Force Reduction cycle, most companies will shrink somewhere in the sub-10 percent range.


Enterprises are not the same as start-ups, and they don’t face the same elasticity demands that these companies do.

When you consider core and context systems, even start-ups may scale core systems, whereas their context systems will scale rather more sedately and predictably.


2. Workload vs Macro


You must be thinking, “Surely though Roger, there are some organisations that do require significant elasticity. What about a university that has 35,000 students during semester, and only a handful of administrative staff during the vacation?”

You’d be absolutely right. In fact of all enterprises, universities do have a rather seasonal business.


Here is where we need to consider whether we really need elasticity across the entire data centre, or for some specific workloads.


Even within other businesses you may have a peaky workload. For example an accounting firm may have a bookkeeping system that needs to scale at quarter and year end. Another example is of a retailer’s marketing department that may run a campaign that takes off for 6 weeks over the summer then scales back afterward.


But when considered in light of the messaging, human resources, payroll and host of other systems, I’ve found it rare that an enterprise organisation needs massive elasticity across their entire cloud deployment.


Imagine you’re running 1000 machines, and only 5 host the marketing website. During the campaign you could scale 10x to 50 servers, and still only affect your overall compute environment by 4.5 percent.




Automated, infinite elasticity is one of the more compelling promises of the cloud. But the truth is that you do pay more for available, unused systems, than you do for reserved allocated systems. This makes sense as the provider has to carry the capital risk for the machines.


With this in mind, determine the actual growth and shrinkage trends for your business and supporting IT workloads over the past 10, 5, and 1 years. Then consider the potential for specific systems to need to scale up and down on-demand, and determine these as a ratio of your entire IT architecture.


You may find you’ll be pleasantly surprised, that reserving services makes the utmost sense.

There is no difference between theory and practice, in theory....
0 Kudos
About the Author


Roger has been trying to get out of Information Technology since programming COBOL on mainframes in the late '80's. But no matter in which continent he awoke, or whom employed him, his passion to enable people with technology was constant. So now he enables businesses to determine their strategy using the latest technologies like cloud computing, mobility, and big data. HP calls these Strategic Enterprise Services, Roger calls them "another day in the office."

Jan 30-31, 2018
Expert Days - 2018
Visit this forum and get the schedules for online HPE Expert Days where you can talk to HPE product experts, R&D and support team members and get answ...
Read more
See posts for dates
HPE Webinars - 2018
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all