Serverlesscode has been running smoothly on Aerobatic since my switch last month. Aerobatic is a static hosting provider aimed (currently) at Bitbucket users, integrating as a Bitbucket add-on for continuous delivery from your git repo to hosting. In addition to CI, Aerobatic provides free SSL certificates, supports Jekyll and Hugo static site generators out of the box, allows custom domains, and handles asset versioning automatically.
I had the opportunity to sit down with David Von Lehman from the Aerobatic team and ask about running a business on open-source, where the idea for Aerobatic came from, and monitoring Lambda infrastructure.
The Interview
A little over 2 years. At the time I was doing a lot of work on single page web apps with Angular and Heroku. It struck me as a waste of dedicated server resources to simply serve up static JavaScript files that execute in the browser. Aerobatic was born out of the idea that modern web apps could be served from a multi-tenant server platform that provides not only the foundational static hosting capabilities (with CDN, proper caching headers, etc), but also a suite of common services on the server to complement client apps such as http-proxying and auth. We like to think of ourselves as a serverless solution for the front-end. Since we got started the serverless backend has really taken hold with Lambda and API Gateway. We think a front-end on Aerobatic makes for an ideal complement to a serverless API backend.
Originally the product was very much focused on single page apps but we’ve since generalized to support any sort of static website with a special focus on static site generators such as Jekyll and Hugo. Most recently we’ve built out a continuous deployment pipeline based on AWS Lambda that builds the static site for you. This has a couple of great benefits: first it avoids the need to commit the built assets to git, and second it enables a streamlined editing workflow where you edit/commit files directly in Bitbucket triggering a new build/deployment. For changes like simple updates to a markdown file, this is much more efficient than the typical pull -> open editor -> make changes -> commit -> push flow. It also opens the door to allowing less technical contributors manage the contents of a static site without having to engage the whole developer toolchain.
We recognize that editing markdown files in Bitbucket is still far from ideal as a CMS, so we are looking at providing a more WordPress like editing experience. Ultimately we think the combination of static site generators, Git, continuous delivery, and highly scalable/performant static cloud hosting is a superior technical stack to the traditional CMS. The challenge is evolving the tooling, the eco-system, and most importantly mindsets for this new paradigm to really take hold. Obviously this is a pretty big deal when WordPress enjoys such an entrenched position in the market.
Considering that so much of our product is gluing together a bunch of open-source building blocks, it only seemed fit that we open-source ourselves. As you mentioned most of the core aspects are packaged up as a collection of Node modules under the 4front umbrella. In a nutshell, our multi-tenant hosting service is an abstraction layer atop Express. The non open-source bits that make up Aerobatic are mostly about adapting 4front to work in close conjunction with Bitbucket.
I’d guesstimate 80/20 open-source to proprietary.
Our server code is all Node and runs on AWS. The hosting layer is a Node app that wraps Express and runs on Elastic Beanstalk. We use DynamoDB to store website metadata like versions, settings, etc. Deployed website assets are stored on S3. Every custom domain is fronted by a dedicated CloudFront CDN distribution that also hosts the domain’s wildcard SSL certificate. Our continuous deployment pipeline is all Lambda functions which you can read more about here. We also use Redis for caching a variety of things. Our front-end is a React web app that runs in an iframe within Bitbucket as an add-on.
I had not written a product exactly like 4front/Aerobatic before, but I had certainly built a lot of web applications both in Node/Express and earlier in my career ASP.Net. Over the years I’ve built up a solid understanding of the fundamental building blocks of the web: the HTTP protocol, how browsers work, HTML, JavaScript, and so on. I definitely consider myself a devoted “web guy.”
One learning is that the web is a big place and things don’t change nearly as fast as one might be led to believe by following trendsetters on Twitter. Like I mentioned earlier, we originally focused on modern SPAs written in Angular, Ember, React, etc. Turns out this is still a pretty niche use case in the grand scheme of things. For example there’s far more traditional page-based websites, perhaps augmented with a bit of jQuery than full-on single page apps.
One of the great things about static sites though, is it’s returning to the way things worked before the majority of websites entailed executing custom code on the server with each page request. The static approach has been with us all along, there’s just been a recognition of late that static happens to play really nicely with modern trends such as global content distribution, separation of backend and front-end, and taking advantage of modern browser capabilities. At the end of the day it doesn’t matter if a website is basic HTML and CSS pages or a highly sophisticated API driven React/Redux web app, it’s all the same to a static host like Aerobatic.
For our main platform we have a continuous deployment workflow using Codeship and Bitbucket. Code is either committed directly to master or merged from a feature branch. This fires a web hook to Codeship which runs the unit tests and deploys to Elastic Beanstalk. Elastic Beanstalk automatically takes care of rotating servers in and out and ensuring everything passes health checks along the way. The open-source 4front modules each have a dedicated GitHub repository configured for continuous integration with TravisCI and Coveralls.
This is an area that is still evolving. Lambda functions log to CloudWatch by default which is nice in that there’s nothing to manage, but the interface is not terribly friendly for searching and monitoring. We also log to Papertrail which has much better search functionality and also allows saved searches that can trigger alarms that are emailed or sent via webhook to other systems like Slack. Our plan is to implement custom CloudWatch metrics and a CloudWatch dashboard to get a single pane of glass with all the most valuable monitoring info.
In general our philosophy is to use AWS provided services wherever possible to simplify our operating model. They might not always have the very best offering on the market, but there’s a lot to be said for having everything in one console and not have to juggle a bunch of different tools. That said, there are instances where external offerings are worth it, such as with Codeship and Papertrail. And it goes without saying that we highly recommend Aerobatic for all the benefits it provides over rolling it yourself with S3.
Right now testing happens on the developer’s machine since we’re still very small and can get away with it. Eventually we’ll upgrade to a proper staging environment on AWS that mirrors the production environment. Bitbucket has a pretty slick setup for testing add-ons locally using a tool called ngrok which provides a localhost tunnel that allows a developer machine to be reached over the network by Bitbucket.
We have several agency customers that are building static sites on behalf of clients that love how Aerobatic fits right into their development workflow. The ability to use staging branches with basic auth provides a streamlined way to share in-progress work and getting approvals. Promoting to production is a simple git merge. We see a lot of startups using us for their marketing websites. Then there’s a bunch of developers running their blogs with us just like this one.
Right now we are very much at the technical end of the spectrum, but by introducing more CMS style features, we intend to make the case for more websites to be built statically that would otherwise go the WordPress route. And of course Aerobatic also works great for SPAs. I wouldn’t say we’ve narrowed our focus to a specific market at this point.
I can’t say enough about Lambda, it’s really a game changer in my mind. You can already see how it’s changing the way we think about architecting systems. Our continuous deployment pipeline would have been a much greater undertaking had we built it from scratch using Docker. Lambda has proven extremely reliable and the time it takes the S3 event source to trigger the function is amazingly fast and consistent. Some of the things we learned along the way working with Lambda include:
- Important to understand the lifecycle of function instances and how they are sometimes brand new and sometime reused.
- Robust logging is imperative, especially early on when still ironing out the kinks.
- It’s important to have a test harness to be able to run and debug functions locally.
- Automate deployments - we use a gulp script.
There’s a nascent ecosystem of tooling right now, but I expect this will only continue to grow and improve. Google just announced their Cloud Functions feature, so it’s great to see more choices in the market for serverless computing.
Wrapping Up
Thanks for reading! If you have a need for hosting a static blog or single-page app, give Aerobatic a spin.
Keep up with future posts via RSS. If you have suggestions, questions, or comments feel free to email ryan@serverlesscode.com .
Disclosure: I use Aerobatic to host this site, and received no compensation for either this interview or my earlier product review.