Private clouds are difficult to build. In this blog series I’ve surveyed all the common flaws in private cloud design and implementation so you don’t have to chase them yourself. Hopefully you can relate to some of the issues and contribute your thoughts in the comments. In the final blog in the series I’m going to attempt point a direction forward, to fix the private cloud, and share my reading list.
Today’s blog is about the organisational flaws exposed by the private cloud trend.
IT built the private cloud IT wanted to build and not the cloud anyone wanted to use.
Private clouds were commonly seen as an extension of virtualisation. This encouraged IT to have an inside-out cloud mindset. Now virtualisation and cloud typically go hand-in-hand, but they are not the same thing. Even though the IT infrastructure deployed in both instances is usually quite similar, from a user perspective they are completely different. Clouds are quick and self-serviced whereas virtualisation by itself is not. The truth is you can have a cloud without virtualisation. For example, if you build self-service etc. on top of an Oracle RAC Cluster you could have DBaaS. (Be careful to not get screwed too much on the licensing costs.)
The virtualisation trend also exposed some organisational issues, which may or may not have been dealt with. It’s part of the phenomenon of Software eating Infrastructure. Virtualisation allowed cloud engineers to make network changes to “soft” switches and firewalls. It allowed them to deploy storage. Storage I/O problems occurred because of poor workload balancing and live migrations. The opportunity to improve IT efficiency by delegating storage, compute and network activities to a semi-orchestrated cloud team existed. In some organisations this change worked, in others it was resisted.
The arrival of private cloud progressed these organisational issues further with many organisations merging specialists into a cloud team and hoping they would abandon their specialist mindset.
I’ve drawn up a very generic cloud stack below:
You should have put most resources into the top block but these skill-sets (establishing services, APIs and managing a relationship directly with cloud users) are not something specialist IT staff are traditionally good at, or have ever had to do. IT shops started reinventing themselves to make this shift.
The bottom two blocks play to IT’s traditional strengths. Depending on how (in)efficient you were you may have spent most of your time and energy stuck in the bottom block, building networks, hypervisors and customised operating systems. If you were still heavily silo-ed there was no way you could match someone like Amazon’s scale and efficiency. Even if you were uber-efficient you probably can’t match AWS. The thing is, if you’ve spent most of your energies in the bottom blocks, and not in the top block, you probably don’t have many users. You spent a lot of time building the “undifferentiated heavy lifting”, as Adrian Cockcroft said back in the day, because it’s what IT knew how to do.
In the next blog post I’ll discuss the business case for private cloud and some use-cases.