Welcome!

From the Founder and CTO of CloudSwitch

John Considine

Subscribe to John Considine: eMailAlertsEmail Alerts
Get John Considine via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Cloudonomics Journal, CIO/CTO Update, Telecom Innovation, CloudSwitch on Ulitzer, LeanITmanager

Blog Post

What Cloud APIs Show Us About the Emerging Cloud Market

An API can give a good indication of what is going on inside the cloud

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:

  1. 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.
  2. 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.)
  3. 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.

Read the original blog entry...

More Stories By John Considine

John Considine is Co-Founder & CTO of Cloudswitch. He brings two decades of technology vision and proven experience in complex enterprise system development, integration and product delivery to CloudSwitch. Before founding CloudSwitch, he was Director of the Platform Products Group at Sun Microsystems, where he was responsible for the 69xx virtualized block storage system, 53xx NAS products, the 5800 Object Archive system, as well as the next generation NAS portfolio.

Considine came to Sun through the acquisition of Pirus Networks, where he was part of the early engineering team responsible for the development and release of the Pirus NAS product, including advanced development of parallel NAS functions and the Segmented File System. He has started and boot-strapped a number of start-ups with breakthrough technology in high-performance distributed systems and image processing. He has been granted patents for RAID and distributed file system technology. He began his career as an engineer at Raytheon Missile Systems, and holds a BS in Electrical Engineering from Rensselaer Polytechnic Institute.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.