Having a “private cloud” deployed in an organization is far more common than it used to be a year or two years ago, when no one even knew what exactly this term meant. Or even more, we can say that you probably have already implemented a “private cloud” in your environment and you haven't noticed. The term “private cloud” is used to name a set of resources (hardware and software), that are delivered as a service over the network (if the network is the Internet, we call this a “public cloud”). The key aspect in this definition is the “as a service” section, since having these resources provided in this way we can guarantee agility, scalability, and reliability, among other benefits. To achieve and gain these benefits within our own “private clouds” (for example, our business application contained in two tiers, web and database servers), we must understand that several of our well-known processes for managing these services must change, including the patch management.


So, how do we apply system patches in a service that must be online almost “anywhere” and “anytime”? There are basically two approaches:

  1. Patching in-place.
  2. Re-building tiers with new updates.

Patching in-place

This is what we already know about applying system patches, updating the systems in the machines used to provide the service. But this doesn’t mean that we shouldn’t test the updates we are about to release; by definition itself of a “private cloud”, these services must have a proper stage for validating the maintenance process. To get a few best practices in this scenario, please refer to  a previous article of mine: “Patching Best Practices: Patch Scheduling

Re-building tiers with new updates

Also the definition of a “private cloud” tries to force us to de-couple the services/platforms provided from hardware and even operating systems. This definition will also demand to have some kind of “portability” in our systems, requiring for example to have automated and fast ways to deploy our entire service into a new set of machines. This process for “re-building tiers” will represent the way from which, by using an automated workflow ideally, we can replace the “out-of-date” OS used by the service with the “updated” OS without requiring any downtime. Automation is another key term for this approach. If we are planning to quickly replace operating systems, we need to have processes and tools that can give us these features and maintain availability of our systems. Microsoft provides a set of tools and platforms we can evaluate to accomplish this, starting with System Center Virtual Machine Manager 2012 (SCVMM).


SCVMM 2012 and Service Templates

SCVMM 2012 includes the use of “Service Templates” as the ability to group a set of Virtual Machines that are configured with several components, including applications, and that can be treated as one. The use of Services can have several scenarios where we can gain efficiency if we integrate it with SCVMM, one example is that we can scale-up our services dynamically whenever it is needed: we can add/remove virtual machines to support the load necessary for our business application without requiring re-defining the architecture or causing downtimes. 

Generating the Workflow with System Center suite

Besides the “Service Template” concept in SCVMM, Microsoft is seeking to provide an entire solution for this scenario of re-building the tiers with new updates. Microsoft calls it "Automated Fabric Patching for the Private Cloud". To achieve a full automation of this process, it actually requires the use of several MS technologies:

  • Hyper-V (virtualization platform)
  • System Center Operations Manager - for monitoring the environment
  • System Center Service Manager - for generating the process for updating the "private cloud" (named "fabric" in this case)
  • System Center Orchestrator - for connecting the dots and generating the automation workflow


Getting in the detailed description of this workflow, the “Automated Fabric Patching” works this way:

  • Add updates to baseline
  • Baseline add to host cluster
  • Run a compliance scan
  • Start remediation
    • Start maintenance mode
      • Move from HA VMs using live migration
      • Break mode in failover cluster
    • Install Windows updates
    • Restart the computer
    • Run a compliance scan
    • Stop maintenance mode

To get more information about this, take a look at this article: “Automated Fabric Patching for the Private Cloud”.

The Missing Approach: Virtualizing Server Applications

I have a big expertise in virtualizing applications and specifically using Microsoft App-V. The latest version of SCVMM includes the platform for “Server App-V”, which is the technology use to “encapsulate” server applications (like a MySQL engine) into one “bubble” and convert it to a portable service. Having this portability we can easily move around different OS without requiring downtime.

So far, Server App-V does not have full support with several server applications, but Microsoft is expecting to include more and more suitable platforms to be virtualized. For more information, please visit this article of mine: “A Quick Glance to Server App-V and Sequencing Server Applications