Flipping Bits

Azure Stack Infrastructure Design Patterns

The most common mistake made when migrating applications to cloud is using the same design patterns that were used on the application’s virtualization platform. Everyone knows not to do this. Too often, I encounter people trying to use the same hardware acquisition patterns for Azure Stack as they used for their virtualization platforms. It’s an expensive mistake that can lead to a very uneven tenant experience.

Don’t apply virtualization design patterns to cloud. Azure Stack is cloud. Don’t apply virtualization design patterns to Azure Stack

One of the advantages of a virtualization platform is that you can make the virtual machines look EXACTLY like the application requirements. If you need 2 vCPUs, 72GiB of RAM, and 156TiB of storage, go ahead and create that VM and attach a bunch of disks. If you need a whole lot of these VMs, you create a template. This flexibility is what made adoption of virtualization platforms like ESX and Hyper-V easy. It’s also driven some interesting rules of thumb when it comes to hardware acquisition, because in general, memory is the capacity gate for a virtualization platform.

“You can never have enough RAM” is the mantra for virtualization platforms

Of course, that doesn’t apply to cloud. When you deploy IaaS virtual machines, the CPU and RAM get dialed up and down together. There are a few different ratios, and in Azure Stack, they range from 768MB per vCPU for smallest VMs, with the biggest memory intensive VMs hitting the mark at 7 GB per vCPU. Fitting the application into these sizes is one of the lighter re-factoring exercises that application owners need to go through in order to port an app to cloud.

You can get a decent amount of RAM in an Azure Stack VM – up to 112 GiB – but remember those VMs come with 16 vCPUs

Here’s how Azure Stack’s VMs split out:

RAM to vCPU Ratio supported by Virtual Machine Types in Azure Stack

So the maximum RAM to vCPU ratio is 7 GiB (in the bigger A, D, and DS type VMs), and the average ratio will be much smaller. This is important and useful information. You can use that to start getting at what your RAM to core ratio should look like in Azure Stack.

You start by figuring out what your performance profile is going to look like. In Azure Stack, you cannot oversubscribe memory or storage, but you can oversubscribe the CPU (that is, have a greater than 1:1 ratio of virtual CPUs to physical cores). You have two general “safe” performance profiles:

1. If you want a performance oriented configuration, reflecting public Azure performance, you will limit the vCPU to core ratio to no more than 2:1 (as in Azure)

2. If you want something that is more efficient, reflecting a generalized virtualization platform, you will limit the vCPU to core ratio to no more than 4:1

From here, the math is simple.

Your maximum RAM per core in Azure Stack should be roughly 14 GiB:Core

That 14:1 ratio will allow you to run the maximum number of “memory intensive” virtual machines on your Azure Stack without oversubscribing your CPUs at an unsustainable level.

Let’s say you have an Azure Stack configuration with 1.5TiB of RAM with 48 physical cores. You have two choices:

1. Oversubscribe the CPUs to 4:1 vCPU:Core. In which case you risk CPU contention and these virtual machines will be by no definition the performance intensive machines your tenant subscribed to

2. Leave fully half of that RAM unused. In which case, you’ve paid for up to 12 TiB of RAM per scale unit that you will never use

For what it’s worth, the Dell EMC VxRack AS (Azure Stack) configurations vary from 14GiB to 16 GiB memory per physical core. You will have plenty of memory, regardless of the mix of general purpose and memory intensive virtual machines.

Player 4 has entered the game!

I'd like to congratulate Cisco and welcome them to the Azure Stack OEM club. Those of us at Dell who have been intimately involved in the development of our Azure Stack systems know how powerfully transformative the Stack platform is, and we're all excited to bring it to the market. This is unequivocally great news for everyone – customers, Microsoft, Cisco (obviously), and even Dell EMC.

