VMware's just-released vCloud Hybrid Service and Google's recently updated Compute and App Engine Cloud Platform illustrate two contrasting approaches to cloud services.
Both use the term "cloud," but they represent very different--indeed, generationally dissimilar--architectural and application design choices. VMware takes an evolutionary approach to the cloud based on what one might characterize as virtualization 1.0, in which VMs and their associated workloads on private infrastructure can be easily migrated to a public dedicated or multitenant service.
In essence, vCloud Hybrid extends an existing vSphere environment to an external service provider. Conceptually, it's no different than running vSphere instances in multiple enterprise data centers, all managed by vCloud Director. It's what VMware refers to as "extending your data center," except in this case it's a multitenant service run by somebody else.
This evolutionary approach has several advantages, chief among them familiarity and application compatibility. VMware spokespeople repeatedly highlighted these advantages during the service's launch event.
In contrast, Google takes a "cloud first" approach by targeting new workloads and applications that aren't currently running in an enterprise data center. Leveraging the vast distributed infrastructure it built to support its search engine and growing portfolio of cloud applications, Google initially introduced a PaaS product (App Engine) with a fully managed application development stack, and later a raw IaaS suite (Compute Engine) for those that want total flexibility in the application stack and infrastructure design.
While it's conceivable one could run the sort of persistent legacy applications typically deployed on a private vCloud within the Google cloud, that's not what it's designed for. Instead, Google targets the new generation of cloud-scale applications that are highly distributed. These cloud-scale applications use big (often colossal) databases and have wildly variable workloads. Tasks are expected to complete in seconds, not hours.
In fact, Google embraces resource dynamism to the max, with its per minute VM pricing (with 10-minute minimum), near instantaneous VM instantiation (its demo at Google I/O showed a parallelized application able to spin up and use new instances within seconds) and ability to scale persistent disk instances on the fly. All these capabilities open up tantalizing new usage scenarios.
Google's pricing granularity significantly changes the application scaling calculus. Say you have a parallelizable business analytics task that takes an hour to complete on a conventional cloud VM configuration. If VMs are priced by the hour and take more than a few minutes to spin up, as in the typical IaaS scenario, getting the job to complete faster will cost you money; money to buy a bigger VM instance for the full hour. With Compute Engine, you just buy six VMs for 10 minutes each (or, alternatively, a single 8x larger VM instance) and, voila, your job runs in a sixth the time for the same price.
The aforementioned Google I/O session describing the new Compute Engine features illustrates the application genres Compute Engine is made for. For example, MapR Technologies, a company specializing in Hadoop, NoSQL, database and streaming applications, used GCE, with 2,103 virtual instances and 8,412 virtual cores, to beat the MinuteSort world record (a measure of how quickly large data sets can be sorted). It sorted 1.5 TB (yes, that's 1,500 GB) in 60 seconds, over 2.5 times the previous mark. Definitely not the sort of thing you would do on vCloud.
The two product launch events illustrate a continued and frustrating ambiguity in the IT industry's use of the cloud label. For VMware, the cloud is little more than a managed VMware service that's much like any other remotely executing and managed application service (think Office 365 or managed DNS). Except in VMware's case, it's a raw hypervisor--wrapped by associated workload management software, for running legacy applications--not the applications themselves. Sure, vCloud can be used by the hour, but it's designed for workload migrations that operate on an IT (i.e. glacial) time scale, not at Internet (i.e. instantaneous) time.
In contrast, Google sees the cloud is a vast utility of services that can be tapped at will. If Compute Engine is the power company, where you can instantaneously vary usage at the flip of a switch, vCloud is akin to an emergency power management service that will provision diesel generators, stock them with fuel, keep them running and handle the maintenance.
These clashing cloud computing visions provide ample fodder for debate and "my way or the highway" polarization, but enterprise IT should actually consider the approaches as complementary.
Use vCloud for legacy, vertically scaled, traditional client-server or database applications. Use Google Compute Engine (or App, if you want a fully managed stack) for new distributed, horizontally scaled applications where the usage is unknown or hard to estimate and the benefits of rapid scaling and inherent cloud resilience are significant.
Sure, Google's services are new, but rapidly maturing to the point of being useful for serious enterprise workloads (and yes, they do have 3.5-nine SLAs). vCloud Hybrid is a great first-generation cloud infrastructure, but make no mistake, Google Compute Engine and AWS are the quintessential second-generation cloud utilities: the Pandora or Spotify music streaming to the last-generation's iTunes store and CD ripping.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
