My six-year-old asked me to tell him a bedtime story and it went something like this.
Jimmy and Tommy are both vRA admins. Jimmy works for a large financial company and Tommy works for a large company that makes really cool stuff. Both Jimmy and Tommy made great decisions to use vRA to automate their private clouds. Jimmy decided his organization was going to build all their own integrations. Tommy decided to use the SovLabs plugin for all his organizations needs.
Four weeks after Tommy’s vRA deployment his company was using vRA to deploy 75% of their virtual deployments. Meanwhile after four weeks Jimmy is just getting started designing the first of many needed integrations. Fast forward a year and Tommy’s organization is now deploying 100% of their workloads. They have reduced management overhead by 45%, and are able to deploy new server requests in under an hour.
A year later Jimmy’s company is still working out bugs with their custom code. Their administrative overhead is up 55% and it still takes over two-weeks for new server requests to be fulfilled. Jimmy is working 80+ hours a week and perpetually stressed. Tommy on the other hand is working 30 hours a week, but don’t tell his boss. He is enjoying his job and has next to no stress.
I then ask my six-year-old who he would rather be Jimmy or Tommy? He responded neither daddy I would rather be you. I asked him why he said he wanted to be me. He responded, because daddy you helped Tommy only have to work 30 hours a week.
GSS has decided on a number of design considerations for their vRA implementation. GSS is currently using a consumption based model for their resource allocation. They don’t pre-reserve any amount of resources for specific groups within the organization. GSS feels their current consumption model allows them to more efficiently manage their resources. It also prevents them from having pockets of idol resources that may never get used. Based on this utilization model GSS will be implementing the following elements within vRA.
GSS considered having a business group for each environment (Dev, Test, Stage, and Production). To evaluate how they would like to proceed they asked to have 5 initial tenants created. One for each of their environments and one to evaluate a collapsed model of all environments in one group.
- Development – All Developers across all groups within GSS
- Test – All QA engineers within GSS
- Stage – All production teams
- Production – All Production teams
- Gregarious – All Dev, QA, and Production teams
Continue reading “Road to Automation with VMware vRA – vRA Design Part 1”
In my previous article The Road to automation with VMware vRA I discussed I would be published a company profile for my fictitious company GSS. In this article we will be digging into GSS to take a look at where it is today, its challenges, processes, systems, and automation use cases.
Company: (GSS) Gregarious Simulation Systems
Profile: Successful Video Game Manufacturer
IT Staff: 80+
vSphere Sockets: 200+
Managed VMs: 3000+
Server Build Team: 12
Environments: Development, Test, Stage, Production
Continue reading “Road to Automation with VMware vRA – GSS Company Profile”
I think we need to take a few steps back and focus on vRA architecture and design. I’ve had many questions, requests, and discussions with some of my readers on this topic. Implementing vRA can lead to many rewarding outcomes, but as some have discovered it can also lead to aggravating outcomes if not designed properly upfront.
At first it can seem very straight forward. Create some endpoints, groups, reservations, and blueprints. Sprinkle in some integrations for custom hostname, IPAM, DNS and AD and you are on your way to fully automating your workload deployments, right? Not exactly. You can certainly do this and at first it will seem amazing, but as you mature and start to scale out your new catalog of services the lack of up front design and planning will quickly start to reveal itself.
Continue reading “The road to automation with VMware vRA”