03-Jan-2013

Version 2.0

A Brief Cloud/SaaS Review

Robert Komartin, ro.linkedin.com/in/robertkomartin/

0. Introduction
Despite the magic of one single unifying concept, the Software as a Service (SaaS)/cloud world is in fact far from being homogenous. From the barebone/servers (which are not even SaaS per-se but rather HaaS ) to the provisioning of business applications, a significant number of companies are providing a wide variety of services for an even wider array of software platforms. Thus, we can distinguish the following SaaS layers with their corresponding providers:

Layer 0 Hardware
0.A Hardware rental/leasing various financial services companies 0. B Colocation/dedicated servers provisioning HostGator, DreamHost, RackSpace, etc.

Layer 1 - Core
1.A - VM provisioning (IaaS) AWS (EC2), Azure (on VMs), Linode, etc. 1.B Software platform provisioning (PaaS) - Heroku, EngineYard, DotCloud, AWS (EB), etc.

Layer 2 Application
2.A - Platform with API (storage, authentication) provisioning - GAE, Azure (on .NET), Oracle (Java Cloud) 2.B Web/CMS platform provisioning Azure (on Web), GoDaddy, bluehost, DreamHost, 1&1, etc.

Layer 3 Business
3.A - API provisioning - PiCloud, Rapleaf, Google API 3.B - Application provisioning - Google Apps, Office 365, OpenERP, etc.

The overall schema below suggests how each level builds upon the capabilities provided by the previous layer(s) only the more representative layers 1 & 2 providers will be analysed in this document: -> 2.A (-> 3.A) (0.A-> 0.B->) 1.A -> 1.B -> -> 2.B (-> 3.B) A separate category (beyond the scope of this document) is the one of cloud software producers, such as Scalr and OpenStack (open source) or VMWare and Citrix (COTS) which are providing the software needed to run the private version of the clouds.

1|Page

robert.komartin@gmail.com

03-Jan-2013

Version 2.0

1. Amazon Web Services (AWS)

https://console.aws.amazon.com /free tier

OK/tested: VM/Iaas (EC2 t1.micro Amazon Linux AMI x86_64 EBS) provisioning Web/PaaS (Elastic Beanstalk - Python with MySQL standard template) provisioning http://default-environment-epe3jn6rmv.elasticbeanstalk.com/

Needs customizations/failed out of the box (OotB): N/A

Other standard options (but not tried): EC2 (IaaS provisioning): Windows, RedHat, SUSE, Ubuntu VMs; S3 (storage provisioning), database provisioning (with Dynamo and SimpleDB), Elastic Beanstalk (EB) PaaS for Java (with Tomcat), PHP, Ruby (with Rails and Sinatra), Python (with Flask and Django), .NET, etc.

Usage: Management: through the web dashboard, including EC2 deployments and EB standard template deployments. Command-line interface (CLI) available for custom EC2 and EB deployments (eb, using git). Pros: 1. Amazon is the first major player entering this space, and they are still a trendsetter; 2. Great set of functionalities/services. 3. Very stable and transparent management processes. Cons: It is still perceived largely as a IaaS (VM) supplier the PaaS services being to a certain extent bolton to the main AWS console (this being said, it seems to have the largest working PaaS collection). 2|Page robert.komartin@gmail.com

03-Jan-2013

Version 2.0

2. Windows Azure
http://manage.windowsazure.com /3-month trial

OK/tested:

VM (Win Server 2012) provisioning VM (Ubuntu) provisioning

Web/CMS (WordPress with MySQL) provisioning - http://andkombattle.azurewebsites.net/ Web/CMS (Joomla with MySQL) provisioning - http://rktestjoomla.azurewebsites.net/

Needs customizations/failed out of the box (OotB): Web/CMS (DotNetNuke Community Edition with SQL Server) Ruby on Rails blog deployment (Typo) - via Website Create (GitHub).

Other standard options (but not tried): .Net PaaS deploy in Visual Studio 2012, SQL Server, Storage, etc.

Usage: Management (including deployments) 100% through the web dashboard; .NET deployment from Visual Studio 2012. Pros: 1. Its Microsoft; 2. Best UI; 3. A wide range of SaaS services with incredible (given were talking about Microsoft) openness towards open-source; 4. Web hosting at no cost (for the shared instances). Cons: The services (App and Data) are still too much indebted to the .NET platform. 3|Page robert.komartin@gmail.com

03-Jan-2013

Version 2.0

3. Google App Engine (GAE)

https://appengine.google.com /free tier

OK/tested: Python w Google SDK (webapp2) custom dev - http://rk-cs253.appspot.com/newpost

Needs customizations/failed OotB: Ruby on Rails.

