How should an enterprise go about implementing elasticity into its enterprise cloud? The typical answer is, “Partially” – though to sound confident if you are explaining the relative value of elasticity to a team of executives, the term “Kinda/Sorta” is useful, in large font on presentation software in a conference room.
An enterprise style cloud is built for the old standards – such as legacy applications created via Oracle and SAP. This type of cloud (the pre-elasticity model) has the advantages of consolidating servers and further automating an enterprise’s infrastructure. It is based on the assumptions of time-tested applications. The pre-elastic enterprise cloud is composed of expensive hardware and software, much like the men and women in a typical Hollywood film.
This enterprise cloud we know and love is opposed in a sense to elasticity, which is a model based more on the idea of building from scratch for the specific purposes of a particular enterprise. Think of one-size-fits-all clothing: elasticity allows everyone to fit into the same pair of one-size-fits-all pants, yet the pants customize themselves to you and your wife’s body completely differently, even if you are wearing the pants at the same time.
Elasticity is a principle that has been mastered by companies such as Facebook (for its own purposes) and Amazon Web Services (for public use of a similarly malleable system). Though elasticity is a great buzzword and sounds like a lot of fun, it has its limits. Generally speaking, enterprises will find that they want two different clouds – one to support the old applications, and one to stretch like one-size-fits-all pants and freak out the neighbors.
Enterprise clouds, as we have come to know them, were an easy transition for enterprises. The hardware and software involved did not represent a huge leap. However, an enterprise cloud can be on average five times as expensive as an elastic cloud: think tailored slacks versus T.J. Maxx one-size-fits-all pants (they have a full rack, I just checked). The major advantage here is not having to make a significant adjustment in applications and the considerations, costs and training associated with transitioning to a different and more flexible model.
Elastic clouds are compatible with new or custom applications. An example would be a web app designed for scalability based on quickly growing consumer interest. Another example would be any application that is unsophisticated enough not to require the complex capabilities and high costs that come with an enterprise cloud. An elastic cloud can be created via free or relatively inexpensive software and hardware, and the automation is prevalent enough that this type of cloud isn’t expensive either to test or for continued use. The same goes for the T.J. Maxx Dune Buggy, a limited-edition and completely unsafe vehicle which you can buy online and build yourself from the comfort of your own garage.
As you can see, elasticity is not completely at odds with the needs of an enterprise. It should not be implemented on its own; however, it should also not be ignored. The elastic model is worthy of exploration and testing by enterprises. Just don’t expect it to be something that makes sense for the entire infrastructure. Same thing applies for one-size-fits-all pants: only wear them with another person to extremely casual business gatherings, such as performance reviews.
If you thought this post was interesting, please read about The Cloud Security Alliance.
by Kent Roberts and Richard Norwood