For customers, choice is more critical than just being able comparison shop between vendors. When you have more vendor offerings, you'll have different perspectives and approaches. It drives innovation. For Microsoft, it widens the path to market, and increases overall investment in the Azure Stack ecosystem. Cisco gets a seat at the table as customers (and the software vendors they rely on) modernize their applications to leverage the technologies enabled by Azure PaaS on-premises.

This is also important and good news for Dell EMC, too! The name of the game in all platforms (Azure Stack included) is ubiquity. The primary factor preventing independent software vendors (ISVs) from wholesale re-platforming and modernization of their core applications is the lack of a universally available platform offering predictable, consistent, and curated cloud technologies. For example, there are a ton of vendors that offering object storage, but none have attained the kind of critical mass to the point where those ISVs can reasonably count on their customers having access to it. So systems of record continue to use relational databases even for use cases where it's an awkward technical fit.

Azure Stack promises to change that – its entry price points, along with Microsoft's proven history of creating platforms that are easily deployed, maintained and consumed mean that a LOT of people will be running Stack. When ISVs see that happening, they can justify the investment necessary to re-platform their applications based on Azure Stack (and by extension, Azure). A robust and healthy ecosystem with a high level of customer choice benefits everyone in that ecosystem – Dell EMC included.

While adding Cisco to the mix is great news for everyone, it's doesn't change Dell EMC's strategy. We will deliver a highly differentiated Azure Stack offering, featuring our industry-leading backup and recovery solutions, exceptional security and encryption, innovative and flexible pricing and consumption models, and a powerful and portable PaaS offering offering in Pivotal Cloud Foundry. Our product quality will benefit from Dell EMC's unmatched combined experience engineering, delivering, and supporting both converged platforms and engineered cloud platforms of all stripes. I can't wait for Dell EMC World in May. It's going to be one for the books.

“This is offensive” – the uncomfortable realities of the impending PaaS revolution

I was recently invited to speak with some customers about Dell EMC's plans around Azure Stack. As we were progressing through the meeting, one frustrated participant remarked "This is offensive". That was a new one to me. I don't think he was referring to me, but the idea that the IT market is changing yet again, and even before he was comfortable in the world of software-defined infrastructure. I understand that – the idea that you need to start thinking about the next transformation when you're in the midst of the current one is uncomfortable at best. But let's consider a few fairly uncontroversial concepts:

• In order to build a modern application, you need access to services like object storage, microservices, software defined networking, and more. In short, you need a cloud platform with PaaS services
• Enterprise applications like Exchange, SharePoint, and SAP are not encased in amber, frozen for all time. They all have a mission to deliver value to their customers. They need to be modernized in order to continue delivering that value and compete.

So, if you need a PaaS platform to deliver a modern application, and we can count on software vendors to modernize their applications, here's the uncomfortable truth:

If you want to run enterprise applications on premises in 10 years, you will be running at least some of them on PaaS. So you should start planning your PaaS strategy NOW.

You should be doing this with your entire team, asking vendors of your critical applications what their PaaS plans are, and getting your staff familiar with and used to managing PaaS platforms. Bi-modal IT - the idea of keeping part of your team focused on the transformation in process, while having another team look at the next transformation – is tempting. But remember: the longer an organization attempts to shield part of the team from change, the further behind they will be when that change comes.

And the change is closer at hand than most realize. PaaS platforms are already mature and robust – the only thing preventing PaaS adoption by these software vendors is ubiquity. Many of the PaaS platforms are locked into public cloud paradigms or lack the simplicity to gain the market share needed to convince vendors that it's worth targeting any particular PaaS platform. But that is changing, and soon. Appliance based solutions like the Dell EMC Native Hybrid Cloud are already on the market, and Microsoft will be entering the fray with Azure Stack solutions later this year. These solutions are inexpensive, efficient, well-documented, and easy to deploy and maintain.

Transformation is hard, and there are few industries like information technology that have such rapid transformation cycles. But at the same time, we don't need to dread the next transformation. The very idea of PaaS is to minimize the headaches presented by IaaS. We should embrace the revolution.

