amazon
What Cloud APIs Show Us About the Emerging Cloud Market
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy 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.
Holiday Presents from the Cloud
As the year winds down, there are a few things I have come to expect: holiday parties, snow, and new features from cloud providers. This year exceeded all of my expectations, starting with a note in early December from our friends at Terremark letting us know that they have fixed their Windows pricing for cloud servers. Until this upgrade, if you started a Windows server in their cloud, you had to pay for a whole month of Windows licensing ($30-$100 depending on the version) no matter how much you used the server. This was rather un-cloudlike, where we want to only pay for what we use. With this new feature, running Windows in Terremark’s cloud only costs a few cents per hour (Linux cost + 20%).
Then came the snow—I live in New Hampshire, and on December 9th we received a foot of new snow to really get the season going. The very next day, Amazon made a big flurry of announcements—support for Windows 2008, the ability to boot from EBS, and the new US region US-West1.
Each of these features means big things for Amazon and for cloud users. First, support for Windows 2008 is a longstanding request from Amazon users. I think that Amazon was held back from supporting W2K8 because of the design of their boot volumes, which needed to be copied out of S3 into the local storage instance in order to boot the operating system. As the boot volume grows, the amount of resources consumed and the boot time of the servers grows significantly, withW2K8 requiring more than 10GB by default. In order to support W2K8, Amazon required another technology advance to make it possible—booting from EBS snapshots.
Perhaps the biggest problem enterprise users had with Amazon was the lack of persistent storage for boot volumes. Amazon has now created a way for users to build persistent boot volumes, coming up to parity with competitors on this feature. Sure, it’s a little different from how enterprises normally think about storage and configure boot volumes, but the ability to use EBS volumes for booting eliminates the window for data loss that most users had to contend with in the original boot methods. (This feature is not huge for CloudSwitch customers because we have always supported booting from EBS as part of our products; however, we can take advantage of this feature to improve boot times for servers in Amazon.)
Another major Amazon announcement is the new west coast region. Many of CloudSwitch’s early customers (not to mention our own development activities) are based on the east coast, so EC2’s primary location has been a good fit for us. Things only improved with the introduction of the Europe region since we have seen a lot of interest for European resources for both locality and compliance reasons. However, for west coast customers, having to hop across the whole country to access your cloud resources was less than ideal. Now these companies have local resources to target, but more important, this ongoing expansion shows that the public cloud is doing well. The addition of US-WEST1 and the soon-to-open Asia region reflect just how quickly the public cloud is growing and how hard Amazon is driving it.
The news from Amazon comes on top of what was already an outstanding year for cloud computing with major announcements from many key players, including: IBM software running in the cloud, new VMware-based public clouds, reduced pricing for servers and storage in the cloud, and Microsoft’s Azure gaining momentum. Each of the cloud providers is growing and maturing its cloud offerings, and we are reaching a tipping point where there are multiple clouds with sufficient features to support enterprise workloads. Get ready for 2010—it’s going to be an exciting year as large-scale enterprise cloud computing takes off.
