A Technology Switch: Cato Evolves from .Net to Python

The automation toolset now called Cato has come on a long journey since we started development in the early 2000s. The user interface was first written in VB / ASP to deliver self-service automation to our hosting customers.  We then moved pieces into Flash to address lack of tree control support (ugghh!).  Cato then moved to .Net. All the while long we kept up with the advances in Javascript, Ajax client-side processing, web 2.0, etc.

In 2011 we decided to release Cato as an open source project under the Apache 2.0 license. We faced an internal decision: Do we release the current software with the .Net component or do we take additional time to rewrite that part? Image

One thing was certain: we had to make it so the whole application ran on a single linux instance. This doesn’t scale but it allows people to try the software out without have a multiple machine install. The ideal scenario would be to be completely off .Net, but that could take months.

We decided to proceed with the .Net release to get the software into the open source world and start reaping the benefits of the feedback cycle. We figured out how to get Cato running on linux using Apache / mod_mono, which worked out nicely.

We received some feedback that the .Net codebase was holding back the potential contributor community. A couple of months ago we dove in and started converting the user interface and services to Python.

Why Python? Why not Ruby? Or PHP? Or Java? Or X?

We picked Python because:

  1. it’s a solid language with a large community and lots of extensions
  2. it’s interpreted, no compiling
  3. solid performance and lends well to scale
  4. easy to learn
  5. believe it or not, easily translates to and from C#

I must say the conversion has been easier that I expected. Well, let’s not say easy. We created a conversion script that did some of the work translating C# to Python and then the rest was elbow-grease.

Why did we want to tackle this project?

  •  Widen the developer community of Cato
  • Address a bias against .Net / Mono software
  • Make Cato easier to package, install and deploy
  • Allow for a more agile development process
  • Tighter integration with the backend services components of Cato

If you are of the hardy sort, go ahead and check out our github page and pull the latest. If you are a Pythonista you’ll notice some deviation from Pep 8. Either bear with us or  feel free to dig in and contribute!

If you are a .Net person interested in how we tackled this conversion, please feel free to contact me.

Advertisements
Previous Post
Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: