SaaS multi-tenant application on PaaS Windows Azure : Where to Start?

The PaaS, Platform as a Service, allows to you develop and deploy rapidly applications in an Agile manner. Compares to IaaS (Infrastructure as a Service) it is far cheaper to operate once in production, since most of the complexity “behind the hood” is taken care of by Microsoft.

 

ASSUMPTION: This Post deals with multi-tenant Web applications. However, to ease the understanding and go straight to the essential point, I do not enter on purpose into the details of the multi-tenancy on the database side (well not too much). The iterative approach below will alow to consider Database aspects at the end. 

 

For having done multiple migrations and worked on Windows Azure PaaS projects, I wanted to present a rule of thumb when starting implementing the Windows Azure PaaS in a multi-tenancy web application.

The strength of the PaaS Windows Azure is that one could take an existing Web application (ASP.Net, but other technologies are supported) and literally migrate and publish it into the PaaS within 1 or 2 hours.

However, I often remind people that this is ONLY the beginning of the adventure and that as long as the web application is not available in Production environment with happy customers paying for it, then the job is not DONE YET!!

So where to start, when implementing (or migrating) a multi-tenant Web application for the PaaS Windows Azure?

My approach is based in DevOps, and I always “start by the end” where the most difficult and riskier elements are, which is the Production environment. Yes it is going to increase the bill sooner than expected but you will find quicker bugs that way.

So let’s stick to Lean principles “Think Big, act small, fail fast; learn rapidly”.

THE BIG picture is here and also below, where you don’t want to just deploy Web Roles within a Cloud Service, but in production you will consider all the Windows Azure “ingredients”, and start implementing them like pealing an onion: from the outside up until the inside (i.e. create a Subscription, a Region, a storage account, … in this EXCACT order).

Source of the document on the left: Microsoft.

 

Now let’s “act small” in the steps below.

 

OBJECTIVE 1 : MAKE YOUR APPLICATION AVAILABLE in the Cloud

1. In Visual Studio, open the solution containing your Web Application, and add a new project. Choose Cloud > Windows Azure Cloud Service (install any Azure SDK if needed when prompted)
   
   Either Add e new WebRole (and Edit the name as shown in the image below) or leave empty if you already have a WebRole (i.e. in our case an ASP.Net csproj).
   
2. Now you have a Cloud project suffixed by “.Azure” to distinguish it from the Web project, as highlighted in blue on the top of the image below.
   
3. NOW the FIRST thing to configure in this Cloud project is to protect your Azure Package from any missing files (DLL, stylesheet, …). Edit the property of the Cloud project, and choose “Treat warnings as error: True”
   It is VERY VERY VERY (did I say VERY ??) important and will spare you many hours of trouble shooting.
   
4. Still on the Cloud project, right click to create an Azure deployment Package “Package…” (you could tick the “Enable Remote Desktop for all roles”). If your application is great!! CONGRATULATION a BIG STEP is already crossed!
   The package will be composed of 2 files:
   * Cloud Service Configuration File (it is a Zip file that you can unzip, which contains other files, including another Zip)
   * Service Package file
   
   
   TIP: to prevent the problem “Yes, but it works on my machine”, create those 2 files from time to time. Indeed, even if your application builds and works on your machine, the generation of an Azure package (particularly with getting those 2 files with the option “Treat warnings as error: True”) adds extra checks to prevent you unnecessary upload files, start provisioning, and wait for a crash after 15 min! (remember, fail fast! Will cost you less in time and frustrations)
5. Now use Visual Studio 2013 to Publish your Cloud application.
   Note : Il it IMPORTANT to let VS doing so when you begin, because VS will be doing A LOT for you behind the scene (including the handling of any required certificates such as the RDP, the SSL, the Azure Management Certificate, … that is to be considered next). Then, later, we will see that you’d better off doing it more manually or with Powershell to better understand the working principles.

 

OBJECTIVE 2 : ENSURE YOUR ALLICATION IS ROBUST in the Cloud

1. To enforce the massive elasticity of the PaaS, Windows Azure PaaS does not authorize Load Balancing with “Sticky Sessions”. Now to ensure you have a true “Stateless” application, you will need to configure at least 2 instances in your Web Role (meaning at least 2 VMs in your web farm, but Azure uses the terms instances and Web Role).
   To do so, it is on the properties of the WebRole within the Roles of the Cloud project.
   
   
2. Start requesting SSL certificates (you’ll need *.cer and *.pfx), since it usually takes a long time to do so
3. Start requesting DNS usually a wildcard *.myGreatSaaSapplication.net so that each customer could have his own one, and all pointing to your same WebRole:
   - Client1.myGreatSaaSapplication.net
   - Client2.myGreatSaaSapplication.net
   - Client3.myGreatSaaSapplication.net
   - FreeTrial.myGreatSaaSapplication.net
4. Manually test your application and play long enough to identify:
   * performance issues (particularly true when considering PaaS Database, called Azure SQL Database, since it is a mutually shared resource, which enables far cheaper costs)
   * Sessions issues
   * Security issues (can Client1 see information of Client 2 ?)
   * Cost (particularly Outband, since VM is a predictable resource)
   * Is the Error handling working fine ?
   * (in the future with your database : is the EntLib Retrial Policy doing his job ?)
5. With Tools: Identify with tools flows in your application
   1. Performance: Load testing the Web application (eg. VS 2013 Ultimate)
   2. “Volume” tests : Use a Tool to populate massive data (VS 2013 Ultimate or Red Gate)
      Used to test performance, and see how robust your application can be once you have insert random data (i.e. your application should handle properly exceptions, since you will certainly perform import / export into your database one day or another !)
   3. Security : Perform intrusion tests (eg. Qualys free scan)
6. Add a DEBUG page on your web application to check:
   * which instance of the WebRole is hit
   * (and later the connection string)

OBJECTIVE 3 : ENSURE YOUR ALLICATION CAN OPERATE in the Cloud

1. Since you only have ONE codebase to lower the cost, you’ll need to know which client is using which feature and can access to which option.
   Start implementing ASAP tools that allows to do so. For the solution InishTech is based on tags that you add in your code (on methods, web service, …) and once in production, your Product Team and Marketing Team could define at the very last moment, what package should a customer access.
2. Start configuring and implementing operational indicators present natively in Windows Azure and through Application Insights for Visual Studio Online.

   

 

This article will evolve continuously et iteratively, so please provide feedback