Clive Longbottom: Is it all stacking up?
Tue 22 Apr 2014
To celebrate the launch of thestack.com, veteran industry commentator Clive Longbottom asks what we mean by a stack and whether we should care what underpins it or just the level of service it provides?
When is a stack not a stack? Sorry – it’s not a joke, but a serious question.
It was easy in the past – the stack consisted of the hardware, operating system, possibly an application server and then the application. Nice and simple – everyone knew what was happening and could design against such simple ideas as to how much CPU of server, GB of storage and MB/s of network bandwidth were required to run a specific workload.
The ivory-tower arguments were over whether you had an Intel-based or a RISC-based server stack; whether you had direct or network attached storage or a dedicated storage area network, and whether it was Cisco or not as the network provider. For the majority, the reality was a heterogeneous mix: different workloads had different needs; different stacks met those different needs; different suppliers for each problem.
Then virtualisation came along. Suddenly, we had pools of resources. How much CPU was needed? Well, sort of “this much”. A standard had to be agreed of virtual cores – a standard that was defined differently by every vendor and was of no use whatsoever in trying to compare one virtual environment against another. Storage remained pretty easy; networking was more of an issue. The arguments became more about which primary suppliers should be used to provide servers, storage and network equipment for a platform that was moving far more towards a homogeneous environment.
Now add cloud computing to the mix: a platform where these pools of resources can be applied dynamically to a workload. No need to know how much CPU, storage or network bandwidth is needed, just make sure that there is enough resource in the pools to meet peak demand and the cloud will sort it all out – won’t it?
Then there are all the different flavours of cloud – firstly, private on-premise or co-location cloud, where you as the owner will still need to ensure that the physical resources are available to meet the peak aggregate needs of all of your workloads. Some cloud providers, such as Amazon, will provide a virtual private cloud – but this is really its public cloud (EC2) wrapped in a special way. Rackspace is building a private cloud practice – you get a dedicated cloud platform hosted and managed within a Rackspace OpenStack data centre, but this still needs careful sizing as the underlying hardware resources are dedicated to you.
So, what about public cloud? Is it infrastructure, platform or software as a service (I/P/SaaS)? If it is infrastructure, all you get is the hardware part of the stack; if platform, you get the operating system (and possibly a bit more) as well. If software, you get everything.
This move along the continuum of virtual and cloud computing is beginning to move the argument along the stack as well. Do you care if the software stack under your outsourced expense management system is Microsoft or Linux? Do you care if it is running on Dell or IBM hardware?
I could (and will in further pieces) argue that in some circumstances you should – suffice to say that as in the world of the purely physical platform, not all workloads are the same and different stacks can meet different needs. However, for general workloads, a scale-out platform using relatively standard building blocks across the whole stack will be good enough in many cases.
Look at SaaS providers like salesforce.com, NetSuite, Concur, Xero and others, including Microsoft with Office 365 and Adobe with its Creative Cloud, both of which are hybrid SaaS models with the software being delivered from the cloud to an end device. Do users really care what the stack is that underpins the offering? No – and that is how it should be.
At this point, the stack ceases to be of any real interest. It is the function that counts and whether the provider of that function can do so to an agreed service level. The ivory tower arguments disappear and IT can get on with what it is there for – supporting and facilitating the business.
However – and this is where the big “however” comes in – the capability to provide a function to an agreed service level is highly dependent on how well the stack is implemented, integrated and run. The provider needs to understand what makes a modern stack – and if you are looking at private on-premise or co-location cloud, then you are the provider.
So – back to the original question; when is a stack not a stack? The answer should be, when it is a business platform. IT will have won when this is truly the answer, rather than “it depends”.
