Since the announcement of VMware vRealize 8, migration has been a popular topic. I don’t mean deployment of vRA8 itself; that is handled [editor: very nicely I might add] by the new version of VMware Lifecycle Manager. Follow the wizard and sooner rather than later you will have a newly deployed vRA8 appliance. When I say migration, I mean migration of your blueprints and configuration from vRA7 into vRA8. But what will work? What won’t?
Migration Assessment Tool
VMware have you handled with their Migration Assessment Tool. Well, when I say handled, I mean it will tell you ‘some’ of the things you will need to know. Using it is straightforward. Add your vRA7 instance to the tool and off it goes, discovering a multitude of facts. The tool lets you drill down in to various areas, letting you see if they are migratable; such as endpoints (vRO endpoints for example), reservations, Xaas Blueprints and more. There is even an option to migrate dependencies for each of your business groups; but don’t get your hopes up as it doesn’t work [editor: yet! why else would the option already exist?!?]. I think it is fair to say that the likelihood of vRA8 being capable of migrating from your vRA7 instance without any intervention/re-working/late nights is unlikely. I hope VMware proves me wrong in the future [editor: let’s hope that the 8.1 release will bring us some of the migration functionality to start playing with!]
Blueprints
Blueprints have changed in vRA8. Completely changed. The way we build them, what you can build and how you should build them are miles away from what you are used to. Unless [editor: deep breath] you are used to VMware Cloud Assembly; then you will see something similar to what you are used to. In the current version [editor: we are discussing vra 8.0.1] we no longer have Software Components, XaaS blueprint flexibility is ‘different’ and if you have workflows in vRO that are used in blueprints, the likelihood is that they will need to be completely re-written. All in all, this really is starting to sound quite painful. But, for all the effort you will need to put in, it is definitely worth moving from vRA7 to vRA, right?
Are People Missing The Point?
If you work in I.T then you are probably in love with the idea of a clean slate. That freshly rebuilt laptop, a greenfield datacentre ready for VMs – you just can’t beat that clean, brand new [editor: car?] smell. I guess, if you have vRA7 and are looking to migrate to vRA8, the likelihood that you are a VMware shop is 100% [editor: well, duh!?!]. So, you deploy your new vRA8 instance and start the process of setting up your cloud zones, writing blueprints, deploying VMs and generally falling in love with something new again. But, [editor: there is always a but with this guy] migrating your blueprints like for like (if even possible); is that right? Is this what you should be doing? It depends on your point of view, but I would say, in general, NO!
What Do I Get?
Lets take a scenario. In vRA 7 you have a blueprint that deploys you one or more virtual machines. The blueprint may install some software (using Software Components maybe), connect the virtual machines to the correct network, place them on the correct tier of storage etc. The process and end result may be something similar to this; a blueprint stored in vRA7.x, deploys 3 virtual machines onto a vSphere environment, performs some in guest operations and configures the networking. Pretty common, right?
An example vRA7.x blueprint; 3 virtual machines deployed to a vSphere estate, with in guest operations and network configuration
It would be obvious to take the requirements from the vRA7.x blueprint and re-create it in vRA8. It is fair to say that it would work and you would get the same end result as you had from your vRA7.x blueprint. But are you benefiting? What have you really achieved? What is vRA8 and this blueprint really giving you as a benefit? Well, nothing! You have what you already had! Wouldn’t the following be better?
A single blueprint, capable of deploying to one or more different clouds, private or public
Yes! A single blueprint that can deploy to different private or public cloud environments. Not a blueprint per cloud. A single blueprint. I know what you are thinking, ‘a single blueprint with lots of complexity and code thrown in to boot’ but you would be wrong! We can accomplish the above with a very simple blueprint in vRA8 [editor: we can accomplish this in less than 40 lines of YAML]. And so without further ado, I present, my point!
My Point
Businesses mature and I.T matures. One often drives the other, however, it is possible that at times, who is driving who, will change. Doing what we have always done isn’t necessarily wrong, however, it may mean you don’t realise the full benefit of what is in front of you. It may be that you are working in or for a business that is already looking at a hybrid cloud model, where you are going to keep an on-premise private vSphere estate, but utilise a public provider such as AWS for bursting at times of demand. Maybe the business is at a stage where it is considering the use of a public cloud provider. Maybe the business isn’t considering it at this time.
It is almost a certainty that within a period of time, a high majority of businesses will be operating with a hybrid cloud model in place. The overhead of deploying a virtual machine [editor: or multiple virtual machines, to provide a service] in vSphere is completely different to that of doing this in AWS, Google Cloud, Azure or A.N. Other cloud provider. The mechanism for deploying is different between the providers. You cannot use your vSphere template in MS Azure can you! vRA8 introduces the idea of cloud agnostic deployments; creation of a blueprint that doesn’t contain a vSphere virtual machine component, but a cloud agnostic virtual machine component.
‘So what?’ I hear you shout. [editor: sigh] Consider not just migrating what you have but think about what your business ‘may’ need in the future. You are going to have to recreate your blueprints anyway, so why not make them agnostic? Rather than creating a blueprint to deploy 3 virtual machines on vSphere, create a blueprint that can deploy 3 virtual machines to any cloud. It may just so happen that on Day 1 you only have a vSphere estate. Fair enough, your agnostic virtual machine can be happily deployed on vSphere. On day 30 when you need to try deploying to AWS, you can create your AWS cloud zone, tag your AWS environmental components and off you go! No massive re-writes, no new blueprint; just use what you already have! Be the hero that creates what you need now, that deploys to where you need now – but can deploy to somewhere yet to be defined!
- Don’t migrate like for like
- Create cloud agnostic blueprints
- Think re-use, re-use, re-use
- Be the hero! Design today for the world of tomorrow! [editor: have you been watching Futurama again? facepalm..]
