Amazon VPC
Is Amazon the Official Cloud Standard?
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Ellen Rubin
The Structure 2010 show was memorable for CloudSwitch, highlighted by the launch of the commercial version of our CloudSwitch Enterprise software that lets companies easily use multiple cloud providers to run their enterprise applications. With a few clicks, users run their applications where they best fit, based on their specific business and technical criteria.
So it certainly got our attention when at the Hybrid Clouds panel, Marten Mickos, CEO of Eucalyptus Systems, made a claim that Amazon’s API should be the basis for an industry standard. Marten added that the industry should orient around Amazon’s approach much as IBM’s personal computer became the standard for the PC industry. (Generations of loyal Mac users are probably glad there was still room for alternatives!)
If there were an industry standard, Amazon certainly has a strong claim for it. They’re the clear leader, with technology second to none. They’ve made huge contributions to advance cloud computing. Their API is highly proven and widely used, their cloud is highly scalable, and they have by far the biggest traction of any cloud. So full credit to Amazon for leading the way in bringing cloud computing into the mainstream. But it’s a big leap from there to saying that Amazon should be the basis for an industry standard.
It’s clear to us that the enterprise market wants options, both to avoid being locked-in and because other cloud providers have much to offer. While Amazon delivers many great benefits, other cloud providers have differentiated based on compliance, service level agreements, dedicated environments, storage capabilities, connectivity options, and support. They’ve implemented their infrastructures and APIs around these areas of differentiation. They’re unlikely to want to adopt a general industry standard since in many ways this commoditizes what they’ve built and limits their innovation.
One of the problems with any cloud standard is that making it work is fraught with controversy and technical complexity. A cloud computing “standard” involves more than a single API or format; it includes a number of elements that together define how the cloud works. For Amazon, this includes the AMI virtual machine format, their EC2 API that defines cloud operations, as well as their storage APIs, which come in two flavors: S3 and EBS. Other clouds have their own set of APIs and formats, developed to reflect their infrastructure characteristics and needs of their target market. VMware, for example, has its vCloud API as well as its own physical machine description (VMX) and storage unit (VMDK). There’s a spectrum of technologies in play that cloud providers and enterprises would first have to agree to, and then do a lot of heavy lifting in order to comply. I have yet to see a compelling reason that would justify their time and cost.
Of course, Amazon isn’t actively promoting a standard, they’re just “doing their thing” — offering their cloud services to whoever is willing to pay for them, and continuing to innovate in the cloud. I suspect they’re content to leave well enough alone and let the market take its course, and we'll continue to see innovations in everything from billing to cloud infrastructure from them.
The irony behind this standards debate is that CloudSwitch technology makes it largely irrelevant. The days when using a cloud meant binding yourself to a provider’s proprietary architecture are over. Cloud providers can innovate for their market segments, and customers can choose the best solution without fear of lock-in. Why go backwards? CloudSwitch customers know better.
Private Clouds: Old Wine in a New Bottle
By John McEleney
I recently read a Bank of America Merrill Lynch report about cloud computing, and they described private clouds as "old wine in a new bottle." I think they nailed it!
The report points out that a typical private cloud set-up looks much the same as the infrastructure components currently found in a corporate data center, with virtualization added to the mix. While the virtualization provides somewhat better server utilization, the elasticity and efficiency available in the public cloud has private clouds beat by a mile.
In short, the term "private cloud" is usually just a buzzword for virtualized internal environments that have been around for years. By replicating existing data center architectures, they also recreate the same cost and maintenance issues that cloud computing aims to alleviate.
Despite their limitations, there is still a lot of industry talk about creating internal private clouds using equipment running inside a company’s data center. So why do people consider building private clouds anyway?
To answer this question, you have to step back and examine some of the fundamental reasons why people are looking to cloud computing:
- The current infrastructure is not flexible enough to meet business needs
- Users of IT services have to wait too long to get access to additional computing resources
- CFOs and CIOs are tightening budgets, and they prefer operational expenses (tied directly to business performance) vs. capital expenses (allocated to business units)
In every case, the public cloud option outperforms the private cloud. Let’s examine each point:
- Flexibility – the ability to access essentially unlimited computing resources as you need them provides the ultimate level of flexibility. The scale of a public cloud like Amazon’s EC2 cannot possibly be replicated by a single enterprise. And that’s just one cloud – there are many others, allowing you to choose a range of providers according to your needs.
- Timeframes – to gain immediate access to public cloud compute resources, you only need an active account (and of course the appropriate corporate credentials). With a private cloud, users have to wait until the IT department completes the build out of the private cloud infrastructure. They are essentially subject to the same procurement and deployment challenges that had them looking at the public cloud in the first place.
- Budgets – everyone knows that the economic environment has brought a new level of scrutiny on expenses. In particular, capital budgets have been slashed. Approving millions of dollars (at least) to acquire, maintain and scale a private cloud sufficient for enterprise needs is becoming harder and harder to justify — especially when the "pay as you go" approach of public clouds is much more cost-effective.
There are many legitimate concerns that people have with the public cloud, including security, application migration and vendor lock-in. It is for these reasons and more that we created CloudSwitch. We’ve eliminated these previous barriers, so enterprises can take immediate advantage of the elasticity and economies of scale available in multi-tenant public clouds. Our technology is available now, and combines end-to-end security with point-and-click simplicity to revolutionize the way organizations deploy and manage their applications in public clouds.
Sir Isaac Newton may not have dreamed about clouds, but his first Law of Motion, "a body at rest tends to stay at rest", has been a good harbinger of cloud adoption until now. It is fair to expect that people will grasp for private clouds simply because it’s more comfortable (it’s the status quo). However, the rationale for public cloud adoption is so compelling that a majority of organizations will choose to embrace the likes of Amazon, Terremark, and other clouds. As adoption increases, private clouds will be used only for select applications, thus requiring far fewer resources than they currently demand. We’re also seeing the emergence of “hybrid” clouds that allow customers to toggle compute workloads between private and public clouds on an as-needed basis.
In the end, we will have new wine and it will be in a new bottle. With CloudSwitch technology, 2010 is shaping up to be a great vintage.
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.
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.
Amazon's VPC Opens the Door for Innovation and Enterprise Cloud Adoption
The recent announcement from Amazon of the Virtual Private Cloud (VPC) represents the next big advance in the evolution chain for cloud computing. Enterprises can now integrate their IT infrastructure with Amazon's vast computing and storage resources, using a VPN connection from their data center to their own virtual private cloud which then looks like part of their internal network.
Until the release of VPC, companies were left to build applications and utilize the cloud as a separate and somewhat siloed portion of their computing environment. In addition to the VPN connection, VPC allows cloud users to control their IP addressing within the Amazon cloud (previously IT addresses were assigned randomly). This may sound trivial, but it solves some tricky problems that made it hard to integrate cloud and internal resources.
Prior to VPC, every time you started a server in Amazon, you would get a new, randomly assigned IP address for that server. This created a lot of issues with how typical applications operate, e.g.: how do you communicate the address of this new server? How do you run authentication/certificate processes with a changing address? How do you deal with identity when IP addresses change at every start? Add to this the fact that cloud servers were separate from internal servers, so internal services that you normally take advantage of (DNS, LDAP, etc.) were not available without a lot of work. VPC provides a way to connect cloud resources to your data center and start to smooth over the differences.
Okay, how does this work? A standard edge networking device in your data center is configured to connect with Amazon's VPC. You can create your own sub-nets within Amazon, and when you launch a server you assign it to one of them. You specify the IP address range for your servers, and VPC performs the "security dance" to build the VPN between the edge device and your private network in Amazon's cloud. All you have to do is update your routing tables so that processes in the data center can reach applications in the cloud and you're off to the races.
By allowing customers to integrate their data center networks with Amazon's cloud, VPC takes the first step in bringing the cloud and the enterprise data center together. While one large hurdle has been removed, there's still work to be done, as indicated in RightScale's blog. As enterprises review the VPC offering, there are things they need to consider as they determine how to deploy and use it.
- Networking: VPC provides a layer-3 connection between the data center and the cloud, which means that traffic is based on IP address routing. You'll have some work to do to figure out things like managing addressing in the cloud, and the implication of MAC addresses changing on every server start. In contrast, the holy grail of this integration is based on the Ethernet level (layer-2), where everything "just works" -- allowing seamless migration of applications between the data center and the cloud (and back). Some applications require layer-2 connectivity (for broadcasting for example), which means they would probably need to remain in your data center.
- Security: As the name indicates, VPC doesn't provide truly private infrastructure, but a virtually private infrastructure -- servers deployed into your virtual private cloud are allocated from the same shared resources that Amazon uses for all its customers. Thus, you still have to think about possible additional security measures in the cloud, both for networking (VPC doesn't allow for encryption between servers), as well as how to protect data in shared storage.
- Management: Developers will have to deal with the "assembly required" aspect of mapping applications to Amazon's infrastructure. There's no simple way to move existing servers to the cloud, which means you'll have to determine how to provision and configure cloud resources, and how much custom work might be needed to interface with Amazon APIs. Deployment is complicated by Amazon specifics -- how to launch an instance, attach storage resources, reset applications to use the proper storage path, etc. You'll also have to address the fact that base servers run on "ephemeral storage", meaning that server outages cause the loss of all data/updates. (There are many blog posts on this topic; this one is typical.)
- Flexibility and choice: Finally, while VPC solves some major headaches for companies that are committed to AWS, it is not applicable for those who want the flexibility of multi-cloud offerings. This is important because users have no control of a cloud provider's infrastructure. When a provider decides to upgrade or change anything, users must go along for the ride.
So to sum up, Amazon's VPC represents an exciting step forward along the road to making the cloud truly enterprise-ready. Cloud computing has come a long way over the last two years, and in many ways Amazon has been setting the pace. Their new offering lays the foundation for the next set of solutions for enterprise adoption from other companies in the cloud computing ecosystem. At CloudSwitch, we're excited to take advantage of the ongoing improvements by Amazon to their infrastructure, and working hard to eliminate complexity and make cloud computing simple, seamless and more cost-effective than ever.
