Cast Preview Release

For the last few months I’ve been working on and off for Cloudkick (now Rackspace) on a project that we are calling Cast. I’m happy to announce that this afternoon we’re releasing Cast version 0.1. The source has been on Github all along, but with this release we feel that the project has finally progressed to a point where:

  1. We’ve implemented the functionality planned for the first iteration.
  2. The afforementioned functionality actually works against the current version of Node.js.
  3. We have a website and documented most of the imporant parts.

Thats Great, So What Is It?

In short, Cast is an open-source deployment and service management system.

At Cloudkick we tend to see users deploying their code in one of three ways:

  1. Services are deployed via a configuration management system such as Puppet or Chef.
  2. Services are deployed by some sort SSH wrapper such as Fabric or Capistrano.
  3. Services are deployed to a “Platform as a Service” such as Heroku.

But none of these are perfect. Respectively:

  1. The high overhead in interacting with configuration management systems is fine when they are managing ‘infrastructure’ (that is, the systems on which you run your services), but tend to impede a smooth “devops” style workflow with fast iterations and easy deployment and upgrades.
  2. SSH wrappers typically work well enough on small scales, but but they feel like a hack, and don’t trivially integrate with in-house systems.
  3. Of all the options, people seem to like these the best. The price speaks for itself - Platforms as a Service (PaaS) are hugely valuable to their users. The problem is that these platforms are closed systems, inflexible and not very “sysadmin friendly”. When they go down, you’re trapped. When the pricing or terms change, you’re trapped. If they don’t or can’t do what you want, you’re trapped.

With this situation in mind, what could we write for our users? An Open Platform (optionally, as a Service).

What Can it Do?

Using Cast you can:

  1. Upload your application to a server.
  2. Create ‘instances’ of your application. Think ‘staging’ and ‘production’.
  3. Manage (start, stop, restart, etc) services provided by your application.
  4. Deploy new versions of your application.
  5. Do all of this from the command line or from a REST API.

We have a lot more interesting features planned. Hint: think “Cast cluster”. But if this sounds like something you’re interested in, stay tuned, share your thoughts or consider looking into a job at the new San Francisco Rackspace Office