Thursday, August 24, 2017

Mobile First–Cloud First’ Strategy – How About System Center – 06 – SCVMM

Advice to the reader
This posting is part of a series of articles. In order to get a full grasp of it, I strongly advise you to start at the beginning of it.

Other postings in the same series:
01 – Kickoff
02 – SCCM
03 – SCOrch
04 – SCDPM
05 – SCSM
07 – SCOM

In the sixth posting of this series I’ll write about how System Center Virtual Machine Manager (SCVMM) relates to Microsoft’s Mobile First – Cloud First strategy. Like SCOrch & SCSM I don’t think that SCVMM is going to the cloud…

First released in 2007 to enterprise customers only, it was targeted for managing large numbers of virtual servers based on Microsoft Virtual Server (yikes!) and later (Q2 2008), hypervisors based on Hyper-V. 

Since then VMM has grown into a product of its own, with every release new functionalities being added, whereas others were removed, for instance:

  1. P2V migration removed from SCVMM 2012 R2 onwards;
  2. Support for Citrix XenServer removed form SCVMM 2016;
  3. Creation and management for private clouds, added in SCCM 2012 R2.

Private Cloud
Let’s dwell a bit longer on the last item of the previous list, the creation and management of Private Clouds.

On October 18th 2013, Microsoft announced the General Availability of Windows Server 2012 R2 (Cloud OS) and System Center 2012 R2. All new here was the Private Cloud vision of Microsoft.

Back then Azure was still branded Windows Azure and offered IaaS mostly (VMs, storage) and PaaS (websites, SQL, Python SDK and Traffic Manager).

As such, the public cloud was limited in its reach and capabilities. None the less, Microsoft top brass envisioned everyone going to the cloud. First everyone would build their own cloud (Private Cloud) and later on, move it into the public cloud, like Azure.

In order to enable the private cloud based on Microsoft technologies, System Center 2012 R2 had to make it happen. And SCVMM 2012 R2 would be the enabler of everything, bringing compute, storage and networking together, abstracting it and offering it as ready to use/consume building blocks for the (internal) customers of the IT department.

Instead of having to worry about compute, storage, networking, connectivity, middle tiers (like SQL and web for instance), a business unit could provision itself with just as many web/SharePoint servers (for instance) as required, as long it fit into the amount of resources assigned to them, hence the private cloud.

All through a portal. In the back SCVMM would initiate the required workloads, using a library of images, additional software and configuration items. Also with deep integration with SCOM (to monitor the provisioned VMs and the underlying hypervisors) and SCOrch, SCVMM could rollout almost anything, no matter how many tiers required.

Simply because the moment a certain type of installation was out of the reach of SCVMM, one or more SCOrch runbook could take care of it, complete with the registration and handling of the required tickets in the service system like SCSM.

The promise and the reality
On itself it sounded awesome. Finally the fully automated data center was there. Just roll out a bunch of servers, network components and loads of storage and SCVMM would take care of the rest. Even bare metal deployment of new Hyper-V hosts could be handled by SCVMM!

So say goodbye to rogue IT and – as IT department – be back in control in such a way by really helping the organization forward and not by frustrating it. Now a business unit could allocate workloads as required, all with ‘nothing’ more of a self-service portal and the click of a mouse button…

However, reality turned out to be a ‘bit’ harsher. For instance, the maintenance of SCVMM can be quite a challenge, especially when the SCVMM ‘fabric’ (all the components and servers used for the SCVMM environment) consists out a lot of servers, combined with a huge SCVMM library.

Especially the latter can be a real pain to maintain and to keep healthy. Orphaned resources in the SCVMM library are a ‘special’ treat. And yet, without the library SCVMM is dead in the water. Other challenges with the library are (but not limited to…): The migration of the library to a new set of servers, or making it high available (and keeping it like that!), or upgrading it to the latest version.

All in all it made SCVMM quite a challenge to run and maintain. However, the end user experience wasn’t that good either. Like any other software, a good GUI is crucial. And somehow, Microsoft seems to have issues with providing good user interfaces, whether full blown or web based. SCVMM isn’t an exception here unfortunately…

