Today’s cloud environments are all about applying policy. The only way to manage large and complex environments is to create a set of rules and instructions on how services should be delivered, which then become templates, or blueprints. Any other approach means its a lot of effort to make any changes to services or to grow or create new ones.
Vendors are providing even richer plugins and a lot are providing completely open APIs, which gives us more control over the entire datacenter. Many organizations take on the task of developing their own cloud solution by using customized scripts or usually workflow tools to call these APIs. Job done?!
Workflow tools (think vCenter Orchestrator or HP Operations Orchestration) are great at automation for general purposes, it’s really the new equivalent of running bash scripts and allow you create complex decision trees with an IDE which can hook into any API.
The problem with working with these kinds of tools is that they can do ANYTHING and that’s a little scary. As your workflow or script grows to encompass more integrations and decisions, it becomes increasingly more difficult to maintain. The work is usually doubled too, because you have to create the teardown flow as the opposite to your build flow. Combine these challenges with a growing CMDB and a growing number of services you provide, it becomes unmanageable very quickly. I wont even start with day 2 operations.
The result of automating cloud services without blueprints is actually closer to doing everything manually. More room for error, complex tear-downs, difficult to keep up to date (especially with new technologies and plugins). Everything in a workflow only solution is actually very static.
So this is where blueprints come in. Call them templates, blueprints, cloud formations, heat, whatever. They give you an elasticity which is essential for cloud.
So what is a blueprint?
Essentially a blueprint is a way of describing a set of resources and how they fit together. Just like a blueprint for building a skyscraper, it will describe what the building should look like and how each piece is connected. However, it doesn’t tell you how to cement each brick together, or how to screw a hinge onto a door. This is the same for a cloud blueprint, it tells you which services are required, in which order and how they fit together, but it doesn’t contain the code to deploy a virtual machine or the process for integrating with something like Puppet. This intelligence is done by the cloud platform or by an underlying workflow or script.
In my opinion, the power of blueprints is akin to the power of virtualization, software defined networks or software defined storage. A blueprint is an abstraction of automation just like SDN is an abstraction of a physical network.
To summarise, I like checklists…..A lot. So here is my personal checklist for a decent blueprinting solution:
- Simple to design – although doesn’t have to be a drag and drop visual interface, blueprints as code are very powerful too.
- Version controlled – If a blueprint doesn’t work, you need to be able to roll back.
- Agnostic – Needs to be able to hook into any technology/vendor.
- Extensible – Able to make use of your existing automation workflows, scripts etc.
- Life-cycle Aware – Understands the full life-cycle of a service, so it can teardown the contents of whole blueprint or expand/shrink as required.
- Multiples – Needs to allow for multiple “things” eg, a multi virtual machine service with interdependencies.
- Elasticity – Enables T-shirt sizing, or custom sizing, or a custom number of machines, etc.