Maintenance Woes Handicap Microsoft's Azure

Last week, Microsoft product manager Steve Martin indicated in his blog that Azure would be a Microsoft-only service – hosted only by Microsoft in Microsoft data-centers. It seems that maintenance challenges, or the ability to “innovate freely,” are limiting the availability of Azure to a pure service play. To be fair, Microsoft has indicated that key technology developed to support Azure will find its way into Microsoft Windows server products, which, of course, can be purchased and deployed by anyone. But I have serious doubts about Microsoft as a service provider because I do not think they have the operational mentality to succeed on the margins that are available to service providers – they are not cheap and efficient like Amazon. Microsoft is already demonstrating that the ties to their past technology architecture are already handicapping the potential success of their future cloud endeavors.

Anyone that pays attention to my musings in this blog knows that I am a huge fan of Amazon's web services – particularly the elastic compute cloud (EC2). And I believe Amazon is going to be very successful in this space because they have led the way with an architecture that effectively de-couples the definition of the application from the definition of the compute resources. Plus, they have an operational mentality – they are cheap and efficient. Aside from Amazon, I believe the really big winners are going to be the technology companies that enable existing service providers to respond to Amazon with a technology model that loosely couples applications to the infrastructure - eliminating the complex maintenance challenges that have historically precluded elasticity and enabling seamless application delivery across public and private clouds. Here are some of the potential players and my handicap for their success.

VMware – I believe virtualization technology is going to play a critical role in cloud due to its ability to de-couple the applications from the host computers – enabling elegant maintenance and true elasticity. VMware is certainly the leader in this space, and there is little doubt that they have relevant technology. The key question is going to be their willingness to respond to the “cheapness” and “openness” requirement of the service providers. VMware has historically sold technology to enterprises in a typical perpetual software licensing model. Cloud will require much more sharing of risk/reward in the sales model and a willingness to be flexible in the technology requirements to co-innovate with the service providers and ecosystem partners. VMware is not known for its partnering mentality.

Citrix – Xen is currently the incumbent technology for virtualization at Amazon, and Citrix is clearly aligned with Xen due to their $500M purchase of XenSource. However, cloud to date seems to be all about Linux and related open source infrastructure due to the flexibility of the licensing model, and Citrix has historically been very tightly aligned to Microsoft and its associated technology and licensing model. I think it is an open question whether Citrix is willing to embrace a radically different business model to monetize Xen as part of a service provider cloud ecosystem.

Cisco – the announcement earlier this month about the Cisco unified computing system is all about a new brand of infrastructure that is unencumbered by the legacy approach which tightly couples applications to the compute host resources. I believe Cisco “gets it” much more so than the current mega-vendors HP and IBM – each of which is going to be hampered with the legacy approaches for application delivery and management. But, as is always the case with new ventures like Ciscos unified computing system, the sky is always bluest when there is nothing yet to lose. We'll see if they can actually execute in the market with a new model.

Microsoft – While Microsoft certainly has many strengths, I do not think any of them lend themselves particularly well to cloud success. Of all vendors, they have the most to lose, and the least to gain, with this new approach. Their sales and distribution model discourages elasticity, they are way behind the leaders in the market for virtualization technology, and they do not have a mindset to be operationally efficient as a service provider. I believe their biggest opportunity in cloud is to provide a new desktop approach that seamlessly integrates all of the services a user would expect to be effective and productive in a networked world. If Apple doesn't continue to run away with that opportunity, maybe Microsoft will make some hay in this space.

Google – I have criticized Google again and again for their AppEngine model that essentially requires application providers to recode their applications to fit Google's infrastructure. I actually do not think Google wants to be a big cloud player for “infrastructure” services in the manner that Amazon is currently defining the market. Instead I think Google is going to be a next generation application platform provider more in the mold of Apple with its consumer products, but geared more to the needs of the business user. As a giant SaaS platform for applications like email, office productivity, VOIP, calendaring, geographical services, etc., I think Google has a great play with their current approach. Just don't expect them to compete with Amazon in the infrastructure space.

Salesforce.com – I think Salesforce.com is completely out in left field for everything other than applications that need to reside close to their CRM application. I personally feel that Marc should just go ahead and take on SAP and Oracle in the business applications space and forget about trying to morph their highly proprietary application platform into a general purpose application delivery platform. They have a terrific sales team, a terrific customer base, and the competing applications from Oracle, SAP, and others are just awful in terms of the grief customers endure to maintain and support them.

EMC – Some folks may be a bit puzzled by the inclusion of EMC in this list of potential cloud players, but remember that EMC owns nearly 90% of VMware which means that cloud is definitely top of mind at EMC. And they actually have been thinking about the data problem associated with cloud. Namely, how do I ensure my data is available to my applications when they become portable across multiple compute service providers? Their Atmos product is effectively Amazon S3 in a box with some interesting features around policy management and data federation. As an equity play, EMC may be a cheap way to own VMW, and they might make some hay themselves if they execute in the cloud market ahead of the other storage providers.

The rest of the A-list technology providers – HP, IBM, Oracle, Red Hat, Sun – either do not get cloud, are actively bashing it (witness Oracle), have no assets that are currently relevant, or are so far behind in investing that, short of a series of acquisitions, I believe they will remain effectively irrelevant. Of course there will be lots of lip service and cute marketing tricks such as IBM's recent open cloud manifesto, but until there is some substance, I stand by the above handicaps.

Killing the OS Octopus

