How to build your Killer SaaS Application?

Hello all!
Usually this blog focuses on QA methodologies, test processes, testing tools, platforms and QA best practices; but from time to time, we will also talk about related topics such as: technology, IT, SaaS (Software as a Service or On Demand solutions) and more.
Many people asked me what are the key things to keep in mind when developing a SaaS application. These are the main points that guide us when we build the PractiTest platform:

• Scale, Scale, and how to scale - that’s one of the main issues to think about BEFORE starting with any piece of code
  How can I make it scale?
  How much will it cost (per additional customer / project / server)?
  Will it add additional maintenance tasks?
  How can I make my servers Highly Available?
  What will happen if the platform will require more than one DB?I know that Agile development is all about how to start the development before you make too many design documents; and not starting and fixing things that aren’t broken yet (and maybe will never be!). So maybe I’m a little old-fashioned, but in my opinion to start and code before taking into account any ‘scale thinking’ is irresponsible. I think that regarding scaling we chose the middle way. Some examples:
  
  • We did not decide before writing the code what would be the indexes in the DB (for example), but when we create the tables, we put some relevant indexes, even when our DB is already working very fast.
  • We made sure that scaling can be achieved by adding relatively low cost machines.
  • We use opensource technologies to make sure scaling by adding machines will not require many $$$ for licensing.
  • We made our code ready for S3 (for file storage) if required, so we will not need to spend many bucks on storage solutions.
• Security – unlike traditional SW, where the DB is located on client’s premises, and all the communication is usually only inside the LAN of the organization, in the case of SaaS systems everything is over the web.
  Security is one of the most critical items, since you are storing and transmitting your clients’ data. Your code needs to forbid ANYONE IN ANY CASE to get or update data unless he’s identified as part of that specific account. The key here is strict standardization within your code.
  We built PractiTest in a way that even WE can’t manipulate or see any client’s data if we don’t have the required permissions.
  Before building any web application, I think anyone should learn about (and how to avoid) things like SQL Injection and Cross Site Scripting.In addition, security also means respecting the users’ privacy and sensitive data:
  • Hashing users’ password (MD5), before saving it to your DB.
  • Filter sensitive information from the default logs (credit-card info, password).
    Build it in a way that even you (or the system admin) will never be able to find users’ sensitive data.
  • Get an expert to try and manipulate your data.Special Tip for testers: try to find a user password on the DB or logs, or try to manipulate/get data that you’re not allowed to access, using http post or get. If you succeed it means there are issues with the product. These issues are showstoppers for every SaaS products, they are also important to fix in any SW product.

• Fast upgrades – SW upgrades shall not take more than few minutes. This should include DB & files backup, latest code version backup (in addition to version control), modifications to the DB schema (if required), upgrade of the code, and sanity testing.
  All the above should be automated. As a rule of thumb, the update should last no more than 10 minutes. If there is a failure, make sure you can rollback within 1 minute. Fast rollback is the main reason we backup DB, files, and code version, before we start the upgrade.
  As a SaaS solution you are expected to quickly solve every problem that may occur; also adding modules is something that you should be able to do easily.
  For example, in PractiTest, we usually do bi-weekly updates since we are adding features all the time.
• Make It Work Fast! The last thing your users (and ours) want is to wait (while you load your application). Actually some customers choose us mainly due to the fact that PractiTest works much faster than the products they used to run in-house.
  How could that be if they run it on their local network!? These are the things we keep in mind:
  • Small javascript files, small download pages.
  • We use only one JS framework. More than one can make the browser ‘become heavy’.
  • We make sure we have enough network capacity to support our clients.
  • We constantly check DB queries on production. Making sure all run fast.Our platform already works very fast for our clients, and this is even without (yet) things like:
  • Javascript and CSS compression (such as YUI Compressor or Packer)
  • Browser image cachingFor additional techniques you can look here: http://developer.yahoo.com/performance/rules.html
• No Installs for the clients – When you are developing a product that is installed on the customer’s premises, you can sometimes get away supporting only IE with an ActiveX based product. But as a SaaS your platform needs to support all main browser without instaling ANYTHING.
• Adjustments as needed – this is only one of the SaaS advantages – if there is a problem, fix it on the fly.

As I mentioned before, this is obviously a partial list of our key points. I mainly wrote what to do and not so much how to do it properly. If you want to know more about how to do it (or how we do it in PractiTest) drop me an email or post a comment.

http://qablog.practitest.com/2008/11/how-to-build-your-killer-saas-application/