Choosing a PaaS
If you are new to this whole cloud deployment thing, do read this simple and accessible primer on cloud computing to get used to the basic concepts and use cases for the cloud.
If you are a fledgling developer looking to spread your wings and take to the sky, the insane plethora of PaaS cloud hosting services available today is a godsend. It’s a new gold rush and everyone’s trying to sell the shovels. Indeed, there hasn’t been a better time for us to create applications and reach users from all over the world. It’s simply amazing when you think about the power you can wield today.
However the sheer number of choices can be overwhelming the first time you try. I’ve been there. And the analysis paralysis might save you; having your application locked-in to the wrong platform is no joke. Treat it like you’re buying a house, not a cute tablet.
Pretty much everyone has done some post detailing comparisons between the major vendors and a few(?) other sponsored listings ($$$). There’s no point doing that myself (feel free to contact me for endor$ement$ though), so instead we should learn what to look out for when making our own self-informed choices.
Available Runtimes and Frameworks
This is obvious. If the service doesn’t support your application’s technology stack at all, then you can’t do anything. If you use the popular Ruby|Node |Python|PHP|Java|etc. types then you don’t really have to worry about this.
Very important. You have to make a judgement call on whether you will get your money’s worth of value when choosing a PaaS.
The pricing models and cost structures of many offerings today can get confusing, but in general they fall under two categories; fixed costs and metered usage. There’s the occasional free offerings as well, but you don’t want them for your important applications. Major providers like Google Cloud Platform provide tools like cost calculators; use them.
This is one of the main pulls of cloud hosting: abstracting away the fiddly infrastructure bits. Scaling often happens automatically at the PaaS level, and most providers today cover both horizontal (number of instances) and vertical (memory and cpu) scaling.
Make sure you have some control over this aspect; if your app tops hacker news when you’re asleep and you get a massive burst of traffic, your app might either fail or the automatic scaling and metered pricing will happily pick up the slack at your expense.
Tools and Services
Many PaaS providers offer some form of monitoring, analytics, or other tools to manage your application deployment. Integration with external services you use would also make life a lot easier.
The developer control panel or dashboard is also something you will use a lot, so a powerful administrative portal is a genuine plus for small developers.
Not just downtime; consider the company’s long term viability and support for the PaaS. This doesn’t matter as much for small temporary projects, but larger business projects cannot afford to fall like this. It’s tempting to jump on the latest and greatest, but only risk what you can afford to lose.
The main objective of a Service Level Agreement (SLA) is to clearly define relationships and set expectations for adequate service levels between the buyer and the seller. Take time to read and understand the SLA from your PaaS of choice; it will keep you informed of your rights and legal expectations.
There are many more aspects to consider when choosing a PaaS to deploy your business/application, but these are the few common and important ones. Try them all if you want, but when it’s time to choose one for a major project, make sure you inform yourself before proceeding.
Here’s a fun little website —www.paasify.it
It uses forms to narrow down your needs and returns a list of candidates fitting your requirements. While it isn’t a substitute for proper evaluation, it can quickly point you in the right direction.