Trial & error. Self-service portal SCVMM
From the beginning the self-service portal of SCVMM turned out to be a challenge to say the least. Slow, buggy, not covering all required aspects of a full blown self-service portal, you name it. The SCVMM self-service portal had it all.

SCVMM 2012 R2 ditched it completely and had it replaced by System Center 2012 R2 App Controller. This replacement also delivered (basic) integration with Azure, enabling moving VMs to Azure. Actually, you had to store the VM in App Controller, and then copy it to Azure using the Azure Transfer Wizard, incorporated in App Controller. Afterwards additional steps in Azure were also required. As a result the ‘integration’ between your private cloud and Azure became a joke.

Due to the lack of success App Controller is dropped in the System Center family. When still requiring a self-service portal wrapped around SCVMM 2016, Microsoft recommends Windows Azure Pack instead, which is another challenge on itself.

However, between System Center 2012 R2 and System Center 2016 the world evolved quickly. Also Microsoft. So the private cloud mantra was scuttled because the world didn’t embrace it to the extend as the Microsoft top brass back then anticipated. Time for another approach!

Say hello to hybrid cloud (and goodbye to private cloud)
Instead Microsoft noticed that companies weren’t ready to roll out many different hard to manage and maintain System Center components in order to build their own private cloud.

Sure, the SDD (software defined datacenter) is still something wanted by many companies, but it’s easier to build and to maintain using other hardware/software incorporated solutions. On top of it, many companies chose all together not to board the private cloud train since it didn’t bring them to where they wanted to get.

Instead companies started to look for more hybrid solutions where their data, applications and workloads are running in different environments, whether on-premise (100% datacenter or 20% private cloud, who cares?) and in the public cloud. As a result their workforce can work anytime, anywhere with any device (when the apps are right that is).

Hence, the hybrid cloud was born, with a far bigger life expectancy and future ahead then the (Microsoft) private cloud ever had. Main reason here is that the hybrid cloud is based on the needs and requirements of the customers themselves, whereas Microsoft’s private cloud was forced upon the very same customers by Microsoft HQ. And even Microsoft HQ can’t dictate the world what to do or what to use. I guess their blew a different wind back then at Microsoft HQ compared to the more recent years.

Hybrid cloud: Nail to the coffin of SCVMM
As a direct result the role of SCVMM has dwindled big time. It’s back to it’s original function as intended when introduced back in 2007: Managing large numbers of hypervisors, primarily based on Hyper-V Sure you can also manage – a bit that is – VMware hosts through vCenter with it, but you really don’t want to go there, believe me.

Which is good, because SCVMM 2012 R2 never really delivered in enabling the private cloud. To much of a pain to maintain, configure and the lot. Also limited use cases since per type of configured server you have to go through the process of building it and save the related configurations as profiles. Only doable and justifiable when you roll out tens to hundreds of servers like that. However, in the smaller IT shop undoable and unrealistic.

Sure, in a hybrid scenario there are still valid use cases for SCVMM, as long as you’ve got a considerable amount of Hyper-V hosts running locally. However, when migrating/moving to the cloud, the use case of SCVMM lessens.

Yeah I know that Microsoft has released more information about delivering features and enhancements on a faster cadence for some System Center components, SCVMM included.

None the less, workloads will move more and more into the cloud. Whether VM based (IaaS) or service based (PaaS). As such the role of SCVMM will diminish over time. It will never get the role it had once with the GA of System Center 2012 R2 (enabling the private cloud).

Therefore with the move to Azure, SCVMM won’t stick and will shrink (at its best!) into a tool to manage Hyper-V based workloads running locally.

But when looking into how the Azure portal is growing into reach – in conjunction with Azure Automation Webhooks and Hybrid Workers – changes are that with the Azure Portal you’ll end up managing your local Hyper-V and perhaps even VMware hosts from the Azure portal.

With that the role of SCVMM will be downplayed even more and put into the role of an emergency tool when there is no internet connection, or the starting point of rolling out new Hyper-V hosts and the moment they’re online, management will taken over by the Azure portal.

Coming up next
In the seventh and last posting of this series I’ll write about SCOM (System Center Operations Manager). See you all next time.

No comments: