cloud infrastructure
Cloud Wars Heat Up
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy John Considine
Last week I wrote about the Cloud.com acquisition and what it means for Citrix, Rackspace, OpenStack and the industry. Next, I’d like to dig into the VMware announcement about their cloud infrastructure suite. Citrix clearly wanted to announce their news just prior to VMware’s, and for a good reason – Citrix is hitting VMware in a weak spot of their cloud strategy. It’s pretty clear that VMware is not getting the vCloud adoption they were anticipating from service providers and even enterprises.
In Paul Maritz’s presentation, he mentioned that VMware “…has been working closely with service providers because you need the same stacks on both sides [the private cloud and public cloud] to be able to ‘slide’ applications to the cloud…and back again.” At CloudSwitch we are dedicated to the notion that you don’t have to have identical infrastructure stacks between the data center and the cloud. You have to expect that what a cloud provider chooses will not necessarily be the same as what the enterprise has chosen, or that they will work together in lock-step. VMware seems committed to the strategy that they will provide the complete solution on both sides of the cloud, and that all parties will work together to stay coordinated. This is very different from Citrix’s positioning around more open and heterogeneous solutions.
Citrix and VMware have been competing in the virtualization space for years with a battle of features (mostly Citrix catching up with VMware and trying to gain share in the enterprise virtualization market), but the scope of the competition has been growing thanks to cloud computing. Cloud computing expands the server virtualization fight from hypervisor features to integrated stacks for deploying/managing infrastructure. The hypervisors remain important, but the new frontier contains everything from core networking to storage management, to large scale deployments to self-service IT. In this new battle, Citrix has some real strength in networking (Netscaler, etc.) and application delivery, and with their Cloud.com acquisition, they are capturing some proven orchestration technologies.
VMware is investing huge resources to expand their cloud offerings (Maritz claims a million man hours). Their focus is on adding features to their hypervisor and layers to their stack (vSphere+vCenter SRM+vCenter Operations+vShield+vCloud Director). They have lots of expertise in this area and direct interaction with enterprise customers and requirements. On the service provider side, they are dependent on feedback from VMware-based partners to provide input and learn how to build and run large-scale infrastructure clouds. We’ll have to see how this approach plays out vs. Citrix’s CloudStack.
In the end, this competition is great for all of us as well as for CloudSwitch specifically. The competition in the cloud space will continue to drive innovation, new features, and simplification of deployment for this great new platform called cloud computing. CloudSwitch is all about choice and giving enterprises control and flexibility in their cloud architectures. As the world of cloud computing evolves, we love to see different options, technologies, and capabilities – because a world filled with different cloud choices needs a CloudSwitch to connect all of the pieces.
Buying the Cloud
By John Considine
Here we are on July 12, mid-summer when you think most people are wondering about going to the beach in 90 degree weather, and instead we have big cloud news. Early this morning we were greeted with the announcement that Citrix is buying Cloud.com for more than $200M. After the initial congratulations to Sheng and the team at Cloud.com, the twitter-sphere and blogosphere went wild with thoughts and deal analysis. At the same time, everyone was waiting to hear what VMware was going to say in their “Cloud Infrastructure Launch” webcast.
I’ll start with some thoughts on the Cloud.com acquisition. Rather than go into the rationale and size of the deal, I’d like to focus on what this acquisition means to Citrix, OpenStack, and Rackspace.
It’s clear that Citrix has been a major supporter of OpenStack and that support makes sense since it’s a great way to compete against VMware. OpenStack is shaping up to be the answer to the closed source solutions being developed by VMware for building both public and private clouds. It’s also clear that Citrix needed a boost to gain traction and credibility in the market for producing cloud infrastructure. They have a good hypervisor and are busy building out more features, tools, and performance – but cloud infrastructure is a lot more than hypervisor + new features.
Enter the Cloud.com guys. They know how to build clouds, and already have traction with service providers and enterprises alike. They have proved that they know how to make a cloud scale – and this is not as easy as it sounds. Keep in mind that building clouds is more complicated than standing up virtualized clusters and running standard tools; there are complex networking, storage, and workload placement problems, not to mention versioning, maintenance, and operations.
So this is clearly a good thing for Citrix, and on the face of it, a good thing for Cloud.com – but what about OpenStack? The bigger question here is: what does this really mean for the OpenStack community? Is this a case of Citrix providing the enterprise/supported version of OpenStack as RedHat does for Linux? Will we see a set of capabilities delivered by Citrix that are built on OpenStack, but that are exclusive to Citrix’s CloudStack? Will OpenStack be increasingly driven by Citrix’s needs and integration with Xen (versus other hypervisors)?
If Citrix remains committed to its stated direction of providing the software for clouds (rather than building a cloud themselves), they are in a great position to capitalize on OpenStack. Rackspace, on the other hand, has a more complicated opportunity with OpenStack. They created the idea and built the community, but they are limited by the fact that they are themselves a cloud provider, so it would be hard for them to sell and support OpenStack software to other cloud providers and vendors. That leaves the door open for someone else to step in and become the enterprise software vendor for OpenStack. Clearly Citrix has been targeting this, and the addition of Cloud.com adds the full software stack and knowhow for building and deploying a cloud.
And in other news...VMware announced its Cloud Infrastructure suite today. Given that the VMware announcement was previously scheduled, I can only conclude that Citrix picked today to overlap with their announcement. These two announcements occurring on this sleepy mid-July date point to high activity in the cloud space, and the coming wars around who is going to provide the cloud infrastructure for both service providers and the enterprise. This may become a battle of closed source solutions from VMware and open source solutions from Citrix (and OpenStack)… I’ll write more about the VMware announcement in my next blog, but the battle between Citrix and VMware is definitely heating up.
What Cloud APIs Show Us About the Emerging Cloud Market
By John Considine
While there is no “official” definition of cloud computing, I believe programmatic access to virtually unlimited network, compute, and storage resources is an essential characteristic. Even though many users access cloud computing through consoles and third-party applications, the foundation of a cloud is a solid Application Programming Interface (API).
Since CloudSwitch works with many cloud providers, we have the opportunity to interact with a variety of cloud APIs—both active and soon-to-be-released versions. After working closely with both the APIs and those implementing them, I’d like to share some impressions:
- Despite all the discussion about standards, clouds are still very different. The important takeaway here is that cloud APIs have to cover a lot more than start/stop/delete a server, and once the API crosses into provisioning the infrastructure (network ranges, storage capacity, geography, accounts, etc.), things get more interesting.
- A cloud requires a very strong infrastructure to work properly. For public clouds, the infrastructure needs to be good enough to sell to others. If you know what to look for, key elements of the cloud API can inform you about the infrastructure, what tradeoffs the cloud provider has made, and the impact for end users (More on this later.)
- The cloud capabilities, and thus the APIs, are evolving fast. We see new API calls and expansion of existing functions as cloud providers add new features and capabilities. At the same time, we are talking with cloud providers about services that are coming soon and what form their API is likely to take. This is a great place to leverage the experience and work of companies like CloudSwitch to integrate the new capabilities into a coherent data model, and keep up with the changes.
An API can give a good indication of what is going on inside the cloud, particularly when you look at the functions beyond simple virtual machine control. I like to look at the network and storage APIs to understand how the cloud is built. For instance, in Amazon, the base network design is that each virtual server receives both a public and private IP addresses. The addresses are assigned from a pool based on where your machine ends up within their infrastructure so that the cloud provider can route network traffic to your servers. In Amazon, the base network design gives each machine both a public and private IP address, which are assigned from a pool based on where your machine ends up within their infrastructure. However, even though you get two IP addresses, the public one is actually just routed (or more accurately NAT’ed) to the private address. In Amazon, you only have a single network interface to your server, which is a simple and scalable architecture for the cloud provider to support, but will cause problems for applications that require at least two NICs (like some cluster applications).
An interesting contrast to this design is found in Terremark’s cloud offering. Like Amazon, IP addresses are defined by the provider so they can route traffic to your servers, but instead of the generic pool of addresses used by Amazon, Terremark allocates a range for your use when you first sign up. The good side of this approach is better control of the assignment of networking addresses; the bad side is potential scaling issues since you only have a limited number of addresses to work with. In addition, you can assign up to four NIC’s to each server in Terremark’s Enterprise cloud, which lets you create more complex network topologies and support applications that require multiple networks for proper operation.
Just when you thought this all makes sense, you have to take into account that in the Terremark model, servers only have internal addresses. Unlike Amazon, there is no default public NAT address for each server. Rather, Terremark has created a front-end load balancer that can be used to connect a public IP address to a specified set of servers by protocol and port. For each protocol and port you want to connect to your server, you must first create an “Internet Service” (in Terremark language) that defines a public IP/Port/Protocol and then assign a server and port to the Service, this creating a connection. Since this is a load balancer, you can add more than one server to each public IP/Port/Protocol group. Now that we have opened the discussion on load balancers, I have to mention that Amazon has a load balancer function as well. And while it is not required to connect public addresses to your cloud servers, it does support connecting multiple servers to a single public IP address.
The key point is that the APIs and the feature sets they define tell a story about the capabilities and design of a cloud infrastructure. Decisions made at the infrastructure level—like network address allocation, virtual device support, and load balancers—will impact the end user features, flexibility, and scalability of the whole service. When considering what cloud environment is best for your applications, you need to look down to the API level to understand how the cloud providers’ infrastructure decisions will impact your deployments.
Building a cloud is clearly complicated—but it provides an unbelievably powerful resource when it’s done right. Cloud providers choose key components and a base architecture for their service which results in clouds with different “sweet spots”. With CloudSwitch, you can span these different clouds and put the right application in the right environment.
Legacy Apps Make the Case for the Cloud
By John Considine
We often talk about CloudSwitch moving legacy applications to the cloud in a simple and secure way; this raises the question of what exactly we mean by “legacy.” To be more specific, we mean a broad range of apps—including third-party, custom and customized off-the-shelf applications—basically any application that has been developed in your current environment without specific design for a cloud.
It turns out that these existing applications are very important in cloud computing. When we started building CloudSwitch, we were focused on the hybrid cloud computing model; that is, some components must stay in the data center and other applications and functions can move to the cloud. However, it became apparent that “stretching” applications between the data center and cloud only works for certain types of deployments due to the added latency between the data center and the cloud. For this reason, we recommend moving as much of a multi-tier application to the cloud as you can. This allows the application to continue to run with low latencies between the different components. Sounds obvious, but this is where a whole new set of problems arise, and it’s what causes people to start talking about the challenges of moving legacy applications to the cloud.
In order to operate a multi-tier application in the cloud, you need to be able to control the application(s), infrastructure, and operating system, including things like a database tier, middleware, and custom applications. This also means that you have to “cloudify” each of these components. Suddenly you are looking at a lot of work, and potentially facing failure because some of those tiers can’t be modified to run in the cloud.
We saw a great example of this when Microsoft’s Azure service first launched. The initial release of Azure allowed application developers to build .NET applications and run them seamlessly on their local machines or in the Azure cloud. However, people trying to use this cloud usually had other applications/databases/etc. that were part of their solution, and there was no way to run these in Azure. This meant that there were a lot of things that could not be moved to Azure since “stretching” the application caused unacceptable latency and there was no way to connect the Azure deployment to the data center-side applications. Microsoft has since expanded the capabilities of Azure, but there are still many types of applications and services that cannot run in their environment.
Given all the challenges, why is it worth bothering to move legacy applications to the cloud? For most enterprises (as opposed to new ventures and SMBs), legacy apps by definition occupy the majority of the existing IT footprint, far more than newer applications, let alone those designed specifically to run in a cloud. In many of the companies we’ve worked with, legacy apps are well over 75% of the data center footprint, and they’re constantly expanding and creating needs for more capacity. Legacy apps tie up internal processing and storage resources, sometimes continually, sometimes in a “spiky” way to meet occasional massive needs. Their demand for computing power is usually growing (or skyrocketing), and contending with other applications. The enterprise then has to make tough choices about whether to buy more equipment or put up with degraded performance.
By providing access to virtually unlimited resources on demand, the cloud can bring a new level of elasticity and efficiency to a company’s IT environment. Legacy apps are often the best candidates for moving to the cloud, especially in cases where they’re infrequently used, or only need to scale for new releases or for seasonal/marketing-driven events. One of the best use cases for the cloud so far is the ability to offload this type of resource-consuming set of apps to a lower-cost cloud infrastructure, freeing IT to focus limited internal resources where they’re needed most.
