A couple of days ago, our excellent Global Solutions Engineering team published two very notable reference architectures: Microsoft Cloud Foundation, and another tightly linked reference architecture that layers some of the most common Microsoft applications and platforms upon that foundation. This is, of course, not EMC’s only foray into the Microsoft private cloud space – we partnered with Cisco last year to show System Center on a UCS and VNX infrastructure, and again to layer Windows Azure Pack (WAP) on top of that same infrastructure. And of course we have VSPEX Solutions for everything from Hyper-V based end user computing with XtremIO and XenDesktop, to ScaleIO based Hyper-V solutions. There’s a ton more – too many to list here, but suffice it to say that this is hardly our first investment in the space.
Here’s what makes this particular solution different:
ViPR Controller is the secret sauce
Those of you familiar with the EMC Federation Enterprise Hybrid Cloud know that ViPR controller is the pivot point of our cloud solutions. ViPR Controller (or its open-source sister – CoprHD) allows cloud administrators to abstract the management, provisioning and metering of a multitude of storage platforms. This is how it fits into the context of a Windows Azure Pack solution.
ViPR continues to be very helpful (I would say crucial) in Windows cloud environments. While it’s possible to integrate storage platforms with SCVMM via SMI-S (and by by extension into WAP), this violates a central tenet of cloud – flexibility. It is highly desirable to avoid getting locked into a specific storage platform when deploying a cloud platform. After all, there are no unicorns – that is to say, that there is no single storage platform that can efficiently address the diverse workloads that you might want to put into your private cloud. You might start off with a general purpose platform (we chose VNX and VMAX as examples), but keeping in mind that you might soon want to add all-flash infrastructure like XtremIO, commodity scale-out infrastructure like ScaleIO, or legacy infrastructure like NetApp.
Without ViPR, adding these components is not all that simple. You will go in and mess about with SCVMM (which does many things well, but few would say it’s an optimal storage management tool). You might go into Orchestrator and change some scripts, or write new ones. But with ViPR, adding a storage platform to WAP becomes nearly trivial. Since ViPR is the only storage component that “talks” to SCVMM, you never have to change your cloud management stuff just because you want to change your storage stuff:
Seriously – it’s a four step process. Create the pool in ViPR, define the tier in SCVMM, assign the tier to your template, get that template into WAP.
And in fact, one of the coolest things in this reference architecture is VPLEX. To your business, it’s an incredible tool with incredible value. It provides site resilience, live migration, and storage cache coherency across sites up to 300 miles. But to Windows Azure Pack, it’s just another storage tier – completely transparent to the tenant, thanks to ViPR.
Application layering is the next (huge) step
It is soooo tempting to say that Exchange, SharePoint, SQL PaaS is icing on the cake for this solution. It’s not.
Yes – I do see that in this picture it looks like colorful icing on (an albeit weird) cake. And I refer to it as a “layer”. But consider that applications are why you want a cloud in the first place, and then look at this workflow for Exchange:
The cloud admin creates a template with an Exchange install script in SCVMM (there are at least a dozen examples, out there, but I like labbuildr as a reference), then surfaces it to WAP. The Exchange administrator logs into the WAP portal, provisions an Exchange server, and a half hour or so later has one. The process is similar with SharePoint and SQL server.
Which brings me to the second point. “Isn’t SQL as a service redundant since DBaaS is included in WAP?” The short answer is “a bit, but not really.” Yes, the WAP DBaaS offering is very attractive, but it’s exactly that – a database, as a service. You can easily extend that to be a database server as a service. This is really helpful in a couple of scenarios:
- Security and/or performance isolation
- Feature isolation
- Version-specific app support
- App support that needs access to the instance, and so can’t work through WAP
You quickly see here that while the DBaaS solution built into WAP is very useful, there are a wide variety of typical on-premises apps that simply cannot use it. But there’s no reason that you can’t apply cloud characteristics to those applications.
So who is this for?
Most obviously, this reference architecture is for Microsoft-centric operations, looking for a certain amount of scale, and a certain amount of technical flexibility. If you’re wondering what all the hype around Microsoft cloud is about, this is a lot to bite off at once. If you’re looking for a turnkey solution at this scale and of this type of architecture, you might want to look at the FEHC, which has even more robust application provisioning. But if you’re managing a sizable Hyper-V environment with System Center and looking for a way to take those next two steps into IaaS and Applications as a service, then Windows Azure Pack is a good way to take those steps, and EMC infrastructure can help you make it flexible, performant and resilient.