Amazon CloudFormation – BYO PaaS?

Amazon Web Services (AWS) recently announced the addition of CloudFormation to their offerings. With this addition, AWS continues to grow from an IaaS provider toward becoming a PaaS provider.  Will AWS will become a PaaS provider in terms a consistent programming interface (API) that abstracts the underlying cloud resources?  It not likely; certainly not soon.  Microsoft’s approach with Azure – start with the platform and then open the infrastructure – is better for true PaaS.  AWS offers so many divergent resources that building a consistent API for PaaS is near impossible.  From a technical perspective, their best approach might be to adopt (and heavily influence) OpenStack which has been experiencing good growth and adoption recently.  That direction is not good for business, however, since applications would be inherently portable to other providers.

So what’s the point of CloudFormation?  Amazon’s announcement states that CloudFormation aims to provide “an easy way to create a collection of AWS resources and provision them in an orderly and predictable fashion.”  Is this an IaaS or PaaS capability?  CloudFormation primarily falls into the Systems Management space which is definitely IaaS.  (The fact that AWS does or may expose programmatic interfaces to CloudFormation reaches into the PaaS arena, but it isn’t Cloud Formation’s raison d’être)

This new AWS functionality will certainly benefit SaaS providers.  I worked with a SaaS provider a year or so ago which hosted its own servers.  Their clientele were Fortune 500-types, so the company hosted a new set of hardware for each new client.  If the company were able to host its SaaS in AWS, it would save on capital outlays for new customers. CloudFormation would further cut costs on administrative personnel, freeing people to stand up temporary SaaS environments in AWS, for example, which would facilitate the sale process.

Interestingly, companies wanting to build special purpose (niche) cloud platforms should be able to leverage CloudFormation into their own PaaS.  As an example, companies could use AWS to host OpenStack and use CloudFormation for provisioning and management.  Such a company may gain enough customers and attention to be gobbled up by Amazon itself.

Caveat Developer: CSharp-CloudFiles

Rackspace has developed a C# SDK for CloudFiles, which in turn is based on OpenStack Object Storage.  As we’ve used this SDK, csharp-cloudfiles, we’ve encountered some unexpected “issues.”  While we see these issues as flaws, some may consider them to be unintended consequences – we’re open to correction.  Regardless, other developers may benefit from our comments here.

The first item has to do with UserCredentials’ constructors.  com.mosso.cloudfiles.UserCredentials has four constructors:

public UserCredentials(string username, string api_access_key) // AVOID!

public UserCredentials(Uri authUrl, string username, string api_access_key)

public UserCredentials(Uri authUrl, string username, string api_access_key, string cloudversion, string accountname)

public UserCredentials(Uri authUrl, string username, string api_access_key, string cloudversion, string accountname, ProxyCredentials proxyCredentials)

Note that all except the first constructor take the authorization url as the first parameter (authUrl).  It turns out that the authorization url is hard-coded in the first constructor, rendering it useless. This constructor uses https://api.mosso.com/auth (via Constants.MOSSO_AUTH_URL), so it’s only useful if you have valid authorization credentials for that end-point.  Since (it seems) only Rackspace’s internal development team has valid credentials there, they should remove this constructor.

While on the topic it’s important to point out that the authorization url passed in actually becomes part of the UserCredentials’ member data.  Code can retrieve the value from the AuthUrl property, but cannot set the value.  As a matter of fact, all of UserCredentials’ properties are get-only (and their member data fields are readonly)!  The only way to change any of the values is to construct a new UserCredentials.

Ok, so UserCredentials is no memory hog and creating multiples is unlikely in many applications.  The issue is that this class seems to ignore the value of separate concerns.  Why, for example, is proxyCredentials a member of this class?  Are a user, account and authorization url always expected to have a single proxyCredentials?  It seems to us that the endpoint, user credentials and proxy credentials need to be combined when calling down to the REST api, but should be separated for flexibility above that.  We think several of these members should be independent, or at least more flexible by being settable.

What are your thoughts?  We’d like to know; comment below.

OpenStack Storage: Not Just for Rackspace Anymore

From yesterday’s CloudScaling blog: OpenStack Object Storage Moves Beyond Rackspace.  This post reiterates that OpenStack was initially created by Rackspace and NASA, that Rackspace has been offering cloud-based storage via OpenStack, and that CloudScaling has recently assisted another company develop a commercial offering using OpenStack.

At first glance, I suspected the unnamed company was Internap and referred to their XIPCloud offering.  But CloudScaling’s blog refers to the company as “a Tier 1 ISP.”   The last I checked, Internap was Tier 2 at best, although it has good relationships with, and subs to, most Tier 1’s.

Regardless, this is good news for OpenStack.  The first major, outside adopter is often the most difficult.  If this second adopter has commercial success, others will quickly follow.  Let’s hope that adopters will also pony up development and test resources as well — OpenStack certainly needs it, particularly in language SDKs (PHP, Java, .NET, etc.)

How-To: Connecting to Internap’s XIPCloud

I didn’t find straight-forward instructions for using .NET with XIPCloud on Internap’s portal, so I’ll pass along what I learned.  This article assumes you are using Visual Studio 2010 and that you have already acquired an Internap account for XIPCloud.

Step-by-Step

  1. Acquire & Build OpenStack C# SDK
  1. Download the Rackspace C# library for OpenStack. Go to the Rackspace / csharp-cloud page on GitHub, push the Downloads button and click on the zip file to download (this article is based on csharp-cloudfiles-1.5.0.0)
  2. Extract the zip files into your preferred location (where you typically keep external or 3rd party code or assemblies)
  3. Using Visual Studio open the solution file, com.mosso.cloudfiles.sln, from the extracted files location.
  4. Build the solution – I batch built all configs.  Assuming the builds completed successfully, you now have the OpenStack C# assemblies in <Sln file location>csharp-cloudfiles-1.5.0.0com.mosso.cloudfilesbin[Debug|Release]
  5. Close the solution
  1. Create A OpenStack Client Application
    1. Create a new .NET application – this article uses a C# console application.
    2. Right-click the References folder under your new project and select Add Reference…
    3. Push the Browse button, navigate to the csharp-cloudfiles assemblies (see #4 above), select com.mosso.cloudfiles.dll and log4net.dll, push the Add button and then Close
    4. Now, change Program.cs to:

using System;

using com.mosso.cloudfiles;

using com.mosso.cloudfiles.domain;

namespace XIPCloudDemo

{

class Program

{

static void Main(string[] args)

{

Uri uriAuth = new Uri(“https://auth.storage.santa-clara.internapcloud.net/v1.0”);

string userName = “<your user name goes here>”;

string apiKey = “<your user password goes here>”;

UserCredentials userCreds = new UserCredentials(uriAuth, userName, apiKey, string.Empty, string.Empty);

Connection connection = new Connection(userCreds);

/* Add more code here.  For example, to create a container and copy a file to it…

connection.CreateContainer(containerName);

connection.PutStorageItem(containerName, localFilePath);

*/

}

}

}

Now you’re ready to build and run your app!  If you have trouble, use Fiddler to diagnose what’s going across in requests, headers, responses, etc.

Somewhere on Internap’s portal or in the developer guide I found the note about using your portal username (email address) and password for X-Auth-User and X-Auth-Key.  Hopefully they’ll provide actual API keys like all the other storage providers do.

I hope this helped you get started.  Feel free to leave a comment if you have any questions.