Dear Dr. Cloud –


I’m struggling to think through all the different parts of our cloud computing environment. There seem to be so many pieces – and I feel like I just opened a box from IKEA, located the Allen wrench, and cannot fathom where to begin. Help, Please!


--Confused in Copenhagen


Interesting that you bring up IKEA, Confused. As a child, one of my favorite activities was to build models with Legoä building blocks, which, in retrospect, is like IKEA for children.  It was so satisfying to see my hours of meticulous work, building block upon tiny plastic block, slowly coalesce into the picture on the front of the box. That experience gave me an appreciation for how a very complex thing can be built in many small steps, out of small pieces, into something more than the sum of its parts.


So, what does this have to do with Cloud Computing, you ask? I’m glad you asked. It turns out that automating a complex Cloud-based service bears a lot of resemblance to my Legoä models. With the current focus in the cloud computing conversation on Infrastructure as a Service (IaaS), it is so tempting to overly rely on the simple strategy of using virtual templates, or images, as the end-all be-all of service provisioning.  This strategy focuses on deploying a few one-size-fits-all Operating System (OS) templates as a “service”, as opposed to building the Operating System from “scratch”, or through what is sometimes known as a script based approach.


The problem with this strategy is that it leaves little flexibility for adapting the service offerings over time. As the “base” image continues to be updated, older images must be maintained to support the older install base. It is also brings up the conundrum of what should be included in that base image. The more that is included, the more flavors of the image you need. The less that is included, the more work is put on the customer to build a useable environment from the delivered service. Once services get complex, this image-based approach quickly spirals out of control.


So what is the answer? For the more complex cloud environment that needs to accommodate complexity and heterogeneity, it must more useful to use a bricklayer’s model of service provisioning. Divide the delivered service into its constituent “bricks” – for example - a very simple base OS, “support” applications (Anti-Virus, Backup, Monitoring, Etc.), application platform, and code. Each of these layers can be dynamically provisioned on the fly, one on top of the other, based on service parameters or input from the end-user. With the right kind of access-control in the provisioning, those individual blocks can even be “owned” by different groups, but combined in the provisioning process. In this way, security hardening standards can be built and maintained by the security team, but deployed inline during service provisioning. This process can be somewhat slower (maybe 20 min) than an image deployment (maybe 5-10 minutes), but for complex requirements it delivers much more with significantly more flexibility and control.


So, as you consider how to build your own private, public, or hybrid cloud – consider how much easier it is to build that crazy thing on the box cover if you focus first on the little plastic blocks.


p.s. I hope to meet you at the Copenhagen VMworld this fall!

Dr. Cloud answers cloudy questions on Tuesdays. To reach the good doctor, email