Before you PaaS out

PaaS is really such a great option for building a global, enterprise grade web applicaiton, without worrying about the riskier propositions such as 24-7 availability, automated backups and failover, automatic scaling as demand increases…

It almost sounds too good to be true. The good news is that if you are building a cloud-first app, most of the above IS true and works as advertised. The bad news is that you can rarely, if at all, utilize these great options for an existing web app, no matter how modern your current stack may be. For example, you may already be leveraging Windows Identity Framework, tokenizing authentication and access; however, it may still not work on Azure Websites (Azure’s PaaS offering) for reasons that will be discussed in this article.

The first thing to understand is that PaaS and all PaaS constucts are – volatile.

PaaS is Volatile

Volatility means that resource locations, uptimes, even their very existence are not guaranteed (okay, mainly the location…). This means that your application needs to plan data storage accordingly; For e.g.

• If your application utilizes temporary file storage, you may not be assured of a file system that is not transient in nature. Fortunately, Azure File Storage is a service that solves exactly this problem.
• For in-memory storage (session data, configuration data etc), once again, you are not guaranteed the memory on your server instance. Instead, you need to use Redis cache (or memcache), which provides you with for in-memory storage.

Of course, you should be moving away from session storage altogether and try building stateless apps. MVC, REST and modern app stack technologies are already edging out the need for storing session data, and this trend is expected to continue.

PaaS is Inaccessible (for the most part)

Developers and production support folks are used to logging on to their servers. This can be for routine maintenance or for troubleshooting an issue. RDP (Windows) and SSH (putty) access are common, and de-facto server access methods.

Not so with PaaS. There is typically no access to the underlying VM. This means that your applications need to be extra diligent about logging exceptions and handling errors.

The PaaS meter is always running

As you are well aware, on the cloud you get billed for usage (just like your electric utility bill). Some charges that almost always take users by surprise include:

• Data Transfer Charges: Data transfer between regions and zones is not free. The cost impact of a high availability, fault-tolerant architecture that replicates data to different locations, can add up significantly.
• Charges vary according to what services you use; for e.g. while cloud load balancers are ideal for highly available apps, they work based on DNS Query resolution. As you guessed, you are billed per million DNS queries. Also, depending on how many service endpoints your application uses, the ‘health check’ of each endpoint is billed separately.

It is usually IaaS ‘didn’t expect it’ charges that surprise consumers (I switched off my VM, why was I still getting billed…..?) , there are some subtle charges in the PaaS world too. In the cloud, the meter is always running on your services and instances.

Summary (You ought to PaaS out Anyway!)

None of this is to imply that you shouldn’t be using PaaS. With global Content Delivery, multi region high-availability and smart load balancing (Azure Traffic Manager, AWS ELB+Route53…), some of your application’s biggest pain points are already addressed by the cloud platform. In addition, you do not have to worry about securing the infrastructure, patching, updating or any of those mundane tasks that require an entire support team.

So, while your existing web-application may not be cloud-ready, it does make sense to at least start refactoring in that direction (start eliminating session variables, start using a File Storage Service instead of local filesystem storage…..).

Once your refactoring is complete, it is fairly straightforward to deploy onto your favorite PaaS web platform (Azure Websites, Google App Engine, AWS Beanstalk…), and test out it’s PaaS compatibility.

Thoughts? Questions? Comments? Have you built a truly global PaaS app?