Harness the Power of vRA with the SovLabs Property Toolkit and Template Engine – Part 2

In Part 1 of this series we walked through how you can use the SovLabs Property Toolkit and Template Engine to configure vRealize Automation (vRA) for our environment input.  In this second part of the series, we’re going to walk through setting up the Application and Compliance inputs for our particular use case.  If you are starting to see smoke, don’t be alarmed. It’s just our Genie being let out of the lamp.

In Part 1, we determined that the required options for our Application input will be:

  • WordPress
  • Microsoft SQL

Determine the Outcome

In this scenario, the selection of the application will have a significant impact on the outcome. However, while we need to think about the application, we also need to look at the larger picture. What do I mean by “the bigger picture”? Well, once we figure out the desired outcome for each of these items, we need to think about how each item relates to the environment and the choices we made in Part 1.

What if the requester chooses WordPress as the application and Production as the environment?  Alternatively, what if they choose Microsoft SQL and Development? Will the outcome of the application differ based on the environment to which it is being deployed?

Some things to consider:

  1. Do the workload specs change based on the environment selection?
  2. Do development, test, and production instances have the same CPU and Memory requirements?
  3. Do any of the integrations change based on application and environment?  
  4. Do WordPress and Microsoft SQL have the same backup requirements?
    1. Does this requirement change based on which environment the workload is being deployed to?
  5. What else could affect the outcome?

To read the entire article please see the original article on the SovLabs Blog.

Harness the Power of vRA with the SovLabs Property Toolkit and Template Engine – Part 1

Ever wish you were able to set more than one value from a single vRealize Automation (vRA) request input?  Have you ever wished you could make some aspects of vRA more dynamic and flexible? Wish you could simplify the vRA request form?  In this article I’m going to let the genie out of the bottle. All your wishes are about to come true. But before we summon our genie, let’s first dive into what it is that we are going to be wishing for.  My wish is to have a simple vRA request page with only three inputs that can drive the outcome of every aspect of my request. Sounds too good to be true doesn’t it? We will find out soon enough.

Finished Result
Harness the Power of vRA with the SovLabs Property Toolkit and Template Engine 1
Determine the needed Inputs

Determining what our inputs are going to be.  For my scenario I need to the following three inputs:

  1. The Environment (Production, Development, or Test)
  2. The Application (WordPress or Microsoft SQL)
  3. Compliance Needs (SOX or Non-SOX)

In my example, these are the only three items I need to know from the requester to build a server in my environment.  The remaining info I can gather from the business group they belong to, what resources the workload is placed on, etc. I know every environment is different and many will require more than three inputs.  Once you have read this entire 3-Part series, you will realize the number of inputs doesn’t matter. It’s how we use them that’s key.

Determine the outcome

What outcomes do we need to drive based on these inputs?  Or, how will these help determine the outcome of the overall deployment?  Will they influence items such as the machine hostname, Active Directory OU placement, vCenter Folder placement, vSphere tagging, application installation, etc?

Harness the Power of vRA with the SovLabs Property Toolkit and Template Engine 2

To read the full article please visit the SovLabs blog located here.

Infoblox, Custom Naming, and the Cost of Free Software

About the Free Custom Hostname Extension for vRealize Automation

Here at SovLabs we are always helping our audience make the decision to either “build” or “buy”, when it comes to VMware automation solutions. Recently, we have been involved in some discussions about the free Infoblox plugin for vRealize Automation. Specifically,these discussions are around how the free Infoblox plugin for vRealize Automation handles custom host naming. That discussion prompted us to consider all such customizations and the support required when when they are integrated with vRealize Automation.

Integrate with vRA
Custom Automation Considerations

There are a few issues at play here, including:

  • How do the different components of your solution work together?  
  • Was it designed wholistically or were pieces added on as you needed them?   
  • Did one source develop all of the components, or are they pulled piecemeal from multiple places?
  • If one source did all of the development – are they still available?  
  • Who is supporting the development work going forward?

Read the entire article written by Josh Andrews here on the SovLabs Blog.

Bedtime story – A tale of two vRA admins

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.

Going to VMworld? Stop by booth 2819 and say hello!

If your attending VMworld 2018 your most likely either already in Vegas or on your way. As I write this I’m the latter of the two waiting to hear the boarding announcement for my flight.

I thought I would take a few minutes and invite you all to stop by the SovLabs booth 2819 and say hello as you crawl your way through the solutions exchange.

Also feel free to check out the below sessions;

F5 Theater – Booth 1136

Mon & Tues: 11:30 -11:45am & 3:00 – 3:15pm

Wed: 10:30 – 10:45am & 3:00 – 3:15pm

Amazon – Booth 1400

Wed 3:30 – 3:50pm

Advanced Extensibility Use Case: vRealize Automation & Ansible Tower (MGT2191BU)

Mandalay Bay H, Level 2

Wed 11:00am – Noon

Hope to see you out there.

Road to Automation with VMware vRA – vRA Design Part 1

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”

Road to Automation with VMware vRA – GSS Company Profile

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
Employees: 1200+
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”

The road to automation with VMware vRA

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”

My vRA Journey Continues

Many of you may have already heard after 6 years at VMware I decided to spread my wings and go back to the world from which I came.  I joined VMware when they acquired DynamicOps a little over 6 years ago, and after 6 great years at VMware I decided to move on to something new, but not so new.

If it doesn’t show from my blog I am very passionate about automation.   I’m even more passionate about helping organizations overcome all the challenges they face during their journey towards automation.  Having been working with vRA for over 10 years I’ve learned a lot.  I’ve learned the countless ways different organizations go about achieving the same end result.  I’ve learned the challenges with automation in the datacenter.  I’ve learned I could probably write endlessly about what I have learned Winking smile

Continue reading “My vRA Journey Continues”