Other standard options (but not tried): Java (with Google SDK).

Usage: Management from the web dashboard; local client (both graphical user interface (GUI) Google App Engine Launcher, and CLI are available) for deployments. Pros: 1. Well, its Google 2. Rich services available when following the OotB SDK resources Cons: 1. Hard to change the standard (use relational DB instead of Google Datastore). 2. Basically, the developer is almost locked within the platform, migration being very difficult from infrastructure and development considerations.

4|Page

robert.komartin@gmail.com

03-Jan-2013

Version 2.0

4. Heroku
https://dashboard.heroku.com / free tier

OK/tested: Ruby on Rails custom dev (Postgres DB) - http://rprok.herokuapp.com/movies Ruby on Rails blog deployment (Typo) - http://secret-meadow-7151.herokuapp.com/

Needs customizations/failed OotB: Python/Bottle.

Other standard options (but not tried): Java/Spring, Play, Scala/Play, Python/Django(?).

Usage: Management using the web dashboard; CLI for deployment (heroku belt, using git). Pros: 1. Any Ruby on Rails app will be up and running in no time; 2. The add-ons many and easy to install and manage; 3. Built-in option for Facebook apps deployment. Cons: Almost anything else than Ruby on Rails (and its ecosystem) starts to be (a bit too) complicated.

5|Page

robert.komartin@gmail.com

03-Jan-2013

Version 2.0

5. Engine Yard
https://cloud.engineyard.com / 500 instance hours trial

OK/tested: Ruby on Rails blog deployment (Typo) - http://ec2-54-235-244-205.compute-1.amazonaws.com/ (Engine Yard uses AWS technical platform; app down to preserve the trial hours).

Need customizations/failed OotB: N/A (but thats because Engine Yard was very careful to clearly delineate the platform objectives and limitations).

Other standard options (but not tried): PHP stack.

Usage: Management (including instance deployment) 100% through the web dashboard (using github). Pros: 1. Clear focus on one platform (Ruby on Rails) (the PHP seems more like an afterthought). Cons: 2. No real free option for the dev/testing options, beyond the 500 hours instance trial.

6|Page

robert.komartin@gmail.com

03-Jan-2013

Version 2.0

6. DotCloud
https://dashboard.dotcloud.com / free development playground

OK/tested: Python & Postgres provisioning (Flask) - http://firsttest-rkomartin.dotcloud.com/ Ruby & MySQL provisioning (Sinatra) - http://secondtest-rkomartin.dotcloud.com/

Need customizations/failed OotB: N/A (but significantly more difficult to configure if departing from the boilerplate configurations).

Other standard options (but not tried): PHP/MySQL, node.js/mongoDB.

Usage: Management from the web dashboard; deployment with CLI local toolset (dotcloud). Pros: 1. The idea of boilerplate combinations (used both for pricing as well as for configurations) the only solution to go out from the one platform trap. 2. The dev playgrounds free indefinitely. Cons: 1. Very limited options to customize/go beyond the boilerplate options. 2. The local client not available/supported in Windows (can be deployed with Cygwin, but this is only a workaround).

7|Page

robert.komartin@gmail.com

03-Jan-2013

Version 2.0

Conclusions
After testing the 6 providers mentioned in the previous pages, we can draw the conclusion that there are a number of key decision points which lean the choice towards one provider or another (and no, the price is not one of them as the prices tend to be close and become even closer between the providers): a. The choice between long-term stability and being on the cutting edge of the technology: if looking for long-term stability (whatever that means in the todays web world), then leaning towards Microsoft (Azure) or Google might be a more reasonable choice, while if looking for the bleeding edge of features and performance then more focused providers such as Heroku or DotCloud might be a better choice. b. Typically, the vendors perform best in one layer with one or few technologies, struggling or at least employing some kind of workaround with the others. Therefore, the choice of the platform provider must be taken AFTER deciding the platform (entire stack: OS, web framework, programming language, etc.). Choosing in the opposite order would be as if we choose a duck for its abilities to swim in the nearby pond and then be disappointed for its lack of tree-climbing skills Thus, .NET screams for Azure, Ruby on Rails is longing for Heroku or Engine Yard, while Python seems to be at home with GAE or DotCloud, to (over-)simplify a bit the discussion. c. Last but not least, another tradeoff which needs to be done is between the need to achieve platform independence (but developing a lot from scratch) or being more closely tied to a platform (but then having a great deal of features already developed available in the platform). In the first case, the more natural choice would be toward Layer 0 or Layer 1 suppliers (AWS EC2 would be a typical example), while in the second case Layer 2 or Layer 3 (with GAE a typical case here) would be a better fit.

8|Page

robert.komartin@gmail.com