One of the big changes you’ll see in vRA 7 is the new blueprint designer. If you can’t wait until the GA release, here is a vRA 7 bleuprint designer preview.
In summary these are the differences from the old pre-7 blueprints:
- Graphical canvas
- Unified blueprint. No difference between single machine, multi-machine or application blueprints
- NSX integration. You can now drag and drop NSX object into your blueprint canvas
- Ability to use blueprints in blueprints Yes, nested blueprints!
- Ability to set dependencies between elements in the blueprint
- Ability to use vRO workflow in a blueprint. This is now called XaaS, formerly ASD
- Last but not least: The designer is on a separate tab in the vRA GUI not hidden in the infrastructure tab.
So basically all the good elements of application director (or appD or application services) are now integrated into the vRA blueprint designer. On top of that we can now use workflows directly in a blueprint. Which is exciting to me really.
This is what the designer looks like when you just created a new blueprint:
And this is what it looks like when you would create a typical two tier application:
Please note that these screenshots are taken from a BETA version so the GA release might look a little bit different.
As you can tell from the screenshots all features are now nicely integrated. You no longer need to hack NS integration into the product or use vRO to actually integrate app services and vRA.
I don’t want to complain because this is a huge step forward but…. The thing I’m still missing though is a higher abstraction layer on top of the blueprints. The bueprint author still has to decide one which reservation policy the VM will land for example. If you have different environments you’ll end up with blueprint sprawl. A better approach would be a form that asks functional questions like: is it for dev or prod? and then populates the different properties in the blueprint. I used to build that kind of functionality in workflows and then publish those in the catalog instead of the actual blueprints. Hopefully VMware will build something into the product to facilitate this.
I’m currently at VMworld Barcelona where this morning VMware announced the new version of vRA. It’s going to be called vRA7. As far as I know it’s still not GA (general availability) but the Beta program is in full swing.
This morning I attended a a vExpert deepdive session hosted by @virtualJad. Here is an overview of some of the new features:
- Simplified architecture You no longer need 24 machines for an enterprise deployment.
- Simplified installation: From download to up and running in 20 minutes. All wizard driven so anybody can run a vRA PoC without assistance from PSO or other consultants.
- One converged blueprint. No difference between IaaS and ASD (which is now called XaaS by the way) and application blueprint
- Blueprint designer is now a beautiful canvas which allows for visio style drag and drop design.
- Nested blueprints: You can use other blueprints in your blueprint (nice!)
- Eventbroker: instead of having a few workflow stub we can now create policies that define when to kickoff a workflow. There are 60 different lifecycle events to which you can attach workflows. And each event has multiple stages (pre, event, after).
This event broker makes the product so much more extensible than what it currently is. The possibilities are almost endless. The other nice thing about this is that it is policy driven and defined by the vRA admin. So extensibility is now no longer part of the workflows. This means you can give the workflow designer to an application architect while still making sure that important IPAM or CMDB workflow is kicked off with each deployment. The application architect can consume XaaS workflows to extend his own blueprint.
In summary: really cool stuff, you’ll be reading lots more about it here in the coming months. I know, I know, I haven’t blogged in a while but I promise you’ll see some good vRA 7 stuff here on this blog!
VMware released version 6.2 of a lot of the vRealize familiy products, vRA is one of them. I’m not going to cover all new features here, you can find them in the release notes. One feature I really like is this one:
- Ability to edit custom properties for published applications in the service catalog.
This feature means we can now have user input for IaaS Custom properties on Application blueprint catalog items. I used to create some fairly complicated ASD workflows to work around this so this new feature makes life a lot easier for those customers using Application Services.
A couple other features worth mentioning or those:
- Schedule date and time for the reconfigure operation.
- Supports configurable email templates.
VMware also released a new product: vRealize Code Stream. This is VMwares take on a Continuous delivery tool. Its is connecting existing tools an repositories and provides the use the ability to create pipelines containing tasks. Interaction with external systems is handled by vRO (former vCO).
Last week I attended VMworld Europe in Barcelona. I had a great time, eating tapas, drinking Rioja and learning something new in between. I already wrote about elasticity achieved using project fargo and docker on my company blog. Since this blog is more automation focussed I wanted to highlight some automation news. OR actually it is more about the future of Orchestrator.
The first thing that stood out to me was the lack of vCenter Orchestrator uuhh vRealize Orchestrator break-out sessions. I think there were two or three session explicitly about Orchestrator. A couple others went a little bit into orchestrator but were focused on vRealize Automation (vCAC). Last year there were quite a couple of sessions about Orchestrator. Telling us it was the best kept secret or the best VMware product never released and we should really go and use this awesome tool. And of course they were right to say so. And seeing where VMware is going with Orchestrator I was really surprised they didn’t give it more attention during Vmworld.
Which brings me to my second point. It is clear by now that Orchestrator will be used as the back-end for vRealize Automation. We can already see this in the current versions: The integration with NSX is completely implemented using Orchestrator. vCAC ugh… vRA has no interaction with NSX whatsoever, everything is handled via Orchestrator.
The same goes for what VMware calls Anything as a Service. Which is delivered using the Advanced Services Designer. Yeah that’s a lot of buzzwords in one sentence. In reality it is just a forms designer which you can use to design user front-ends for Orchestrator workflows. The objects created by the workflow can then be managed by vRealize Automation.
I already see that the adoption of Orchestrator is mainly driven by the use of vCAC. But there is more to come. VMware told in one of the Orchestrator sessions that Orchestrator will be used as a DEM replacement for vRealize Automation (but any information given in such presentation may change at any time). For who isn’t familiar with vCAC/vRA; The DEM is the Distributed Execution Manager. It is basically the component which does the actual work in a vCAC deployment. Currently it is 100% .net code and runs MS .NET workflow foundation workflows. So it makes total sense to replace that workflow engine with VMwares own workflow engine. The result will be that some day we can get rid of the windows components in vCAC and end up with just a virtual appliance which is easy to deploy and configure. That day will be a good day.
To be able to use orchestrator on the scale that vRA requires there will be some changes to the product in the future. For example, better permission management, multi geographical deployment models, integration with DevOps solutions and a lot more.
So although Orchestrator didn’t get a lot of attention during VMworld it seems it is going to play a crucial role in VMware’s automation strategy. Nice 🙂