IaaS is not for software architects. Elasticity is
I've been saying it for a couple of months. Albeit a solitary wee voice, somewhat trying for a response : Simply moving servers to the cloud ignores architecture. I'm revising that statement today to Infrastructure as a Service (IaaS) is not for software architects. Its provocative but I'm interested if people believe I’m wrong…
By contrast a platform as a service (PaaS) is for software architects and beyond. It should provide three core tenets: better services at lower cost, better flexibility than on premise and of course scale. IaaS claims to do the same. So, what's different?
The ability to scale up and scale down without significant impact to flexibility or costs is important in this discussion. I refer to Buck Woody’s latest post which generalises elastic scale thus “In a distributed computing model (such as “Cloud Computing” and Windows Azure) computing and storage resources can be added - and removed – dynamically”. So lets look a little deeper at the impact in elasticity in IaaS and PaaS.
I’m claiming simply moving servers to the cloud ignores architecture, and its because of elasticity which enables scale. If a company simply moves to the cloud by moving servers around, the shortcomings between supply and demand are exposed. Moreover I think it is guaranteed that resources will be wasted on premise and people have come to accept it. Its often here the developer relies and is instructed by the physical constraints of the organizational standards and resources. As a side point how many Data Centers run by in large under utilised (e.g. time of day) or over utilised for the same reasons? On the other hand PaaS encourages resources and demand to be in lock step.
To illustrate I have drawn two diagrams. On the left I use Buck’s drawing to illustrate the minimisation of waste is ideal (PaaS). In this diagram resources are always just more capable than demand.
On the right I look at typical on premise Infrastructure to support a software solution. There is often an inherent amount of waste and a ceiling on capability. This would be the same on the whole if it was moved to the cloud using IaaS.
To describe the IaaS waste in more detail, let’s imagine the solution has:
1) An architecture has a minimum infrastructure requirement ( e..g number of servers)
This the operating base line. The solution requires these platform servers to things like AD/ Domain controllers/ Firewalls etc
2) A multi-tiered architecture
There is a likely to be some pool of servers. The pool starts with a large over capacity but as demand grows the pool is incremented in steps
3) A dependency chain
The dependency chain is the physical linking to logical assets (e.g. access to a pool of resources accessed by the application servers). This chain has a physical limit (connections/ memory/ disk space/ threads)
4) Some physical threshold
This is a ceiling due to some physical infrastructure constraints. This could be floor space, heating/cooling, power or even running costs/budget.
My point is this; When you are on premise you have implicit minimum server pre-requisites in addition to procedures for dealing with new demand that are rarely automated or quick. If you move this type of solution to the cloud in an IaaS way then you may well achieve the same on premise results albeit with some cloud benefits (notably cost).
When you start to look at the architecture which determines what the application does where and with whom, servers should be the last place you start. The application, its architecture and its respective suitability for the cloud, I would assert, is a better place to start.