Happy new year everyone!  VMware’s Cloud-Native Apps team kicked off the new year by hosting a half-day meeting today with a group of industry leaders with the goal of defining a common, totally open application blueprint definition.  We had about 30 technologists representing many different companies: Amazon, Cisco/Noiro, Cloudsoft, CoreOS, Docker, Gigaspaces, Google, HashiCorp, Mesosphere, Microsoft, OpDemand/Deis, Pivotal, Telematica, and VMware.  It was great to see so much industry participation here!

Big group, small room…

So what exactly were we discussing?  Blueprints.  “Blueprint” is certainly an overloaded term and indeed we spent the better part of the first half of the meeting discussing exactly what we meant by it.  Thankfully we were all largely in agreement.  We want to focus on applications first and foremost and thus the blueprint definition needs to take an application perspective.  Modern applications are distributed and are comprised of many different components.  The blueprint specifies all the components of an app, how they’re stitched together, network and storage requirements, other service dependencies, and more.  It was widely agreed that the blueprints should support many app delivery formats: Docker, Linux container, VM, bare metal, and more.  This way we can provide customers the choice to deploy with whatever technology suits their applications best.  Further we all agreed that these blueprint definitions should be infrastructure agnostic.  This means that the same blueprint can be used to provision an app on a developer’s laptop, in a staging environment, in an on-premises virtualized datacenter, and in a public cloud.  The blueprint designer should be able to define the blueprint such that the requirements within it are properly mapped to whatever infrastructure is chosen.  In this way, blueprints can drive the application lifecycle from dev to CI/CD to production, enabling greater business velocity.  The group wanted to go even further, proposing that a single blueprint should be deployable by many different tools from different vendors.

It was very encouraging to see that there was general agreement on what we think a blueprint should look like.  The next challenge is  to do something about it.  Given the size of the group and the number of individuals and companies involved, many felt that getting something done might prove challenging,  so we decided to move quickly with specific deliverables both time- and scope-boxed.  The first deliverable is to define a set of use cases that we want this blueprint definition to solve.  Use cases are critical to keeping this effort grounded in reality so that what’s produced will be valuable to customers (after all, that’s what this is really about!).  So within the next week we’ll be putting together a use cases doc that is at most three pages and has two use cases clearly defined and agreed upon by the team.  Once we have that doc (which we’ll post here and would love your thoughts and feedback), we’ll get to work creating a prototype implementation.  The plan there is just to set up a github repo, roll up our sleeves, and get to work.  And yes, it’s all going to be open — open standard and open source.  This means we’ll be looking for your input every step of the way.

While there are still many details to figure out and many contentious points of design to work through, I’m very excited by the progress we’ve made in this first meeting and the fact that pretty much all of the participants see eye-to-eye on the basics of what we think a blueprint should be.  The goal here is to create a better experience for customers by getting all the players in the industry to agree on a standard.  I think we’ve taken an important first step towards that goal today.  Certainly a great way to start 2015!