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.

Business Groups

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”

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”