Last entry I touched on the idea that management and orchestration will be the future battleground for cloud providers.  The future of IT operations is likely to take multiple forms ranging from some evolutionary enhancement to what folks do today (console based administration, reactive support) all the way through cloud scale programmatic operation of IT via devops process and tooling (examine any advanced AWS shop to see this in action).  Somewhere in the middle is the vision that Microsoft and VMware are betting on to be the most; the “hybrid cloud” model.

What does “hybrid cloud” really mean though?  Well ideally,  it requires a “cleaning of the IT house” when it comes to the management of on premise resources.  Evolving ultimately into some semblance of an actual “private cloud” in terms of process and tooling, and then extended out to one or more public cloud providers in a seamless fashion.  If your IT shop presents a service catalog to empowered technologists in your business lines who are able to procure services based on budget and SLA requirements, and then have those services instantiate on the platform that best fits their needs (be it on prem or at a provider), then you have what Microsoft and VMware would define as a “hybrid cloud”.

Microsoft, more than any other technology vendor, has all of the component bits in the breadth of their portfolio.  From the hypervisor up through the server and desktop OS to the application layer and tooling (both developer and management).  With the addition of Azure, Office 365 and Dynamics they have a comprehensive XaaS platform as well.  On the consumer side there is similar breadth of service and increasingly there are points of synergy between the two (Onedrive being a good example).

The challenge for Microsoft has been in actually rationalizing all of these assets and telling a compelling holistic story.  In addition, there are weak points in the portfolio where the offerings are not accepted as best of breed (VMware leads in virtualization, AWS leads in IaaS).  Probably most importantly, Microsoft tends to approach problems from a monolithic perspective and the experience is generally not a great one unless you completely buy-in on the vision.

Since I test from a VMware perspective, the release of the Azure Pack seemed like the perfect opportunity to put the Microsoft vision through its paces and see how far they’ve come in addressing these challenges.  So what is the “Azure Pack”?  Azure Pack is, in some ways, Microsoft’s version of the vCloud Suite.  It is a set of software components that overlay the existing Microsoft stack with administrative and consumption web portals and provide multi-tenant service orchestration and management.  You can look at it as “cloud provider in a box”, designed to bolt on to a set of existing infrastructure bits.  Of course anytime something is “in a box” I approach it with some skepticism, so armed with my MSDN subscription (generously entitling you to both free Azure and the entire Microsoft catalog for testing and development) I set off the implement the Redmond version of “hybrid”, but with a heterogeneous architecture (the kind real customers tend to run!)

Before approaching an implementation challenge like this one, it’s important to understand what all of the components are.  It is also critical to know how the pieces fit together and what deployment restrictions are in play.  I think this image, courtesy of Microsoft, tells the story really well:

So what are all of these component parts?  Let’s walk through them…

• Virtual Machine Manager:  VMM has had an interesting history within System Center.  It is the Microsoft (rough) equivalent of vCenter and these days is able to manage both native (hyper-V) and competitive (ESXi, XEN) hypervisors.  It is a critical component of the hybrid architecture in that it is responsible for surfacing virtual machine resources (organized within VMM into “clouds”) to the Azure console.
• System Center Operations Manager: no stranger to these pages, SCOM is Microsoft’s comprehensive, and extensible, monitoring platform.   SCOM tends to be the manager of choice for Microsoft workloads and that trend continues here with the Azure hybrid model.  This product maps most closely to vCenter Operations.
• Service Provider Foundation: this is an interesting set of bits.  It is an OData web service extension to Virtual Machine Manager that provides a multi-tenancy layer for the resources that VMM manages.  In the overall solution, this piece is closest to vCloud Director and is a standalone optional component packaged with System Center Orchestrator 2012.
• System Center Orchestrator (optional):  this is Microsoft’s orchestration engine, also known as “what’s left of Opalis”.  While a full install of Orchestrator is not an explicit requirement of the Azure Pack (again, Service Provider Foundation is required, but is a stand alone component), an orchestration engine if a vital component in any cloud strategy.  Automation stands with identity management, in my opinion, as the two critical pillars of IT as a Service.  VMware offers a similar set of capabilities in vCenter Orchestrator.
• System Center Service Manager (optional): service manager is Microsoft’s entry into the IT governance space.  The purpose of this class of software is to assist IT in implementing, automating and enforcing IT operational process using technology.  Essentially a policy engine, auditing system and dashboard, the service manager provides tracking and oversight of problem resolution, change control and asset lifecycle management. VMware’s offering is called, oddly enough, VMware Service Manager.
• SQL Server: really needs no introduction.  In this case, Service Manager requires either 08 or ’12.  The rest of the products are fine with ’14 and/or are able to utilize SQLExpress.  I have 08 and ’14 in my lab and utilized ’14 for everything except Service Manager.

