By Choong Keng Leong
Organizations implement VMware vRealize Automation (vRA) with the aim of shortening the provisioning of infrastructure services and the release of applications through self-service and automation. To achieve this, there is a need for balance between governance and business agility. Projects are more likely to fail or face significant obstacles if they do not plan adequately and ensure the necessary policies, processes and workflows are in place.
In this blog, we’ll explore some of these key planning and design activities that are often overlooked on the journey to cloud automation.
Key Players
The very first thing we need to do is identify key players. The roles are mapped to actual team members in the organization. Minimally, we need to identify:
- Service consumers – Authorized users of the self-service portal who can request and manage their cloud services, and which business groups they belong to
- Approvers – Approves all possible requests
- Cloud administrators – Administers and manages the cloud infrastructure, cloud resources, and the configuration and maintenance of vRA
- System administrators – Administers, configures and maintains the guest operating systems in the virtual machine
- Application administrators – Installs, administers, configures and maintains the application software hosted on the virtual machine
- Cloud security and compliance analyst –Monitors, analyzes and tests the security and compliance of application, guest OS and infrastructure
A common mistake is not identifying all the necessary key players and involving them in the planning and design early, which could have drastic impact to the vRA workflow designs.
Service Models
The next step is to determine what cloud services will be offered through vRA. Many organizations start by offering Infrastructure-as-a-Service (IaaS), provisioning virtual machines leveraging existing vSphere virtual machine templates. For organizations that are heavily virtualized, this is not transformational and has very little incremental impact visible to the business.
To realize the full values of vRA, organizations should look beyond provisioning up to the OS level. The steps that follow after the server with OS is ready usually involve manual or scripted steps and multiple parties (app, middleware, db, security, etc.). Being able to automate these steps, package them and offer the package as a cloud service will result in significant efficiency gains. For example, instead of offering Windows 2012 as a catalog item, why not offer a SQL Server 2012 or a Tier 2 Application consisting of a pair of load-balanced Apache Tomcat Servers and a SQL Server?
Developing service models requires engaging the business to understand their requirements. For example, what is the point in offering a Windows Server 2003 R2 catalog item when no new business applications will be running on it. We also need to understand the service levels and performance requirements so that we can provision the machines in the correct pool of resources that provide these capabilities. We also need to identify which business groups will be entitled to these services.
Request Models
Once the service models are defined, we can identify all the use cases for vRA and the types of requests within the scope of vRA. Request models (i.e. workflows) for the services are mapped out and documented. These may include:
- Request for a virtual machine
- Request for a database server
- Request to increase the resources of a virtual machine (e.g., add CPU, Memory)
- Request to extend the lease of a virtual machine
- Request to reboot a virtual machine
- Request to decommission virtual machine
- Request to snapshot a virtual machine
- Request to back up a virtual machine
It is common to start by mapping out the current workflows and automating some of the steps using vRA and/or vRealize Orchestrator. While this approach may be quick, it has proven inadequate in many customer use cases I have encountered. Requirements to interface with a business system, process and function appear in late stages of the vRA implementation project, jeopardizing the project’s schedule and budget. In order for an organization to automate as much of the process as possible and make significant impact to service provisioning and delivery times, the whole service fulfillment cycle needs to be studied, optimized and transformed. It’s imperative to understand the whole business process through initiation of an IT/business project, budgeting, approval, procurement, installation, building, integration, testing, release, operation, management, support and retirement. Then, you must identify how the vRA will fit and interface with the various stakeholders, functions, processes and systems. Sometimes, it is necessary to have the vRA interface with external workflows already existing in other systems such as an IT service management (ITSM) system.
In addition, each request model needs to be correctly categorized and aligned with the organization’s governance policy and processes. For example, a request for a virtual machine in production vs. a machine for development will require different change management process, approval levels and approvers. These considerations should be incorporated into the design of the workflows and vRA approval policies. The request models can also be re-categorized to reduce governance overhead due to risk reduction with process automation and standardization of blueprints.
Access and Entitlement Management
After the key players, service models and request models are finalized, the different security access roles for vRA can be defined and mapped to the key players, so that they have adequate permissions and privileges to perform their tasks defined in the request models. Entitlements to the services are also configured and granted to the respective business groups and/or users.
Communication and Awareness
Before the launch of the vRA, don’t forget to brief all key players on the processes and how to use the vRA based on their roles. Print and distribute reference cards and stickers to remind them of the process steps and how to get support when needed. It is important to cater for more hand-holding and support during the initial transition phase. The project will fail if users start to revert to old ways and stop using vRA.
========
Choong Keng Leong is an operations architect with VMware Professional Services and is based in Singapore. You can connect with him on LinkedIn
