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.

Analysis: CloudReplica’s Unlimited VM Instances Model

When I first saw the announcement (HT HPCInTheCloud) that CloudReplica is offering unlimited

When I first saw CloudReplica Announces Unlimited Virtual Machine Licensing (HT HPCInTheCloud), my first thought was that they might start driving down VM and Instance pricing in the cloud.  As I read further, however, I realized that’s not the case.

The trigger for my disappointment was the final paragraph of the announcement:

CloudReplica’s unlimited virtual machine license for Standard Edition is priced at $1,500 per month and is available immediately. Support is available for an unlimited number of Windows virtual machines using VMware or Microsoft® Hyper-V™ Server 2008 R2 virtualization platforms.

Hmmm. $1,500 / month.  How does that compare with other solutions?

VM Type Monthly Account Fee Cost/Hr Cost/Month VM Count Total Monthly Cost
CloudReplica Unlimited $1,500.00
Amazon EC2 Small $0.12 $87.60 17 $1,489.20
Large $0.48 $350.4 4 $1,401.60
Rackspace Cloud Server 1 GB $100 $0.08 $58.40 23 $1,443.20
2 GB $100 $0.16 $116.80 11 $1,384.80

In order to realize the cost benefits of “unlimited,” you might want to consider CloudReplica if you have (or need) more than 17 Small Instance VMs at Amazon or more than 23 of Rackspace’s 1 GB instances.  That’s a bunch of VMs to manage!  If you are using Amazon’s Large Instance or Rackspace’s next step up, 2 GB Cloud Server, the comparatives drop to 4 and 11.

Methodology (briefly)

As you should expect, the above analysis is not exhaustive.  Each vendor not only has different pricing levels, but unique pricing models as well.  Some charge for bandwidth consumption (ingress / egress), while some don’t.  Some charge differently for Linux instances than Windows.  Only Windows pricing was considered in this analysis since that is what CloudReplica offers.

The instance types used for comparison in this analysis were:

VM Type RAM (GB) Local Storage (GB) Comments
CloudReplica ? ? ? Web site unclear on sizes.
Amazon EC2 Small 1.7 160
Large 7.5 850 BIG jump from Small
Rackspace Cloud Server 1 GB 1.0 40
2 GB 2.0 80

JungleDisk Server Edition #FAIL!

We use JungleDisk Server Edition to ensure we have backups for one of our critical servers.  Why did we choose Server Edition over the basic JungleDisk?  Because we have several (higher) expectations for server backups:

  1. Scheduling – We need to have control over when the backups occur.
  2. Reliable – Once we install & configure the backup software, paths, schedule, etc., we need to trust that it will work without oversight or manual intervention.
  3. Fast – We run backups every six hours.  The backup process needs to be fast and complete well within the six hour window.  Obviously the amount of data being backed up is a major factor, especially on initial backup.  But the software itself is also a major factor.  We can manage schedules to data sizes, but we can’t change the software.  For reference our backups have been completing in less than 30 minutes (peak).
  4. Smart – Since the accumulation of data on servers tends to be large, the backup software needs to be very smart about what needs to be backed up and not waste CPU, memory, bandwidth unnecessarily.
  5. History / Logs – We need to be able to look back in time and know what happened with our backups, good or bad.
  6. IJW

JungleDisk SE has been a pretty good solution for us for a while.  But last night (~11 pm EST) one of our team members happened to look at the JungleDisk Activity Monitor on the server and found out that:

  • JungleDisk SE seemed to have skipped the most recent scheduled backup.
    • There was no record in Backup History (log) of any activity around that time-slot.
    • The Activity Monitor reported “Failed to open backup vault. No Internet connection detected. xSocketTimeout – HTTP connection timed out: SSL connection timeout”
    • Attempts to start a backup manually in Activity Monitor consistently failed with the same error.
  • JungleDisk’s Customer Support site doesn’t recognize our login credentials and doesn’t support SSO with main site.
    • We could successfully login to our JungleDisk account via https://www.jungledisk.com/
    • After successful login and navigating to My Account page (https://www.jungledisk.com/secure/account/), we tried to get support via the Support tab under Current User in the left navigation bar.
    • On submitting a support request, we were notified that we had to login first.
    • We clicked the link for login and found that the page (http://support.jungledisk.com/access/) is not secured!  We didn’t really want to pass our server backup credentials over plain-text, but we figured we can change the password later.
    • When we tried to login, however, JungleDisks Customer Support site didn’t recognize our credentials (the same credentials we used successfully on their main site)

As you’d expect, we were beginning to wonder if JungleDisk is still an active business.  The plot thickened, however.  The good news is that when we checked on the server this morning, JungleDisk appeared to be working again.  The bad news, however, is that the transfer rate is incredibly (painfully) slow (between just 88 & 104 kbps!).  The estimated time required was over 12 hours!  We weren’t sure what to do.  Should we just let it run and hope that future backups normalize back to less than 30 minutes?  Or should we reset the JungleDisk service in hopes that it would speed up?

Our team decided to ride it out.  We’ll hope that this backup completes successfully, and we’ll check the next few scheduled backups to ensure they complete quickly and successfully.

UPDATE:  Many will be interested to learn that Rackspace’s Server Backup product is just JungleDisk Server Edition rebranded.  While looking at backup options on Rackspace’s site, our guy was accosted by those flying online salesperson chat boxes.  He finally caved and simply asked the rep the difference between the two (JD SE & RS SB).  The chat went something like this (paraphrased):

AltaModa rep (AMT): What is the difference between JungleDisk Server Edition and Rackspace Server Backup?

Rackspace rep (RS): Rackspace Server Edition provides Fanatical Support.

AMT: We’re using JD SE now, but it didn’t backup last night.  We wonder if we should switch to something else.  Would RS SB require taking the server off-line?

RS (after a very long wait): Unfortunately, yes.

AMT: That is unfortunate.  Is it substantially different and better than JD SE?  We don’t want to take the server offline just to get the same thing.

RS: Rackspace Server Edition includes Fanatical Support

AMT: Ok, but is the code actually different?  Or is it just a rebranding of the JungleDisk code?

RS: Yes, the code is rebranded.  Would you like for me to send you a link….

We’re going to stay the course and see if the current JungleDisk will work (see above).  If we’re going to have to take the server offline, we’ll do a more exhaustive analysis of solutions that just Rackspace’s offerings.  If you have suggestions, please add a comment below.

UPDATE 2:  Some have asked about the relationship between Rackspace and JungleDisk.  Rackspace acquired JungleDisk in October, 2008.  Rackspace continued to invest in and maintain JungleDisk after the acquisition, but now may be killing off the JungleDisk brand.

Technorati Tags: ,