Monday, 13 June 2011
Are infrastructure people doing cloud the wrong way?
So here we are – banging on about the cloud story, flexible infrastructure, infrastructure as a service, platform as a service etc…
Most things I see / here about / vendor presentations are really focused towards how do we make the infrastructure layer more flexible… but are we not just continuing to dig ourselves a hole and perpetuating a legacy way of working?
We are busily trying to re-produce the legacy environments we have today, utilising traditional written application layers that have a reliance on infrastructure layer. Hell even the vendors are doing it – you only need to look at the approach that Oracle are taking with Exadata / Exalogic, VCE with vBlock, FlexPod etc etc……
Surely there is a better way – sat here doing some thinking over the weekend and came to the conclusion that we more and more need to turn this cloud stuff on its head! (from an infrastructure perspective)
Why are we not provisioning a core infrastructure that is essentially very dumb, and rather than trying to offer infrastructure services that provide resilience, high availability, scalability, disaster recovery, encryption, capacity planning (the list goes on), let’s start putting requirements in to the App Dev community around how they have to code to / principles that they should work with? They are a smart bunch – and given the challenge and the promise of more agile delivery would probably jump at the chance to embrace this challenge.
They type of development principles / rules that I had in my mind were:
· The application will scale out and spin up engines as it needs to become more performance or requires more bandwidth
· The application will be coded in such a way that resilience is provided at the app layer, and has the capability. If stateful data movement is required – a publisher / subscriber (Pub/Sub) bus must be used
· App owners and development folk know / understand their data better than any infrastructure dude can – if they need encryption – put it in at the application layer
· The application will be coded in such a way that DR is provided at the app layer (Using approaches such a dual commit / write many places etc.)
· From this point forwards let’s use a converged framework for development (tools / libraries etc).
· As the application sees BUSINESS TRANSACTIONS go out of tolerance provision some more app instances / put application logic in to deal with this scenario (no doubt some of you grid types are saying we have been doing this for ages ;-)
Admittedly some smart stuff needs to happen at the middle layer to take care of spread and movement of data, ensuring transaction data is published to / subscribed in the appropriate way, but the interfaces between app and infrastructure should be unhooked and we should be taking more advantage of pub / sub message busses to interconnect
Once you start doing this, and all the stuff that infrastructure people worry about starts falling away and the App Dev community don’t have the dependency on infrastructure – the opportunity to be more agile starts becoming reality. Let’s also face it – application development are far closer to the business than infrastructure are
Let’s start ripping out the complexity of tin / infrastructure layer and start moving up the stack and do the clever stuff (just as an aside – one of the things I am struggling with (for the enterprise) is how you ensure that items such as data are catered for in major DR events (i.e. holding state somewhere else) – I still think the concept of Prod / DR may exist for a while – so this needs to be catered for in any model you propose.
At the moment you have the likes of the infrastructure people trying to solve a problem that simply can’t fix it (we can for the legacy way of working – but not the brave new world!)
OK – so maybe this does not solve the legacy problems – but if we start tackling this way of working for NEW application development, and continue with some of the current practices for legacy applications – its got to start improving things
If we carry on doing the things in the same old way, the various infrastructure vendors will continue to empty out pockets of cash, and more importantly we continue to deploy things in the same old legacy way. We should really re-focus that cash on a better way of doing things.
I am probably preaching to the converted – but it makes sense to me!
And now, finally – for a diagram!