Verizon Misses with Cloud Offering

About two weeks back, I was excited to see a headline about Verizon partnering with Red Hat to offer their customers a “new” cloud computing offering. I was hopeful that the details would reveal a KVM hypervisor based elastic compute capability coupled with an OVF based specification for virtual appliances to run on the service. I was also hoping to discover some details on storage as a service, with all of the services accessible via a management capability exposed via RESTful APIs. Boy, was I disappointed. Turns out the new Verizon cloud offering is just the old Verizon hosting offering with a new name.

Why is it so difficult for all of these old school infrastructure providers to understand the new path being blazed by Amazon AWS? Why can't they offer even a reasonable facsimile of the capability provided by Amazon? Surely it is the threat of Amazon that is leading them to re-name the old hosting stuff as the new cloud stuff. Why not go all the way and actually offer something that is competitive? Here is a recipe for any that are interested:

First, provide a X86 hypervisor based, virtualized compute service that allows the customer to bring their applications with them as pre-packaged, pre-configured virtual machines (virtual appliances). Don't ask them to boot a “standard OS” and then spend hours, days, weeks, months configuring it to work for them (because what you specified as the “standard” is certainly not what they have tested with their applications, and the whole purpose of elasticity is defeated if you can't quickly put images to work on the network in response to application demand). Better yet, let them boot existing Amazon Machine Images and VMware virtual appliances. Providing this capability is not rocket science. It is just work.

Second, provide a simple storage service (see Amazon S3 for what it should do) for storing unstructured data as well as for storing their virtual appliances that boot on the virtualized, elastic compute service. If you don't want to take the time to develop your own, follow AT&T's lead and go buy the capability EMC offers as part of the Atmos product line. You don't even have to think, you just need to write a check and viola – an Amazon S3 type capability running on your network. What could be easier?

Third, provide a block storage capability for attaching to virtual appliance images that must store state, such as database images. Most of the hosting companies already provide this type of SAN offering, so this part should be a no-brainer. Just price it with a very fine grained, variable cost approach (think megabyte-days, not months).

Fourth, provide access to the infrastructure management services via simple, RESTful APIs. You don't have to go overboard with capability at first, just make certain the basics are available in a manner that allows the services to be run effectively over the Internet without any funky protocols that are specific to your network implementation.

Finally, go sign up partners like rPath and RightScale to offer the next level of manageability and support for the virtual machines that will run on the network. These are the final touches that indicate to your customers that you are serious about providing a terrific capability for the complete lifecycle of your cloud computing offering. Instead of asking them to be patient with you while you re-name your hosting offering as a cloud offering in the hopes that it will assuage their bitterness that Amazon-like capability is not available on your network.

Federation - The Enterprise Cloud Objective

I know the title to this blog post sounds a bit like a Star Trek episode, but I believe I have an useful point to make with the term federation - even at the risk of sounding a bit corny. I have been watching with interest the lexicon of terms that are emerging to describe the architecture and value of cloud computing. VMware uses the terms Internal/External/Private to describe the distribution of application workloads across multiple networks in a coordinated fashion. Sun uses the terms Private/Public/Hybrid, respectively, to describe the same architecture (although they would argue for Sun branded components in lieu of Vmware/EMC branded components). I think both of these term sets as descriptors for a cloud architecture that distributes workloads across multiple networks are flawed and confusing. Rather than simply complaining, however, I am willing to offer a solution.

The term Federation describes the end state of an effective cloud architecture perfectly, and I think we should all begin using it when we attempt to sell our respective goods and services to enable the enterprise cloud. Whether part of a Internal/External/Federation combination or a Private/Public/Federation combination or Network1/Network2/Networkn/Federation, the common term accurately describes the end objective of cloud computing.

First, some attribution. This term was presented to me as a descriptor for cloud value during my work with the cloud infrastructure group at EMC (the folks that own the Atmos product line) over a year ago. It is now my turn to put some greater structure on this enviable original thought that belongs to EMC.

A good general definition for Federation (independent of an IT context) is a union of member entities that preserves the integrity of the policies of the individual members. Members get the benefits of the union while retaining control over their internal affairs.

In the case of a technology infrastructure federation (aka a cloud architecture), the primary benefit of the union is the lower cost and risk associated with a pool of technology assets which are available across a diversified set of independent networks. In other words, application workloads should be distributed to the network with the lowest risk adjusted cost of execution – i.e. based upon the risk policies of the enterprise. If the risk of running a mission critical, enterprise workload on Amazon's AWS network is deemed high (for whatever reason, real or perceived), that workload might stay on a proprietary network owned by the enterprise. Likewise, a low risk workload that is constantly being deferred due to capacity or complexity constraints on the enterprise network might in fact be run for the lowest cost at Amazon or a comparable provider. For a startup, the risk of depleting capital to purchase equipment may dictate that all workloads run on a third party network that offers a variable cost model for infrastructure (Infrastructure as a Service, IaaS).

