During the last weeks and month I had the opportunity to get an idea how different companies (Start-Ups and existing player) realized their software as a service offerings. In a series of blogs posts I would like to share technical ideas and best practices to realize similar projects. Let’s start with a couple of assumptions:

• Most software as a service offerings are web based applications based on HTML, CSS and JavaScript (I will call them HTML5 apps)
• Most software as a service offerings are using a specific web framework which is responsible for rendering the application, e.g. PHP, Ruby on Rails or ASP.NET MVC
• Most software as a service offerings are implementing a multitenant ready backend (shared or isolated data storage)
• Most software as a service offerings want to follow the paradigm “pay as you go” for their infrastructure

In the first part of this blog series I would like to focus on the “pay as you go” paradigm, which allows to scale out  your infrastructure just as you need (and of course to shrink if necessary) – be elastic 🙂

Traditional Web-Application-Architecture

The good news is, many web applications are following the same main architecture shown below:

The system offers a storage backend for relational data (SQL or NO-SQL Database) and a way to store mass data (files, attachents, photos,….). On top of the storage backend the web worker is responsible for processing all user request in the system (complex applications have also background worker, of course). The load-balancer in front of the system delegates requests to the next free worker server.

Step a way from this picture and think about the requirements we have on the different roles and layers of our system:

• Storage Backend
  • Highly Available
  • Reliable with support for backup and restore mechanisms
  • Fast / Reactive
• Web-Worker (Computer Nodes)
  • Independent from each other
  • High processing rate
  • Stateless
• Load-Balancer
  • SSL Manager
  • Highly Available

The components of an Infrastructure as a Service Provider

Today, Amazon AWS is not the exclusive IaaS provider but is one with a sophisticated infrastructure. I’m using Amazon AWS in these articles because you have the option to try it out for free, right now. Amazon offers a Free-Tier-Program for all new customers without any fee.

Let’s have a look what Amazon offers:

• Storage Backend
  • Amazon S3 – A highly scalable and distributed storage system for mass data, which allows storing nearly everything behind a unique key. Every element is accessible through a RESTful web service.
  • Amazon RDS – To make it simple, it’s MySQL for the Cloud. Amazon offers a multi site, sharded database system, which allows to create as many databases as you need.
• Web-Worker
  • Amazon EC2 – The elastic cloud (EC2) allows to get virtual machines on demand as needed. This machines are provisioned based on an existing AMI (Amazone Machine Image) and will be provided immediately.
  • Amazon AutoScaling – The AutoScaling service allows to add new EC2 nodes into your cluster automatically and of course to reduce the amount of cluster of necessary –  be elastic J
• Load Balancer
  • Amazon ELB – The Elastic Load Balancer is responsible for receiving all HTTP(S) request and redirects the request to a free node in the cluster. The ELB is also highly integrated in the AutoScaling service so  if needed the cluster behind the ELB can be expanded automatically.

Recap for our Web-Application-Architecture

With the new knowledge about the different components it’s easy to generate a new picture of the system (and I know there are many other ways to realize a solution but for me personally this solutions fits best):

And now?

In the next parts of this series I would like to cover some more detailed topics, e.g.

• Build a Ruby on Rails application which relies on Amazon S3 and Amazon RDS as backend storage system
• Bake an AMI for the EC2 nodes and handle the application deployment and upgrade scenarios
• Rolling out a primary infrastructure with a minimum set on servers, load balancers and storage backends
• Implement AutoScaling in detail to handle the first customer storm J
• Calculate the CAPEX and OPEX for a SaaS offering