Since this is a complex installation, I thought it would be useful to go over what I found to be the minimum footprint for deploying all services.  Keep in mind that this is a lab build. Obviously in production these functions would all be discrete and made highly available where applicable:

BOX 1:

• System Center Configuration Manager
• System Center Virtual Machine Manager
• System Center Orchestrator
• Service Provider Foundation
• Service Manager management server

BOX 2:

• System Center Operations Manager

BOX 3:

• Active Directory Domain Controller/DNS
• Azure Pack

BOX 4:

• SQL Server 2014
• Service Manager Data
• Database server for product backend
• Provider for Azure Pack

BOX 5 (optional):

• SQL Server 2008 R2
• Database server for Service Manager (requires 2k8R2 or 2k12)
• Provider for Azure Pack

There have been hundreds of pages written on all of the setup tasks required, so I decided to instead document some “heads ups” from my experience walking through the process end-to-end:

General Heads Ups

• As always be hyper aware of firewall rules.  Lots of custom port definitions in this process and lots of services that don’t automatically get firewall rules created (Analysis and Reporting Services on SQL for example).  When facing a ‘can’t connect’, check the firewall first
• Pick one service account, make it a domain admin and use it everywhere.  Life will be a lot easier this way with this build especially.  Of course if you are specifically testing the implications of a granular access control strategy then this doesn’t apply.

Virtual Machine manager and Service Provider Foundation Integration Notes

• Make note of the SPF service account during install – this is super important as the permissions get tricky
• SPF will create a set of local security groups on the SPF server.  They are all prefixed by “SPF-” quite handily.  For a lab install, add the service account to all of them.  In production more granular RBAC would likely be a better idea
• The VMM application pool, used by the Virtual Machine Manager web administration console and API, will install as NetworkService by default.  It should be switched to a named account which also  needs to be a member of the Service Provider Foundation groups
• The service account used for SPF and the VMM App Pool should be added to the Administrator role in Virtual Machine Manager under “Clouds”.

Service Manager Notes

• SCOM Agent must be uninstalled prior to installation but can be re-installed after installation is complete
• Ignore the collation warning.  Fantastic detail on that warning can be found here.
• Management server and datawarehouse server must be separate (cannot one box this)
• Pre-req’s will including warnings for RAM (wants 8GB) and CPU (wants 2.5Ghz) if these resources fall short
• Service Manager Server Install requires 1GB and wants to create a 2GB database.  It also wants to map internal service account privileges to a Windows security group (local or domain)
• Service Manager Data warehouse Install requires 1GB and wants to create 5 2GB databases.  It also wants to map internal service account privileges to a Windows security group (local or domain)
• SQL Reporting Services requires some custom configuration for Service Manager.  Luckily the Deployment Guide covers it in detail.
• Service Manager in general is honestly a pretty big pain in the ass.  Definitely keep the Deployment Guide handy

If everything goes well, the finished product is a working Azure style console for your on-prem private cloud:

With a few clicks, SQL Server and MySQL capacity can now be rolled into a DBaaS foundation.  Adding the capacity in is as easy as selecting the category on the left hand resource family menu (SQL or MySQL) and selecting “Add” from the bottom actions.   The required options are straightforward: the server name (and optional port number if non-standard), credentials, a group assignment (Azure Pack provides the ability to associate SQL servers into a server group for easier control of consumption) and finally the amount of space that can be consumed via hosting (storage on the server allocated to Azure Pack consumption).

Up next I’ll do a rundown of the experience using Azure Pack from both the service provider and consumer view.  Where possible I will compare/contrast to the VMware experience.  Stay tuned!