vRealize Operations Manager – Part 1

I thought I would begin to post a multiple part series on vRealize Operations (vROps).  I’ve come to be rather partial to this tool as it has solved many problems for me.  Plus I’m a data junkie and this gives me all that I want.  In this post I will review enterprise knowledge management and how vROps can help.  It may be an overlooked aspect of a tool that is so strongly marketed towards performance monitoring, but vROps is nothing if not dynamic.

The challenge many organizations face is a lack of knowledge shared between organizational units.  An infrastructure team may have a great inventory of servers but they rarely know the applications hosted on those servers.  In small to mid-sized organizations tribal knowledge often is easily and quickly obtained by the infrastructure team and they often do know what application is on the various servers.  This is from either supporting the servers or provisioning and completing the application install and is often mistaken for enterprise knowledge  However, that knowledge does not scale to 500 or 5000 servers And if the knowledge is resident within a single team then that’s not very enterprise now is it?

Luckily, vROps can help solve this problem by allowing the creation of customized application dashboards. You can create multiple types of dashboards to fit your particular needs.  My go to is an application health dashboard that binds multiple servers together into a single health badge.  The health badge provides a good representation of the application’s overall health from all servers, it takes up very little real estate on your dashboard, and you can link together multiple widgets to show additional data when the application’s health badge is selected.  The dashboard can also be shared to other user’s across your organization such as application owners, management, support desks, or to your executives.

By creating application dashboards you can begin to share common information across multiple user bases to break down communication barriers.  Your infrastructure team can now visually see what application is hosted on a group of servers.  Your application owners now see easy to understand health indicators of red, yellow, and green of their particular application.  The management team can see overall health of all applications they are responsible for.  Multiple users with differing needs, all interpreting and consuming the same data; basically they can now share a common language which is a wonderful thing in a datacenter.  Combine this with a configuration management database and poor knowledge management can quickly become a thing of the past.

In the next post I will walk you though how to setup an application dashboard and continue to review other features of vROps.

ITaaS Guiding Principles

I wanted to share some guiding principles I follow that assist me on maturing an organization towards ITaaS.  Each particular step has it’s own challenges and unique tools to assist in implementation.

My current team hears these principles nearly every day.  I actually have a standing challenge with them involving these principles.  I will buy their lunch if they can provide an example of a situation that is not resolved by use of the principles.  So far I’ve not paid out any lunches.  I’m rather confident in them as I have sat through numerous presentations demonstrating various cloud automation techniques, overcame my own daily challenges, and seen various long term strategies implemented .  In each situation the principles applied even if the individuals were not aware of them.

Each principle serves as a foundation component for the next to build upon.  As with any foundation item, if not soundly implemented can cause issues once built upon.  This is key to understand as it assists with future troubleshooting.


This is the first and oddly enough a very difficult principle to implement.  The standard can be anything; provisioning a server, a policy, a configuration standard, a process for applying a patch, etc..  Let’s take an example of provisioning a Windows 2012 R2 server.  Defining the provisioning process is something I would guess most organizations have defined.  With the implementation of virtualization it’s become a necessity and typically results in a golden image that most engineers create and maintain.  However, cloning an image is not server provisioning.  There are many other items to include such as IPAM, domain memberships, VLAN assignments, support tools, change control adherence, updating record repositories such as the CMDB, implementing firewall rules, DNS updates, and integration into various programs such as patch management, configuration management, compliance management, and vulnerability management to name a few.  When you start looking bigger picture the difficulty increases but it must be done to ensure the next step occurs.  To help keep things organized I find it best to use your documentation tool of choice such as a wiki, a word doc, or a KB repository.


This is a desire for any organization yet it is what is often at times eroded by the organization’s culture.  I find it’s eroded due to the fact that it’s not been achieved.  Everyone knows that one “go to” person they contact directly when they need something because they do it to your expectations when compared to the random person we get when we use the service desk queue.  Let’s continuing with our example and take the server provisioning standard and train a team to leverage it for each service request.  What if that team was 5 people, or 10, or 15, or 20…therein lies the challenge.  I find most managers struggle with a desire to not be dependent on a single person yet overwhelmed with frustrations when trying to train a large group to be consistent.  When working in the consistency principle, do not focus on how long the task takes.  Just ensure it is completed the same way every time. This is where a good set of tools can assist a team.  In this example a workflow orchestration tool is a game changer.  Something like vRealize Orchestrator can be extremely helpful.  I’ve heard someone refer to vRO as their perfect employee and they are right.  No matter who on your team of 20 is running the process, vRO will ensure each step is completed for them and not forgotten.


Do not confuse consistency with efficiency.  Remember, the consistency principle is simply ensuring something is completed the same way every time.  Efficiency is where you apply automation to your process.  To build on our example, you should now have some excellent data at your disposal.  If done well, you can now identify how long each step of the provisioning process takes.  Use that business intelligence to determine what should be automated.  While you can automate practically anything some things really shouldn’t.  Automation is a technical investment and as with any investment understand the ROI.  This is where you can build upon vRO’s API integration.  As you become more adept at using the tool you can integrate with other tool’s API such as your service desk software, hypervisor, IPAM device, firewalls, network devices, etc.. You can also use various scripts to assist in the automation and have vRO execute them for you.


This is really the nirvana of ITaaS that we are chasing.  This is where we truly find out if we are ITaaS or not.  Staying with our server provision example and let’s say the organization now wants you to add Red Hat Enterprise Linux 7 to the service catalog.  Or maybe you were just informed that a new firewall platform is being implemented.  Did your team just freak out?  Did they tell you that it will take months to deliver?  Or worse yet, did they tell you that it can’t be done without purchasing a new set of tools?  If the answer was “no problem” then congratulations, you are living the dream.  You see, this is really a validation of the preceding principles.  If each is sound then the impact on your service is minimized.  All you are doing is changing a standard, changing a workflow, or changing an API/script.  Not to minimize those efforts but this is why you go through normal development, testing, and QA cycles before you hit production.  If you are finding you have to completely start over there is a problem somewhere in the earlier phases.

Think about these four principles and how they can be used.  While used server provisioning as an example think about how they would apply in other programs such as monitoring, configuration management, patch management, or compliance management.