But, what do we really mean when we talk about elastic technology?
One of the great benefits of many of the cloud solutions is that they offer capacity on demand or, in other words, supply to meet demand. Essentially, you never get more than you need but always get as much as you need. This differs from local systems in that we build new capacity in-house based on predicted future requirements. Of course, we don't always get the future demand right, so sometimes you need to upgrade or expand sooner than predicted, but more often you have a lot of spare capacity that is not used before the machine is retired of old age.
Whether you are upgrading early or finishing up at end of life with spare capacity, you will always be paying for more capacity than you require on any given day.
Let me just define capacity loosely for the sake of making sense here. I am discussing capacity of infrastructure required to run applications. Essentially, this is the capacity of server hardware such as:
- Data storage (eg. hard drives)
- Memory (eg. RAM or cache)
- Access to processor power
- Network bandwidth
- Power
- Cooling
- Backup and redundancy capabilities
In the server room, many businesses moved to virtualisation to reduce this problem so all the systems share the spare capacity locally and overall there is less spare capacity required. This is a great intermediary step to the next step of using larger shared systems.
So, why do we talk about the cloud systems as being elastic? Well, because you can ramp up your demand as you need it, but you can also scale it back down again. For example, if you were to build a platform to sell tickets to a single concert being held at the MCG, you would expect that in the first hour of online sales after the show was promoted and ticket sales were opened you would need a lot of computer power. Later the same day, you would need considerably less and so on until the show was on – at which point you wouldn't need any computing power for ticket sales.
Of course, this is an extreme example and there are many more subtle ones in day-to-day business. But, stay with it for now... If an application like this is hosted on a local purpose built server we can expect it to overload initially, providing the keenest of ticket buyers with a bad experience. If, however, the solution is built on the Oracle Exalogic platform or the Amazon EC2 platform, for example, the initial hit would simply cause the system to scale up and supply more capacity. (For the geeks, let me just acknowledge that this assumes the application has been written to make use of the underlying scalable nature of the infrastructure).
To a small business with just a few servers, the important part of elastic solutions is that you only need to pay for what you use and you only use what you need. Be warned though, it is very important to determine what your needs will be prior, as hosted elastic servers can be very expensive if the utilisation is not well managed. In some models, I have seen it cost four to five times as much as building your own server on premise.
So, really, the question for you to ask of the people trying to sell you elastic solutions that sound really impressive is, "So, tell me what would I need to buy to run that here in my office, what would it cost me to run it in a data centre and what will it cost me to run it in the cloud?" Of course, if you anticipate huge spikes in demand and would need to invest many thousands of dollars to cover the peak few hours of use each year, the sums may stack up.
As with all big dollar technology decisions in business, if you are not sure you are making the right decision, get another opinion; preferably from someone you know who can provide a sensible comparison based on extensive industry knowledge.
David Markus is the founder of Combo - the IT services company that ensures IT is never an impediment to growth.
No comments:
Post a Comment