The Path to Dell EMC’s Azure Stack

I am incredibly excited to have the opportunity to lead the Microsoft Hybrid Cloud group in Dell EMC's Converged Platforms and Solutions Division. The last few years working with the Microsoft presales systems engineers at EMC have been a truly memorable experience. I've learned more than I thought possible, and have had the great pleasure to work with and meet some absolutely wonderful people in whom I've found competence, passion, creativity and personal warmth. I'm both happy and fortunate that I won't be going far, - I'll still be working closely with the MSpecialists.

Our first major initiative will be bringing the Dell EMC Azure Stack to market. There's been quite a bit of effort put forth on the solution so far, and we were excited to be on stage at the Ignite conference earlier this year. I'm even more excited to be able to present the product at Dell EMC World in May, and for the launch later next year. In the meantime, I'd like to share my thoughts on why I accepted the position, and why I think Dell EMC is hands down the best placed provider for Azure Stack solutions.

Azure Stack is the future ready platform for Microsoft applications

Imagine for a moment what an application like SharePoint, Exchange, or Dynamics might look like if it were conceived and built today. Instead of using a relational database as your only persistent storage, think about how scalable something like a SharePoint farm could be if it leveraged object storage instead of a relational database. Think about how quickly you could index content if it not only resided in that object store, but you could fire up microservices to index it, bursting the process to take advantage of any available compute (wherever it resides) in the face of a large ingest of new data. Now extend that imagination exercise to any existing enterprise application, whether custom or commercially provided. This is why developers are so excited about cloud technologies in general – they make fewer compromises when they have a robust, predictable cloud ecosystem from which to get their tools.

But enterprise application developers are still hamstrung today. They can choose to deploy their application on public clouds like Azure, Google, or Amazon to take advantage of all those rich cloud services. But it means two things:

1. Their customers will have to be OK with running their application in the public cloud. There are a whole host of reasons why someone might be unable, unwilling, or just hesitant to run an application in public cloud, from regulatory or governance concerns, disparate data locations, inadequate network, cost – the list goes on.
2. Legacy enterprise application developers face a "lift and shift" operation, which is unrealistic given the complexity these mission critical applications present. The inappropriateness of legacy applications running on modern cloud systems is the primary driver of bi-modal IT

But what if you could have predictable, consistent cloud services on commodity hardware, at small scale points, operable virtually anywhere by virtually anyone, and STILL have complete compatibility with a globally present megacloud provider? That is Azure Stack in a nutshell, and it's not hard to see why I'm buying into that vision, and Dell EMC is investing heavily.

The Azure Marketplace will change the enterprise computing landscape

Imagine again for a moment that you're setting up a new environment for SAP. Or SharePoint. Or any other multi-tier enterprise application. No matter how small it the application, you start your planning by figuring out the application requirements and translating that to infrastructure, eventually figuring out how many virtual or (gasp) physical machines you'll need to support the application, the kind of network connectivity you'll need, and then all the stuff around it, like backup, security, business continuity and so forth. Then you go about provisioning those servers. If you're lucky, your infrastructure team has set up infrastructure as a service, and some of the process is automated. Hopefully your networking is software defined, so you can automate some of that. But at the end of the day, you're still managing virtual machines. Once you get it set up, you have to set up a maintenance plan to ensure that everything gets patched and updated, and validated afterward.

The Azure Stack Marketplace can change much of how that is done. Enterprise application developers can use Azure Resource Manager to define what the applications optimal infrastructure landscape looks like. They can push out updates dynamically if desired. You can already see the complexity draining out of systems that use this model. Pivotal for example, has used the Azure Marketplace to automate the delivery of Cloud Foundry instances – complete with dozens of virtual machines and associated services with a single click. Developers will flock to this model because it's far easier to support and they can deliver value to the consumers at the pace of their own development, rather than the pace of the consumers' update cycle. Consumers will flock to the model for all the same reasons most of them use the app stores on their mobile phones – they are provisioning services, not servers, and the update process is cleaner.