The inspiration for this blog post title comes from a Paul Maritz (CEO of VMware) quote, during his presentation to financial analysts last week. Paul used the phrase "severing the tentacles of complexity" multiple times when referring to the new level of business flexibility that is possible when applications are liberated from their physical host by encapsulating them inside of a virtual machine with “just enough operating system (or JeOS).” They can be provisioned much more quickly because there is no need to provision physical assets. They can be moved from datacenter to datacenter more quickly because there is no onerous installation and validation process required. Indeed, virtualization enables cloud computing because the applications are no longer defined by the physical computers upon which they run. But, until VMware truly embraces a JeOS approach with their operating system support matrix, they are simply recommending “isolating” the tentacles of complexity. And the result will be a perilous and expensive condition often referred to as VM sprawl.

So what is the difference between “isolating” the tentacles of complexity and “severing” them? Isolating the tentacles means shoving the previous definition of your application running on a physical server into a virtual machine box. When you put a virtual machine box around the octopus, it can no longer create mischief with other application octopi running on the same physical host. Its tentacles are “isolated,” and utilization on the physical host can be much higher. This approach is valuable, and it has catapulted VMware into the spotlight as one of the hottest technology companies on the planet.

However, the octopus is still alive and well inside the box, and system administrators must continue to feed that hungry animal in exactly the same way they did when it was living on a physical server host. The level of maintenance has not been reduced. The level of security vulnerability has not been reduced. Although isolated, it is still a resource hog because those crazy tentacles demand CPU, and memory, and disk to flail and flap as they do. This condition of ever expanding system administration grief associated with the frictionless deployment of virtualized applications whose tentacles of complexity have simply been isolated and not severed is known as VM sprawl. And it will be a nightmare of system administration expense for those that embrace it.

In order to avoid the nightmare of VM sprawl, the tentacles of the complexity octopus must actually be severed, not simply isolated. Application developers and system administrators alike must re-think the category of the operating system in the context of a virtualized datacenter. Since the operating system is no longer the conduit for managing the hardware, it should become a simple shared library for system services required by the application. Two great example of this approach are rPath and BEA's (now Oracle) liquid VM technology. With both of these platforms, the operating system is specified in a manner that explicitly supports the needs of the application – without any extra bloat associated with the typical general purpose OS approach. As a result, the OS in both of these cases is 10X or more smaller than the smallest installation option offered by a general purpose OS. In theory, this should lead to a 10X reduction in the scope and scale of administration activities. Severing the tentacles of complexity by re-thinking the OS eliminates the perils of VM sprawl.

But VMware does not currently support this approach. They only support the legacy vendors of general purpose OS technology. Sure, these new approaches have terrific performance and value, and VMware is happy to have them contribute to the value of their virtual appliance market, but their support statement pretty clearly favors “isolation” of complexity over true elimination of complexity. But the winds of change are steadily and surely blowing in favor of this new approach in the market. Red Hat, for example, just announced that they are going to market with a bare metal hypervisor that is directly competitive with the VMware approach in lieu of their historical product architecture - where virtualization was simply a feature of the general purpose operating system. And Paul Maritz was pretty clear in his presentation that “severing the tentacles of complexity” and a “just enough operating system” approach are important to VMware. Perhaps we are drifting toward the precipice of an all out war for the definition of the future datacenter operating system. I said it back in 2006, and I'll say it again today -- let's fry up that OS octopus polvo frito and serve it with some spicy mango chutney and cold beer.

Will Agile drive a Hybrid Cloud Approach?

Some workloads are perfectly suited for cloud deployment. Generally, these are workloads with transient or fluctuating demand, relatively static data (lots of reads, few writes), and no regulated data compliance issues (i.e. patient healthcare records). Test fits this description perfectly – especially with the growing popularity of Agile methods. With its focus on rapid iteration and feedback to achieve faster innovation and lower costs, Agile demands a flexible and low cost approach for testing cycles. I have no doubt that developers will begin using variable-cost compute cycles from services like Amazon EC2 because of its flexibility and pay-for-what-you-use capability. But I am also willing to bet that testing with Amazon will put further pressure on the IT organization to respond with a similar, self-service IT capability. I think a hybrid-cloud architecture with complementary internal and external capability will emerge as a productive response to the demand for true end-to-end agility.

Some time ago, I authored a blog post titled “When Agile Becomes Fragile” that outlined the challenge of implementing Agile development methods while attempting to preserve the legacy IT approach. What good is rapid development when the process for promoting an application to production takes several months to absorb even a few weeks of new development? If developers take their Agile methods to the cloud for testing (which they will), it becomes a slippery slope that ultimately leads to using the cloud for production. Rather than the typical, dysfunctional IT response of “don't do that – it's against policy,” I think the IT organization should instead consider implementing production capacity that mimics and complements cloud capability such as that offered by Amazon.

Along with all of the cool technology that is emerging to support Agile methods, new technology and standards are also emerging to support the notion of a hybrid-cloud. The new Atmos storage technology from EMC and the OVF standard for virtualizing applications are two good examples of hybrid-cloud technology. Atmos gives you the ability to describe your data in a manner that automatically promotes/replicates it to the cloud if it has been approved for cloud storage/availability. Whether applications run on an external cloud or on your “internal cloud,” the supporting data will be available. Similarly, OVF has the potential to enable virtualized applications to run effectively externally on the cloud or internally – without significant manual (and error prone) intervention by system administrators (or those developers that play a sysadmin on a TV show). In both cases, the goal is to enable greater flexibility for applications to run both internally and on the cloud – depending on the profile of the application and the availability of resources.

Agile is yet another important technology change that is going to pressure IT to evolve, and rPath is sponsoring a webinar series that dives into this topic in some detail. Whether you are a developer, an architect, or a system administrator, these webinars should be interesting to you. For the IT staff, the series may offer a glimpse at an approach for IT evolution that is helpful. In the face of Agile and cloud pressure, the alternative to evolution – extinction – is much less appealing.