How Bustle Uses a Serverless Architecture to Manage 52 Million Monthly Visitors – InApps Technology 2022

Established tech companies are starting to look at migrating their production environments to serverless architectures.

Case in point: Bustle. This media company currently publishes two websites — Bustle (aimed at millennial women) and the newly-launched Romper (aimed at millennial parents, particularly millennial mothers) — and has a combined and growing audience of 52 million-plus monthly visitors, according to web data company, SimilarWeb.

A modern media site with this audience size requires a data-driven architecture that can integrate with social media, analyze trending and shared content in real time, and report findings back to editors, writers and advertisers. Bustle CTO Tyler Love said that means having around 12 APIs in production use. It would be more, but Bustle has moved to GraphQL and deprecated many of its internal APIs in that process.

With these APIs, the company can collect and analyze the data of over 100 million events that occur each day, often splitting analysis by device, as session experience differs significantly depending on how the reader is consuming Bustle’s content.

Love’s focus as CTO is on ensuring the site can continue to scale, while reducing the operational complexity for engineers, helping teams keep the focus on the content products, and facilitating editorial’s use of data to understand how readers engage. That’s where serverless is bringing the greatest advantage: data insights are sped up so that the editorial team can better respond in real time to trends they are seeing in reader engagement.

For Love, serverless is already sufficiently matured to be trusted in production environments at scale. 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.

While an early adopter of AWS Lambda, it was the combination of two of AWS’ other products — Kinesis and API Gateway — that together allowed Bustle to migrate their complete production environments to serverless.

“We’re Ruby and JavaScript developers, so we had a Java app, and it kept growing in complexity,” explained Love. “Two years ago when we first got access to Lambda, we were able to start processing the Kinesis feed, and we prototyped something in a couple of days for Re:Invent [Amazon’s yearly user conference]. At that stage, we had a couple of instances running in production, and autoscaling this stuff was something we didn’t want to take on managing in the longer term. So when AWS announced API Gateway, that really caught our eye. We thought we don’t have to manage our Rails servers … complexity was already increasing because of all of these self-managed node instances,” Love said.

“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.”

When Production is Deployed to Serverless

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?

The new site — a JavaScript single page using AWS ElastiCache — was built to scale efficiently and was launched right on top of AWS API Gateway. “It worked as a great testbed for how we can migrate Bustle to this same architecture,” said Love.

Love said that with 2 to 3 million unique visitors a day, as the Bustle media product was being built out, there was little space for guesswork when implementing new initiatives.

“On any given day, we collect 100 million events that are all sent up to an API gateway endpoint,” said Love. “Those are processed by a Lambda function, cleaned into normalized events (for example, the server sets timestamps, user agent information, and adds device segmentation), and then written to a Kinesis stream. Then consumers of the Kinesis stream can see real-time raw counts and aggregates of content in Redis.:

“We are doing a ton of increments and decrements to render time series in Redis,” Love explained. “Now, you can more or less do that with Kinesis, which deprecates the need for Redis and that is something we will be rolling over to. We have done a couple of experiments with it, and it really simplifies it for us.”

One of the key architectural components that has been changed with the migration to serverless is a removal of DevOps processes that respond to sudden increases in readership when content goes viral unexpectedly.

“Before serverless, if a threshold is reached, then the developer is alerted. They need to know that we have to monitor the service, and alert editorial — usually via a slack notification — so that they can very quickly react to the breaking news,” explained Love. “In the past, we had a lot of monitoring in place, but now with a serverless environment, we are integrating with CloudWatch to set the frequency of events and thresholds. Because we are in this environment, we don’t do anything to manage the alerts; we just have to configure it once.”

Software engineer Zahra Jabini has been leading the migration to serverless for Bustle. This primarily involved rewriting the front-end app in Ember.js. While the previous infrastructure used Ember as well, Jabini says that it was easier to do a complete refresh that could talk to the newer implementation of GraphQL and allowed the team to incrementally move parts of the backend to Lambda “without having to do a big-bang rewrite” of backend code.

“I would say that the cool thing with our client-side architecture, is that we deploy our app once at the [content delivery network, or CDN] and users download it. We deploy it once, and Amazon runs it as many times as needed. So, for a site like ours, we can focus on building really cool products, not having to worry about our site crashing,” said Jabini.

