Comparing SaaS Cloud apps hosting and provisioning options

Categories Development, Working smart

This is what popped up while going through a thought experiment on choosing hosting and provisioning for the development of a new Software as a Service offering.

The options considered are:

  • PaaS with multi-tenancy – use a PaaS offering (think Cloud FoundryHeroku, Google App Engine and Windows Azure Compute) to host a multi-tenant system. Provisioning for a new client is zero-cost done inside the system
  • PaaS with one environment per client – use a PaaS offering (think  Cloud FoundryHeroku, Google App Engine and Windows Azure Compute) to host a regularly developed system. Provisioning for a new client means configuring a new PaaS environment, adding an instance and deploying
  • IaaS with multi-tenancy – use an IaaS offering (think Amazon EC2 or Windows Azure Virtual Machines) to run a stack of Virtual Machines configured to run your platform of choice, hosting a clustered multi-tenant application. Provisioning is zero-cost after initial setup
  • IaaS with one stack per client – use an IaaS offering (think Amazon EC2 or Windows Azure Virtual Machines) to run one stack of Virtual Machines configured to run your platform of choice, hosting a clustered (or not) regularly developed application for each client. Provisioning means creating stacks, adding virtual machines, installing OS, DB, platform and deploying application

For convenience I also added a category called UGLY, just to highlight what I consider to be the worst point of each option.

SaaS

Over PaaS with multi-tenancy

Over PaaS with one environment per client

Over IaaS with multi-tenancy

Over IaaS with one stack per client

GOOD

  • Application must comply with platform constraints
  • One version for all clients
  • Single location deployment
  • Automatic scaling
  • Simpler, faster provisioning
  • Simple monitoring at the application level
  • Looks cheaper, pay by CPU-time and resource usage
  • Application must comply with platform constraints
  • Allows for multiple versions at the same time for different clients (even deep customization)
  • Automatic scaling
  • Simpler provisioning
  • More control in choosing platform and technologies
  • One version for all clients
  • Can use farm-deployment for single location deployment
  • Simpler, faster provisioning
  • Simple monitoring at the application level
  • More control in choosing platform and technologies
  • Allows for multiple versions at the same time for different clients

BAD

  • Application must comply with platform constraints
  • One version for all clients
  • Application has to know about multi-tenancy – it should be designed to support it
  • Application must comply with platform constraints
  • Must have tight configuration management to handle different versions for different clients
  • Provisioning may be slower, depending on instance creation speed
  • Complex monitoring
  • Must handle horizontal and vertical scaling
  • One version for all clients
  • Increase in deployment architecture complexity
  • Must handle clustering and state
  • Application has to know about multi-tenancy – it should be designed to support it
  • Must handle horizontal and vertical scaling
  • Must have tight configuration management to handle different versions for different clients
  • Must handle different deployments and deployment scenarios
  • Complex monitoring

UGLY

  • Platform may enforce application architecture and technologies
  • Platform may enforce application architecture and technologies
  • Must manage operating system, storage and database configurations
  • Must manage multiple, possibly different operating systems, storage and database configurations

 

Some points are good and bad simultaneously. Examples:

  • Application must comply with platform constraints – which means that you can’t always do what you want to do, producing
    • GOOD – sometimes enforces good coding and resource-usage conventions
    • BAD – more effort in developing exotic things
  • One version for all clients – there can only be one version in production
    • GOOD – less versions to worry about, less things to manage
    • BAD – you may upgrade users that want the old version or you may have some users that want deep customizations and that are willing to pay for them

The overall conclusion is that the higher you go, the less you have to manage, the cheaper it gets.

For another good read you can check out the PaaS vs IaaS comparison on http://www.engineyard.com/paas-vs-iaas.

Leave a Reply

Your email address will not be published. Required fields are marked *