What you likely missed in Bustle success story

You might recently read about the amazing success of Bustle, agency which using data-driven serverless setup scaled their magazine to 52 million monthly visitors. This story is indeed very encouraging, but if you aren’t up to date with trendy AWS / Serverless related topics you might miss some very important points.

To make use of that architecture, however, they have found it necessary to move beyond default configurations (especially for monitoring tasks) and have built some of their own open source tooling to complement and enhance AWS’ offering. But the payoff has been that once those configurations and tools are in place, engineers are spending less (if any) time on operational concerns.

One of the biggest benefits of serverless architecture is time saving. However, it’s saving time in processes, not in always in a launch. Quite mature, still a new concept isn’t tooled with solutions to all problems yet. It means your team can focus on building and maintaining logic when platform provider takes mostly responsibility for scalability, uptime and performance.

“We had many services that we were managing, it felt like it was just one node server after another, so we very quickly started moving servers over to API Gateway and Lambda when it became available. As soon as they released it, we were getting value out of it.”

The previous benefit translated directly to money. In early days of ServerLess project (former JAWS) their founders presented very interesting calculation:

“Scenario 16000 request/day @ 200ms avg = 3,200,00ms/day
Two EC2 Instances, 1yr upfront reserved $2.97/day
Lambda 1048mb $0.05/day”

I wrote some basic roundup for that technology in the past: Roundup — is serverless worth trying

With the core infrastructure now operating on the AWS platform, Love’s team wanted to test whether they could go even one step further and manage a user-facing product completely in a serverless environment. While Bustle was operating on AWS, there were still a number of DevOps tasks involved in production. With the upcoming release of Romper title planned, Tyler’s team was asking, could they make a user-facing site with all of the complex constraints required: Could they still ensure search engine optimization, ensure bots and crawlers could access the site, could they set response headers, handle 301 redirects, and set location dynamically, all in a serverless environment?

It is 2016 and most of the crawlers will be able to read frontend composed web pages. Anyhow, if you’d like to go for AMP (Accelerated Mobile Pages) and are afraid of JavaScript frontend errors affecting crawl ability, I can suggest a different solution. At Skarina.com, what we decided to do is different — we divided important publishing content and add-ons. Add-ons are provided via tag manager. The main content is served as precompiled static files on CDN. That allows response time that no frontend app can achieve and we believe it would affect overall indexing results.

In the end serverless it’s not only AWS stack. Other providers also build up similar solutions like Azure Functions or Google CloudFunctions. In short what you mainly gain is:

- limit long-term cost of devOps
- enable infinite scaling
- build very low entry cost for infrastructure (development can cost you actually more)

Show your support

Clapping shows how much you appreciated Lukasz Sielski’s story.