Love gives one example of the type of media feature that makes Bustle so popular amongst its readership: “A good example is our flowcharts. They are an example of what an editor and designer can do by working together. So based just on keeping some layer naming conventions, it shows what can be done with panning and viewing in an SVG. How can we create a premium product that will engage readers and that brands will be impressed by? By doing something that was really cool that we could trick the browser to do, we ended up designing a whole [content management system] so that an editor and writer can conceptualize a flowchart in a day and two.”

By moving to serverless, Bustle has avoided the monolith. It is not just large enterprise that faces the technical debt of legacy systems. By the time a rapid growing startup reaches the scale-up stage, it often is in a situation where the engineering teams end up actually having to say no to any suggestions for feature enhancements, as already the startup is now dealing with a cumbersome, large code base. The usual route to solve this is for a startup to move their newly created monolith into a microservices architecture then.

But by building on serverless architecture elements such as Lambda since its early days, Bustle has been able to avoid that common trap. “We work really closely with our designers: they would give us what they would want us to build and their vision, and we wouldn’t have to say no to them,” said Jabini. “It let us incrementally improve the application without anyone worrying about diving into the huge source code that you get with monoliths.” Jabini also points to a string open source culture within the organization that has also meant that engineers take personal responsibility for making sure that anything they are building is well-documented.

The Business Advantages of Serverless

Love says that the new serverless architecture has had huge ramifications for the business side of Bustle. Particularly in making data available in an easy-to-use form so that various business units can conduct their own analysis and build their own dashboards and tools to review better what is happening in real time with reader engagement.

This starts with the Kinesis Firehose, which processes events from Kinesis feeds in real time and writes them to AWS Simple Storage Service (S3) where they are then able to be analyzed in ElastiSearch or AWS’ data warehouse service, RedShift.

“Firehose solved a lot of problems,” said Love. “Now we have a data store that we can easily scale and do quite a bit of analysis on. Any database data analyst can access this. As the site grew and our content inventory grew, and ad revenue needs grew, we want to use our product to engage with the user better.

Using serverless, we have integrated these event feeds into our data warehousing and without thinking about how we scale, we analyze how many stories are scrolled through each day, and what types of stories get recirculation. Doing clickbait is one thing, but we like to ask what is happening over the duration of the session? Do we market content that is actually more engaging?”

Love says what is really interesting here is that no one is doing operations, everyone has an understanding of how Lambda works and best practices in writing to databases. Marketing can now put a cost-per-impression on every story right down to the cent, engineers can use that to sort the stories algorithmically, product engineers are now having conversations that are informed by the events.

“Anyone is able to quickly build dashboards, often with very little engineering work. We are able to train less technically savvy data analysts and marketing people to make sense of this data,” said Love.

Love said that as a result when a new media product or content type is launched, the product team can see how readers engage with it, make some changes, and “then kind of walk away from it.” Product enhancement becomes about identifying the low hanging fruit through the data and then improving the overall experience, which often dramatically improved within a few weeks. Love points to the improved slideshow media type as an example of how data has informed and improved the reader experience within a matter of weeks, now requiring little if any further tinkering.

Inspiring an Ecosystem

The Bustle engineering team have created several toolsets in-house to help speed up their workflow in the new serverless environments. One open source project, Shep, is a framework for building APIs using AWS API Gateway and Lambda. The team also created a CLI tool to run Ember-based applications in Lambda, using Fastboot.

“The CLI lets you create endpoints in Gateway without using the console, which can be a bit more tedious, especially when you are creating a number of APIs, and with Shep you can manage them consistently in one way,” said Love. Other in-house tools include a tool to prototype something and get it into API gateway quickly.

“We want to be building tools so that writers and editors can build engaging content without knowing how to code,” said Love.

The ability to manage the size of the Bustle (and Romper) audience is a good indication of the sturdy foundation that serverless architecture is demonstrating. The amount of processing of event data in near to real-time, with NoOps being required to manage rapid scaling when there is a sudden increase in traffic, also bodes well for the potential of serverless in managing Internet of Things applications.

To learn more about serverless technologies, check out our new “TNS Guide to Serverless Technologies: The Best of FaaS and BaaS.”

Feature image: “88/365 outtake1” by thelittleone417. Licensed under CC BY SA-2.0.