Not all blueprints are equal

Application blueprinting is a simple enough concept: capture your application model as code and deploy that model to clouds or platforms of your choice. Infrastructure as code gives you the opportunity to leverage all the best practices of traditional software development against the entire application environment, no matter where it lives.

At Cloudsoft, we believe that blueprinting should go well beyond modeling and deployment, and encompass the full lifecycle of the application. We provide the tools to make operations-as-code a powerful reality. Blueprints for Cloudsoft AMP (and for Apache Brooklyn) allow you to detail the in-life management of your application via easy to write and easy to manage policies. Simple policies like autoscalers and service replacers, or more complex policies that assist with, for example data sovereignty or follow-the-sun operations.

This is something I’ve written about extensively, for example, in Managing the New Complexity with Policy-based Management. I wrote this piece for The New Stack in February 2016 and a year on at InterConnect 2017 last week, it was clear that we need policy-based application management more than ever.

At Cloudsoft we think about in-life management a lot - it is in our DNA - and we recently did an exercise comparing and contrasting creating blueprints with Terraform, Apache Brooklyn, and Cloudsoft AMP. Given we originally contributed Brooklyn to the Apache Software Foundation and we have built AMP on top of it, we had to ensure that this exercise was scrupulously fair. Therefore we wrote up our experience on Github in a vanilla organization Montlake and we encourage anyone interested in this space to take a look at the blueprints we created and open sourced there.

A word on Montlake - we are a big fan of bridges and the Montlake Bridge in Seattle is a beautiful example of a double-leaf bascule bridge that carries traffic to this day, spanning the Montlake Cut and connecting the University District with Montlake and the city itself. We chose this as it symbolises somewhere where we can explore ideas and illustrate how you can “bridge the gap” between today’s world where management and automation is all too often focused on infrastructure provisioning and a future state where it will be all about autonomic application management.

From bridges back to blueprints - what did we learn?


There is a very wide range of good deployment and cloud orchestration/automation tools and methodologies in use today. Different opinions and approaches, and a great deal of sophisticated and beautiful design. When it comes to deploy, while we’re partial to our cloud-agnostic approach, it is easy to recognize that an organization in may prefer one tool or language over the other for specific work, and each tool has its sweet spot. That’s why we feel strongly it’s essential to be able to consume and incorporate other tools within a blueprint.  From Terraform and TOSCA on the blueprinting side, to Chef, Salt, Ansible, Puppet, Docker images, etc. on the image/OS prep side, Cloudsoft AMP lets you pull in the right tool for any application modelling job.


Portability across clouds is difficult… and valuable. Writing a single blueprint that avoids becoming entrapped by enticing features (or odd quirks) of a given cloud vendor, without maintaining separate versions for each cloud, is not easy, and often not possible, with some tools and approaches. Every enterprise that has learned from the Microsoft and Oracle lock-in strategies will be running in multiple clouds, and consumers increasingly want choice. Cloudsoft AMP and Apache Brooklyn have an advantage here as portability has been a central pillar since day one. An AMP blueprint focuses on the intentions and requirements of applications, not specific infrastructure choices (unless that this desired), and so is deployable to all major public cloud providers, from Amazon and Azure to Google and IBM; established platforms such as VMware and OpenStack; as well as modern platforms like Docker Swarm, Kubernetes, and OpenShift.

Third (Most important in our view)

Most tools don’t offer sufficient in-life automation capabilities, and if they do, those capabilities are not portable across clouds. Fundamental application management capabilities, like service (or server) replacement and auto-scaling are frequently left to the mechanisms provided by the cloud or platform being targeted. That’s usually sufficient as a starting point but falls short when applications grow, and relying on cloud-supplied management ties you further to that cloud. For Cloudsoft AMP and Apache Brooklyn, policy-based application management is a first-class citizen, completely portable and configurable, and sophisticated enough to meet the demands of any application.

In short, not all blueprints are equal.

We will be contributing more examples to illustrate these points in the coming weeks and months, starting with enhancements to our Apache Spark blueprint. We’d be delighted if other people did the same. Join the conversation, and contribute examples at