And with Azure Stack, developers can deliver these modern (or modernized) applications without forcing customers into potentially awkward decisions around regulatory, geographic, hosting, or costing models.

Why I'm amped about the Dell EMC Azure Stack

Hands down, Dell EMC has more experience with Azure, Microsoft Hybrid Cloud, and converged engineering solutions than any other company. Let's take this one by one:

Dell EMC's existing investments in public Azure technologies are difficult to overstate. Pivotal is deeply invested in Azure, and you can find Cloud Foundry and Greenplum on the Azure Marketplace today. You can find our security solutions around Cloudlink SecureVM and RSA in the Marketplace as well. We have tiering solutions for both active data with Isilon Cloud Pools and CloudArray, and backup data with Cloudboost. You'll find that data protection solutions like Avamar Virtual Edition have been validated in Azure, and you can even purchase public Azure Cloud Services through Dell, including backup, test/dev labs, and site recovery. There's a lot of active work across all the Dell EMC divisions and there will be much good news around that in the coming year. Many of these services designed for Azure will be directly applicable to Azure Stack as it ships next year.

Dell is the only provider of the Microsoft Premium Cloud Platform System, and independently developed its little sister, the Dell Hybrid Cloud System. Dell has already brought significant innovation to the Microsoft cloud platforms through the streamlined patch and update process. Anyone who's built their own Windows Azure Pack system knows that the patching ballet of firmware, Windows, System Center, and Azure Pack itself is an art. The lessons we've learned around how to consistently deliver, maintain, and automate complex Microsoft private cloud systems will be brought to bear on the Azure Stack solution. Just as importantly, Dell has innovated with creative payment models that allow organization to consume private cloud with flexibility similar to public cloud.

On the infrastructure side, Dell EMC created the market for converged compute/storage/network solutions back in 2009 (as VCE), and it has been going like gangbusters ever since. We have led the way in making complex systems simple to consume, operate and support. As centerprises increasingly adopted cloud technologies, we expanded our engineered system portfolio to include the VMware-based Enterprise Hybrid Cloud, and more recently the Openstack-based Native Hybrid Cloud.

This will benefit customers in two primary ways: First, the organizational experience that Dell EMC has in delivering engineered cloud systems will be applied to the Azure Stack solution - not just the engineering, but delivery, consulting, support and maintenance. Second, the Dell EMC Azure Stack solution will complete Dell EMC's engineered cloud portfolio, allowing customers to choose a single provider and point of support for all of their engineered cloud needs.

You might be wondering what the vague handwaving about how that experience and tribal knowledge translates to in practice. It boils down to this:

Azure Stack is no science project for Dell

Skunkworks projects are exhilarating and fun. It's where the some of the most creative technical work gets done - where technology gets sculpted into value. However, you don't deliver skunkworks projects to customers at scale. So, we will be lighting up our engineering Centers of Excellence across the globe to innovate and improve the customer experience across the entire Azure Stack (and Azure for that matter). We will be training our own employees and partners across all functions from corporate engineers, services delivery, education, consulting, presales and sales to help customers get the most out of their Azure Stack experience.

I am excited for myself and Dell EMC to be part of this. It will be a fun, transformative, and at times challenging experience for everyone involved.

Visualizing the impact of the DSSD D5

The DSSD D5 flash appliance hit the market earlier this year with a lot of deserved fanfare and some mind-numbing performance numbers associated with it. Getting up to 10 million IO/s and 100 GBytes/s out of flash dies residing in 5 rack units is an engineering achievement requiring optimization at every level of the appliance. Those numbers are very impressive, and open a large number of use cases for high performance shared storage. For this blog post, I'll focus on storage latency (or service time). Service times represent the amount of time it takes to do a single unit of work, and it's more likely than raw throughput to impact the "wall clock" times of a given application process. I think Chad Sakac did a great job in his first blog post describing DSSD a couple years ago.

