By: Pierre Moncassin
You might not think of Patch Management as the coolest part of running an IT operation (cloud or non-cloud). It is a challenging, often time-consuming part of keeping infrastructure secure. And in many industries, it is a critical dependency for meeting regulatory requirements. As a result, IT managers can be forgiven for thinking of it as hard work that just needs to get done.
But recent discussions with global vCloud customers have given me a new perspective on the Patch Management function. These customers’ service owners have quickly grasped some new possibilities that come with an automated cloud infrastructure, one of which involves exploring how to offer patch management services to their end users. While this is not a new concept for managed providers, it’s a step change for an internal IT department – and one that turns Patch Management into a pretty exciting role.
Let us look at the key elements of that change:
To start with – we now see the patching toolset as a key component of end-user service. There is no point in offering patching services in a cloud environment without reliable automation to deliver them – the core toolset for patch reporting is of course VMware’s vCenter Configuration Manager, complemented by vCenter Orchestration for automation of specific remediation workflows.
But beyond the automated patch level checking and deployment, VCM also opens the possibility of adapting compliance reports for each user. Without going into too much detail here, it’s relatively straight forward to configure VCM in a ‘service-aware’ structure. VCM allows administrators to define virtual machine groups that match, for example, the virtual servers assigned to a specific division. Filters can be further set to extract only the patch information relating to that end user. Then your VCM reports can be exported into customer-facing reporting tools to provide customized compliance reports.
Make that switch to a service mindset. Of course, bringing the idea of ‘service’ into the patching activity means a mindset shift. It implies service levels and well-defined expectations on both sides. And it invites a financial perspective, too: the cost of delivering the services can be evaluated and potentially communicated back to the consumer. As the cloud organization matures, it may consider charging for those specific services.
Moving to a service approach for patching, then, can be a stepping-stone towards delivering further value-added services to the end user: not just routine patching, but other compliance services that can become more and more visible. Again, patching has moved well beyond its traditional role.
Next, integrate patching with Self-Service capabilities. As with any on-demand service, patching-as-a-service will need to be published in the Service Catalog. In all likelihood, patch management would be offered as an option complementing another service (e.g. server or application provisioning). There are many ways to publish such a service – on the service portal, for example, (if there is such a dedicated portal), or directly within vCenter Automation Center (vCAC). In vCAC, a patch management service could be made available either at provisioning time, or, potentially, at runtime when a machine is already running (vCAC for example can issue a ticket to the service desk to make the request).
Beyond the Service Catalog, there is also interesting integration potential if patching requirements are ‘pre-built’ into the vCAC blueprint. In a nutshell, vCAC can be configured to select the patching option that will be applied by vCenter Configuration Manager at runtime. In my view, that type of integration has considerable potential – potential I’ll explore in a separate blog in the near future.
Lastly, communicate. It’s an obvious part of a service mindset, but also one that’s easy to overlook: if you are adopting this new way of looking at patch management, you need to ensure that two-way communication takes place with your end users, whether to define the service, to publish it, or during its delivery. This is an extended, if not new function for the service owners.
In sum:
Patch Management – often associated with ‘hard work’ done in the background – is transformed with Cloud Operations:
- ‘Hard work’ becomes ‘service design work’ – a common theme across VMware Cloud Operations
- Team focus shifts from ‘keeping the servers running’ to a more creative activity closely engaged with consumers – offering a new, value-adding service
- Patching services set the foundation for more comprehensive services under the umbrella of Compliance-as-a-service
- Technical integrations between self-service provisioning and patch management can be leveraged to open new avenues for self-service automation
Follow @VMwareCloudOps and @Moncassin on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.
