archives –––––––– @btnaughton
Brian Naughton | Fri 30 January 2015 | company | website PaaS docker GAE

These days, I think it generally makes sense to put your website on some kind of PaaS (platform as a service) instead of hosting it yourself. That way, you don't have to worry so much about security patches, scaling, server uptime, etc.

I have tried a few PaaS before, but the space has evolved a lot recently, so I have been reviewing a bit to find the best choice for my needs.

I am looking for a PaaS that (a) is cheap to try out so I can get a quick idea of whether I like it; (b) is mature and supported long-term; (c) can run any random binary I might need (with which bioinformatics is lousy); (d) has support for Docker (just in case that becomes more of a standard); (e) is capable of running on its own hosted platform or my own AWS server.

S3

I am including S3 since I've used it for a bunch of websites, including this blog. It's great — it just sits there hosting your site and never breaking down. It's also super-cheap, in that you only pay for bandwidth, and it scales as much as you like. Of course, the catch is that there is no server, so everything has to be static. However, since you can upload to S3 from JS, static is not that static... It's also a great place to dump all your static files — there is no point having your webserver serve those.

Google App Engine

I think of GAE as being one level up from S3. GAE is a real pleasure to use, especially for small projects — I think more people should try it. Snapchat was built on top of GAE, and that seemed to work out ok. Generally, it's an awesome backend to a mobile app. As an example, I wrote a webapp on GAE that stores and retrieves images uploaded from a website: it is free, scales if I need it to, and it's only a hundred lines of Python code! Another free GAE instance I have handles tens of thousands of requests a day. The catch with GAE is that you don't have access to the server so you can't run whatever you want. Basically, you end up only running Python/Java/Go code you wrote yourself. The other catch is that you have to run your code in an unusual GAE-specific way to make it work efficiently. That's not so bad, except that this knowledge doesn't really translate to other platforms. You can now run GAE apps on Google Compute Engine, so it is becoming more flexible, but I haven't tried that.

Heroku

I once used heroku for a small experiment that GAE could not handle (it had to keep a connection open so it used gunicorn; I also needed ImageMagick). It was a nice experience — easy to set up and use and you could include add-ons like redis, sendgrid, etc by just clicking a button. You can run random binaries if you need them, but it's not officially supported. Heroku has a free tier but in general it's quite expensive. Heroku is probably the most popular PaaS, it's owned by VMWare so it's well-supported, and generally gets excellent reviews. The biggest problems are cost and lock-in: ideally, I'd like to be able to deploy the same website on AWS without heroku if I needed to (for example, let's say you needed your data to be stored in a HIPAA environment on AWS).

OpenShift

OpenShift is an interesting, new-ish PaaS. I hadn't heard of it before, and even though both are from RedHat, it is not really related to OpenStack (which is like an open-source AWS). OpenShift has a lot going for it: it's cheap to try out (you get three ''gears'' for free), it has pretty good support for Docker, it is open-source (as OpenShift Origin), and it's run by RedHat, a well-regarded, well-capitalized company. First impressions are good.

Elastic Beanstalk

Elastic Beanstalk is AWS' version of a PaaS. It's one of the thirty or so services you see when you log in to the AWS command center. It is not as friendly as a true PaaS: you can't click a button and have a redis instance just appear, for example. The big advantage of EB is that you're on AWS, so you know it's run properly, you have a lot of flexibility, and you benefit from easy integration with AWS' many other services (their push notification service is great, for example). However, for me, Elastic Beanstalk looks to be a bit too heavyweight. AWS is also pretty expensive to test out, especially if you've already used up your free micro instance like I have...

Azure websites

Microsoft's Azure cloud is actually pretty massive, even though I think of it as a new player. It's much bigger than Google's cloud business and second only to AWS. They have an AWS competitor, obviously, but they also have an interesting PaaS called Azure websites. Azure websites was a bit of a revelation: to create a flask-based website, you just click a couple of buttons. You can then quickly edit the code in your browser using Visual Studio Online(!), click "run" and there you have your own website that will scale up as much as you want. Even though it's a Microsoft product, it has support for Python, node.js, git, etc. Best of all, it's free for up to ten websites (assuming low bandwidth of course). Azure websites looks fantastic for simple websites or servers.

azure
azure

New-fangled Docker-y PaaS

Apparently, Docker-based PaaS is the "third wave" of PaaS. If it's anything like coffee, that will be a very good thing. The players here (Deis, Flynn, Tsuru, Dawn, Octohost, according to the linked article) seem to be pretty small and minimalist. This is more like roll-your-own PaaS, so it's too hands-on for me (Dawn is just a github repository). For now, these services are too immature for me, but it will be interesting to see if a new generation of PaaS really emerges.

So... OpenShift then?

The above list is just the PaaS I already knew about or thought might work for me. There are a bunch of other interesting ones out there like Stackato, dotCloud, Cloud Foundry, etc.

The PaaS that seems to best fit my criteria is OpenShift, so I'm going to try it out and see how it goes.

Comment

Boolean Biotech © Brian Naughton Powered by Pelican and Twitter Bootstrap. Icons by Font Awesome and Font Awesome More