Independent of the proprietary calculus for risk that must be undertaken by every enterprise relative to their unique situation, it should become clear to all that the distribution of application workloads across multiple networks based upon the cost/capability metrics of those networks will lower the risk adjusted cost of enterprise computing. The same diversification theories that apply to managing financial portfolio risk also apply to managing the distributed execution of application workloads. The historical challenge to this notion of application workload federation is the lack of an efficient market – the transaction cost associated with obtaining capacity for any given application on any given network were too high due to complexity and lack of standards for application packaging (de facto or otherwise). Now, with virtualization as the underpinning of the network market, virtual appliances as the packaging for workloads, high bandwidth network transit and webscale APIs for data placement/access, the time is coming for an efficient market where infrastructure capacity is available to applications across multiple networks. And Federation is the perfect word to describe a cloud architecture that lowers the risk adjusted cost of computing to the enterprise. Enterprise. Federation. Clouds. Star Trek.

EMC means Even More Clouds

Last week, Doug Merritt, an executive vice president at SAP, informed Information Week that EMC is planning to offer a computing utility service suitable for running enterprise applications. This “cloud” (a term popularized by Amazon's Elastic Compute Cloud) would offer SAP an ability to deliver on-demand applications to enterprise customers without investing the significant fixed costs of large scale datacenters ala Salesforce.com. The cloud capability is likely to make heavy use of the VMware hypervisor technology owned by EMC (Amazon uses the competing technology called Xen) such that providers like SAP can define their applications as virtual appliances (or a set of virtual appliances, known as a virtual appliance network or VAN) and launch them on-demand into the cloud. ISVs such as KnowledgeTree are already doing this using virtual appliances and Amazon's cloud. Why not SAP with an EMC cloud? What is the likely scenario for enterprise adoption?

As enterprise customers increasingly virtualize their datacenter computing resources, it is going to become more and more common for them to rely on computing clouds outside of their datacenter for certain application workloads. Once you have virtualized the infrastructure and defined the applications you run as virtual appliances (i.e. they are defined independent of the computer that they run upon and are loaded on the virtualized infrastructure pre-configured with the OS), moving the application from datacenter to datacenter (or cloud to cloud) becomes much easier.

Rather than buying all the servers required to deliver the application at peak load, it makes more sense to launch new instances in the cloud during peak demand and pay a variable cost charge until the peak subsides. Similarly, batch oriented analysis that occurs once per day/week/month (perhaps closing the books and logging transactions at the end of a month) is an ideal application scenario for cloud computing with virtual appliances. Why own the servers when you only use them periodically? Is it becoming clearer why SAP and EMC might be collaborating on this type of service? It's pretty clear to me.

But what's missing? Why is this obvious scenario not already mainstream? To begin with, production implementation of virtual infrastructure is only now beginning to take hold. Historically, virtualization was used extensively in test and development or to curb Windows server sprawl (a condition that occurs because Windows cannot effectively host more than one application per OS instance). Now, enterprises are beginning to understand that virtualizing every application makes sense because it separates the evolution and maintenance of the application from the evolution of the hardware infrastructure.

For example, it makes much more sense to create a virtual appliance for an existing single-threaded application and run several instances on a dual socket, quad-core eight way machine than to attempt to re-write the application to take advantage of the quad-core threading model. There is no value in the re-write, and virtualization provides a means to scale the application to take advantage of modern hardware. Another obvious benefit of this separation of application and hardware is server maintenance. You can shutdown one virtual appliance to patch it and then spin it back up without disturbing any of the other virtual appliances running on that server. This approach minimizes application to OS conflicts, and it eliminates application to application conflicts.

If virtualized production infrastructure is a cloud requirement that is slowly becoming a reality, what other obstacles lay on the path to cloud nirvana? Well, the current most popular approach for virtualizing applications is building a working system from legacy components and then “snapshotting” it with your favorite physical to virtual (P2V) tool. This approach will not scale to cloud computing. First, it is unlikely that your cloud provider has a virtualized infrastructure that is identical to your own. Going through a manual, ad-hoc process to build snapshot images for each cloud is going to be slow, expensive, and prone to errors. Also, it is inevitable that cheap, variable cost computing is going to tempt enterprises to define ever increasing numbers of application images. However, the administration and maintenance burden of the legacy OS system layer is going to result in skyrocketing administration costs or a “don't patch it and hope for the best” security scenario. A new approach to system software that couples the application with just enough OS is a requirement to make cloud computing a scalable reality without untenable administration costs or security risks.

Finally, and perhaps most importantly, there needs to be some “context” language by which networks of virtual appliances communicate to the cloud their requirements for system resources, configuration, and service level. How does an application server communicate to the cloud to boot it on the same network segment as the database server it requires? How does a critical application that is CPU intensive communicate a requirement for 2 CPUs and 4 gigabytes of RAM? How do redundant application servers communicate a requirement to run on separate physical servers to preserve a failsafe capability?

An application architecture for cloud computing will take into consideration all of these current deficiencies. The application and all of its associated context information will be defined as virtual appliances and virtual appliance networks independent from the physical infrastructure. The general purpose OS will give way to a just enough OS approach to enable a more simple and scalable maintenance model. And there will emerge cloud release and service brokering systems for launching applications into the clouds at acceptable service level without error prone manual processes and extraordinary administration expenses. These changes are coming. What are you doing to get your enterprise on the path to cloud computing?