Orders of magnitude are difficult to visualize and appreciate. I'd like to offer up a couple new visualizations that can help you understand the relative performance of non-volatile shared storage available on the market today. I find that treemaps (below) are a fantastic way to show relative scale by plotting surface areas next to each other. Way over to the bottom right is the DSSD D5.

Relative service times of shared storage, 2016

The treemap is accurate, and a fantastic visualization. But despite that, it's abstract – it's difficult for humans (even engineers) to relate to things on the kind of scale that we're talking about here. The great Grace Hopper's description of a nanosecond is one of the most effective methods of describing orders of magnitude I've ever seen. You can watch the video of course, but here's what she did:

1. Established a baseline visualization that was easy to comprehend: the distance light will travel in a nanosecond is 11.8 inches
2. Drew a comparison to a larger measure: the distance light will travel in a microsecond is 984 feet (already this is difficult to comprehend – that's about the length of three football fields)
3. Applied the initial measure to a real-life use case: satellite signal latency

In that spirit, you can look at the travel times between some well-known places. Let's say that it takes the same amount of time for the DSSD to do an IO as it takes to travel from the White House to the US Supreme Court building (1.7 miles). I drew a 1.7 mile radius around the White House here:

For a typical all-flash array to do the same unit of work, it would be about 11.7 miles, any point in the beltway around Washington DC.

For a hybrid array to do the same amount of work, it would be about 50 miles, well beyond Baltimore

A typical HDD array would look like this:

You might notice that Cleveland is in that radius. Imagine that you could get from the White House to Cleveland in the same amount of time as it takes to get from the White House to the Supreme Court.

Analogies like this invite skepticism, but it's important to help people realize the impact that revolutionary technologies can have. If your application can move 10 times as fast as does today, what new things might be possible?

Enhancing Azure with EMC

I'm finding that the "cloud or not" decision increasingly reflects the "rent or buy" decision. Those decision trees have a lot more possible outcomes than they did a decade ago. For example, for most people the answer to "How do I get around town?" was either "Buy, lease or public transit". With the advent of services like Zipcar and Uber, there are more possible answers at a wider variety of price points. Most importantly, the choices are no longer mutually exclusive – after all, most Uber users own a car. The question changes from the very general "How do I get around town?" to "What's the best way to get where I'm going right now?"

The decision process looks very similar in information technology. The question is not "Where should I put all my applications?" It's "What's the best place for this application?" As long as the primary driver is economics, predictability and variability of the workload play the major role in how this decision is made. The more predictable the workload, the more likely it is that it belongs on premises.

So understanding that in the coming years nearly everyone will have workloads both in the cloud and on-premises, EMC is working hard to integrate with public cloud platforms, including Microsoft's Azure and Office 365. Here's a quick map of our current integration points:

Avamar Virtual Edition for Azure allows you to back up "born in the cloud" data, backup data to the cloud, and perform disaster recovery from the cloud. Source level deduplication is an excellent way to minimize egress costs.

Azure Site Recovery allows you to orchestrate disaster recovery and replication operations from Azure. By integrating with SAN replication, you can automate those DR operations while leveraging SRDF for site to site replication.

CloudArray is an incredibly elegant solution to cache or tier infrequently accessed data in public or private clouds. Its compatibility with a large variety of both publicly and privately hosted object stores help our customers avoid lock-in with robust options for cloud to cloud migration of storage.

CloudBoost is a feature of the EMC Data Protection Suite that allows you to leverage cloud object stores for long term retention of backups. EMC's industry leading technologies around data reduction help alleviate the pressures this can place on a WAN infrastructure.

CloudLink SecureVM encryption management not only enables the encryption of the entire virtual machine running in the cloud or on-premises, but by extension, allows you to dictate where and under what circumstances that virtual machine is allowed to run, giving you full control of your cloud VMs.

CloudPools for Isilon were recently announced, enabling native (sans gateway) tiering of Isilon data to object stores residing almost anywhere you want – on premises with ECS, AWS, Azure, and Virtustream.

I'm a huge fan of our Spanning folks. They offer SaaS backup products that can currently back up Office 365 mail and calendar data, not to mention Google Apps and Salesforce. They are coming out with new features at a very quick pace to add on to their already impressive offerings.

All of these solutions either help people leverage the cloud, creating a bridge between public and private IT, or they solve challenges inherent in cloud. These are both spaces that are worth keeping an eye on.

    

Data Platforms and the Death of Bi-Modal IT

A month ago, Gartner surprised many with their 2015 ODBMS Magic Quadrant publication in which Microsoft displaced Oracle for the top spot. As an outside, but nonetheless professionally invested observer, it didn't surprise me, and I'm really happy to see Microsoft getting the recognition they deserve in this space. It is possible to make too much of individual moves within quadrants, and frankly this was overall a pretty small move – Microsoft was very credible in this space before. But still, there is plenty of market intelligence to be derived from looking at trends over time, and even more from observing how the evaluation criteria have changed.

A Diverse ODBMS Ecosystem

In 2013, there were four vendors in the top right quadrant. 2014 saw the addition of four more, for a total of eight vendors. This year, there are eleven. Notably, Amazon Web Services entered the top right quadrant for the first time. Right away we see that the ODBMS market is rapidly diversifying. Even the name is telling - "Operational Database Management System", omitting the word "relational", is indicative of the redefinition of the data platforms market. This is no longer about the extent to which Microsoft can replicate Oracle RAC functionality – it's about which vendor can deliver the breadth of platforms in demand by developers.

There is a secular shift toward non-relational data stores for certain workloads, and to understand how that shift affects Microsoft, it's helpful to understand some of the history behind it. For decades, if you were writing a Windows-based application that needed a commercially supported, reliable data store at a reasonable price, you stored your data in SQL Server. That's a double edged sword, though. Because of its place in the market as the "reasonably priced, commercially supported" data platform, Microsoft found it difficult to raise prices for what were undeniably premium features like AlwaysOn Availability Groups. Oracle was unabashedly priced at a premium, willingly ceding the low end of the Windows and Linux RDBMS markets to SQL Server, MySQL, and PostgreSQL.

What this means to Oracle and Microsoft

Microsoft has two types of customers for its RDBMS: folks who leverage the "relational" part of the SQL platform, and those who just use it as a reliable place to reference data. Microsoft never made much money from the latter group to begin with, so a shift toward non-relational platforms is actually a financial opportunity for them. They can position Azure Tables and DocumentDB and actually increase revenue. And because they have a diverse set of data platform offerings, it leaves them free to raise prices on SQL Enterprise Edition for those premium features that allow them to functionally compete with Oracle.

Oracle does not have the same luxury – when an application developer migrates her app to noSQL from Oracle EE, not only does Oracle have to compete with the likes of MongoDB, but even if Oracle wins, they've lost 80% of their revenue. This is not a conversation an Oracle sales executive is going to want to have.

It's about the suite

There are plenty of folks who will claim that RDBMS is dead, and plenty of others who believe that non-relational data stores are a fad. Both of these stances are likely wrong. For a long time, you used a relational database management system to store structured data, whether you needed to declare relationships between those data or not. Those days are over – developers use the tools that are most appropriate to the needs of the application they're developing. It's ironic that Gartner – the organization that introduced the notion of "bi-modal IT" – is now rewarding Microsoft for its decidedly single-mode approach to the data platforms space.

It's always tempting and sometimes useful to put tech into "buckets", like "Application vs infrastructure resilient" or "pets vs cattle" or "platform 2 vs platform 3" or "cloud native vs …". These allow you to understand the needs of the application, and apply the right infrastructure technologies to support it.

Dividing your IT organization is probably a mistake

Although these terms may help you understand an applications and its needs, it's probably a bad way to organize an IT outfit. Beyond stifling innovation, dividing your IT organization into silos will sacrifice what most organizations need the most – agility. The ability for people to move, work across lines, and leverage appropriate technologies is critical. Organizations with multiple silos can be incredibly difficult for business units to work with.

As an example, let's take a business intelligence initiative. These are broad projects that touch all sorts of IT. They'll pull operational data from legacy line of business applications, they may leverage data warehouses, they may pull third party data via APIs, they might need semi-structured data that resides in one of your Hadoop clusters. In a bi-modal organization that data scientist, or business analyst, or sponsoring executive is now navigating the likely troubled waters of competing internal IT organizations who have differing ideas of how and where certain functions should be performed. Even simple problems with established fixes, like leveraging Hadoop to ease ETL workloads on data warehouses, become laden with political overtones.

This is probably not "face of IT" that most CIOs would like to present to the business.

The technology is collapsing anyway

For the better part of a decade, legacy application developers have been working furiously (and successfully) to modify their platforms to leverage non-resilient commodity infrastructure. There are about ten different ways to leverage Hadoop with SQL, some of which allow operational joins between RDBMS and Hadoop stores. Expertise in a function (such as messaging) does not lose its value when the underlying architecture of the messaging platform changes. The promises of hybrid cloud computing are coming to fruition. Organizations that have silos of "fast" and "slow" mode IT will be ill-equipped to make use of these developments.

The EMC Microsoft Cloud Reference Architecture

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.

Azure Services Taxonomy

Microsoft has done an amazing job building out the services available in Azure.  They are simultaneously broad and deep, and expanding rapidly. My job is to help EMC’s presales engineering community make sense of how Microsoft and EMC interact (both in the market and technically). I’ve struggled over the last year to do so, given the breadth of Azure offerings.  So I’ve put together what I’m called an Azure Services taxonomy to help us (and our customers) understand how Azure fits into their technology landscape.

I used a Venn diagram, with Management and IaaS, Data Services, Web/Mobile and Internet of Things, and finally Network.

This is not perfect, but I think a decent start.  I’ve probably missed some services, and quite certain that some of the services are misplaced.  Perhaps even the major categories of the taxonomy are a bit off.

What do you think, and what would you change?  Feel free to comment below, and if you’re interested in grabbing the source for this Venn, drop a comment as well.

 

Five reasons Microsoft should open source Azure Pack

Microsoft has made great strides with open source.  Codeplex has been around for a long time, and the Microsoft github repository is growing.  They’ve made real investments in Linux integration.  The Docker integration was a shocker at first (the Kubernetes and Openstack work even more so) but those already seem like par for the course.     Most interestingly this year, the Revolution Analytics acquisition both raised eyebrows and gained approving nods.

Microsoft has demonstrated that they will open source SDKs, APIs, and tools that enhance the Microsoft closed source ecosystem.  They’ve also demonstrated that they will acquire open source technology companies in areas where they’re finding it difficult to compete.  They’ve demonstrated that they will actively contribute to existing open source efforts.  Still, I argue that Microsoft has some way to go before I’d call them fully committed to open source.

Approximately two results to go…

What Microsoft hasn’t done is open source strategic intellectual property that was developed within the company.  For established IT firms, that process is a journey, and for Microsoft the sensible first step is Azure Pack. 

Increased adoption

People don’t hate closed source systems as long as they’re reliable, well-supported, actively developed by the vendor and there is a reasonable exit strategy.  If you make the wrong bet on a hypervisor – even enterprise-wide - the pain lasts just about as long as the equipment on which you have the hypervisor installed.  It would be painful if the vendor goes in a strategic direction incompatible with your own, but your investment in the platform would depreciate gradually, not disappear.

Cloud is an entirely different beast, with a heavy development, automation, and customization investment, the lifecycle of which far exceeds that of any hardware investment. When you change out a hypervisor cluster, you move the workloads.  When you change out a cloud system, you change all sorts of automation at all levels of the compute stack.  You change out billing systems, and all of the other moving parts that distinguish a cloud from a virtualized environment.

Customers investing thousands of hours in automation and customization efforts want to be assured that the platform they’re working on is going to be actively developed in a manner that jives with their strategy for a very long time.  A customer’s cloud system will be the central gear in their IT operations for easily the next decade.  This is the primary appeal of Openstack for customers.  That exit strategy is that the community can always fork the code if the primary advocates of the project go off the rails. 

Microsoft could directly monetize Azure Pack

Right now, Microsoft gives Azure Pack away for free (as in “free beer”, not “free speech”).  Free stuff gets relatively little love from sales organizations which are motivated to sell things that gains commission.  Any ROI for Microsoft comes from Azure Pack dragging revenue to System Center, Windows and SQL Servers, and public Azure.

Open sourcing Azure Pack would allow Microsoft to continue to give the software away, but opens a wide array of options for monetizing it.  The model I would choose is charging for support, like Red Hat.  This has three effects:

• Sales organization commitment to selling Azure Pack on its own merits
• Paid support gets them more robust data around deployment models
• Paid support gets them more robust data on problematic areas of Azure Pack

Of course there’s nothing stopping them from charging for support today, but that would have an unacceptable chilling effect on its place in the market.

Increased pace of development

Open sourcing would gain Microsoft access to a community of users/developers.  The sole developer of Azure Pack is Microsoft itself and has tied Azure Pack release pace to Windows.  The latter has improved, but we’re still looking at a 3 year release cycle between 2012 R2 and Windows Server 10.  Open Sourcing Azure Pack doesn’t meant that they need to accelerate that, but it does mean that user/developers don’t need to wait 3 years to see improvements that are critical to their business.

Better responsiveness to its customers

Right now, Microsoft Azure is the primary driver of new features in Azure Pack.  While it helps the larger community and has resulted in a very cool product, not every organization has the same priorities, scale or strategic direction as public Azure.  Community contribution to the core of Azure Pack would eventually make it more responsive to a much wider array of customers, and at a variety of scale points.

Increased cooperation from third party vendors

Cloud has a lot of moving parts, so vendors are challenged to provide everything – a multi-vendor approach is very appealing.  When vendors – the HPs, EMCs, IBMs of the world – decide where to invest, they apply much of the same calculus as end users when deciding which platforms in which to proactively invest. Unlike crowds of people, crowds of open source contributors reduce the turbulence of the crowd.  The seeming mayhem actually assures the individuals in the crowd they always have a seat at the table, and if they end up not liking their seat, they can go sit at another table without completely abandoning their investment.  For vendors, this is the appeal of Openstack.

Increased partnership with and enthusiasm from service providers

A couple months ago, I spoke to a forum of service providers about EMC’s efforts in the Microsoft Cloud space.  Some of them were Microsoft Cloud OS Network partners.  The tone of the discussion was markedly different than the discussion around open source efforts.  For most of them, the decision to enter the business was driven by the acknowledgement Microsoft could drive a fair amount of business their way if they offered a cloud solution based on Azure Pack.  That’s a far cry from deciding to establish a cloud platform for its technical capabilities, or because they have a strategic partnership.  A couple people from organizations said they chose not to enter COSN as they viewed Microsoft as a competitor.  Open sourcing the core of Azure Pack would allow these SPs to gain the assurance and control they need to make sure the needs of their business are met.

I would be shocked if this were not an active topic at some level within Microsoft, and would not be at all surprised to see it announced at Ignite next month or the Build conference next week.