posted

0 Comments

We recently launched our next major release of vRealize automation 7.0, I’d like to cover one of its most important capabilities – the converged blueprint model and the new design canvas.

Since our last release, we’ve been thinking about how best to serve our customer’s key automation use cases. We learnt that increasingly, the traditional infrastructure and the application infrastructure (comprised of middleware) use cases were all converging.

Sure, there are people that have expertise in individual components – for example, an OS administrator provides a hardened OS image and configuration and a database administrator provides various database configurations. However, in a cloud model, these people would like to provide services that are re-usable. Each service can be a building block for another composite service. We also learnt that the ability to integrate with existing or shared services (e.g. shared load balancer, SaaS services) in a seamless way is very essential. And finally, a developer need not assemble each of these services from scratch. Rather, they can simply order a pre-assembled stack and deploy their application components.

All of this led us to fundamentally re-think how we enable automation for our customers. We settled on a few tenets:
  1. Single, converged (or unified) model for automation versus specialized models for infrastructure, middleware, applications and anything-as-a-service
  2. Compose a service using other services as re-usable building blocks
  3. Express blueprints declaratively (in YAML) while also having the ability to write actions in code (i.e. scripts)
  4. Provide graphical canvas as alternate mechanism for power users
Let’s talk about some of the use cases we now solve:
  1. Start simple. Create single-machine OS blueprints (Windows or Linux)
    • Add network profiles to create dynamic networks (through NSX) or use existing networks
    • Add NSX security mechanisms through security tags or groups
  2. Create XaaS blueprints to connect with shared services (e.g. load balancers), or to call workflows (e.g. check with a licensing server) or connect to SaaS services
  3. Create middleware software components to single-machine OS blueprints
    • Add database and/or application server on top of OS blueprints
    • Add specific security mechanisms (e.g. control traffic flow or open specific ports)
    • Add XaaS blueprints to call workflows
  4. Publish application patterns
    • Compose application patterns that can be used by your developers or deployed in mature stages of your release pipeline
    • Create multi-tier, multi-node blueprints
    • Create dependancies between components. This is used to determine order of various operations by vRealize Automation (e.g. Db server starts before app server).
    • Indicate property bindings between components (e.g. App server’s db_port value is bound at run-time with Database server’s db_port value)
    • Indicate number of instances for each tier that you want to be deployed
    • And finally, do not forget to include any callouts to XaaS blueprints. These callouts could be pre or post install callouts for any OS node.

All of these blueprints can be built using our new design canvas (see demos below). But we do not stop there. All of these blueprints can be exported to a readable YAML format. We call them Blueprint-as-Code. You can save them into a source control repository, share them, edit them and finally import them back into vRealize Automation. This puts the unified blueprint model straight into the hands of the developer or the DevOps engineer.

Nothing is better than to show demo of the above use cases. Please check out following videos:

  1. Expert Panel (with Demo)
  2. Intro to Converged Blueprints in vRA 7
  3. Building a multi-tier application using vRA 7’s Converged Blueprint Designer