Serverless Smart Radio

You are currently reading part I of the Serverless Smart Radio series. In this article, I will be mainly talking about how and why we aim to be serverless, the Smart Radio Project, walk you through the components of our system, and talk about the systems we use within AWS.

What’s Smart Radio ?

Smart radio is an on-demand personalised audio delivery platform. A common radio system is a linear broadcast of audio, the same for each listener. Via Smart Radio you can select the topics you want to be informed on, then we deliver you a personalized stream of audio segments based on these preferences.

Why Serverless Smart Radio?

Our radio app is quite popular which means we need to handle a lot of requests via our audio API.
We are a team of data scientists and I am the only engineer thus, we aim to do minimum devops and maintenance. We like to build more features for our users.
We would like to iterate on our workflows quickly, try out different versions, connect more services
Automate infrastructure as much as possible so that we can also scale up and down our processing service without any commitment (i) no containers are running after the live radio stream ends (ii) start more containers when more audio files needs to be processed.
No need to re-invent the wheel and let the AWS do the heavy lifting for us by using AWS services such as unlimited storage(s3), transactional databases(RDS), event streams(Kinesis) and many more.

Why Serverless ?

Challenge

Managing servers and infrastructure is a time-consuming job and requires special personnel to maintain the system hence costs lots of money, time and headache. Simply leaving the server management to the service provider, developers and businesses can focus on their main thing; building features .

Goals

Reliability
Scalability
Maintainability
Cost Effectiveness

In this series of posts we will be going through each of these fundamentals and explain how the serverless architecture help us to achieve these concerns successfully.

Serverless vs Serverless

The term serverless has been used with multiple meanings. There is a serverless framework, and it is used to indicate the Backend as a Service (BaaS), also used for the Function as a Service(FaaS)

We like to think of Serverless as the general attitude towards a system that does not require a dedicated or virtual machine and benefit from all the available managed services from the cloud provider.

In addition to infrastructure management, implementing auto scalable software is not an easy task and requires careful consideration of every piece of the system and a lot of infrastructure coding.

By also leveraging the service provider’s thousands of machines, you also decrease the chance of server faults per machine in addition to auto-retry functionality in case of failures.

The software industry is in the following progress in terms of infrastructure evolution

Physical servers-> Virtual servers-> Containers -> PaaS -> Serverless

Heroku as a serverless cloud application provider (PaaS) has helped many startups to kick off their applications as soon as possible and scaling up and down with simple commands and adding more services using the tool chain around their ecosystem such as queues, databases, etc. However not having an account in a cloud provider has its downsides, thus making it hard to transition from one to another or to your own infrastructure.

We think serverless is the evolution in the right direction. Designing your services based on small pieces of functions that are tied together from the start also helps you with managing the overall complexity of the software development process. We will be going into more details in Part II — Lambda Functions and Part V — Clojure

In essence, serverless is more thinking about your users, thinking about functionality, applications and rather than constantly thinking/worrying about servers. Most software projects hit major slowdowns after the initial release, just because there is simply much more to consider.

The goal is;

No provisioning, no operating system to patch/maintain etc…
Auto-scaling
Pay per use
Increased development speed
Maximum automation
Event driven
Nimble components

As the golden rule, a serverless architecture is also not the silver bullet. As you will see in the following sections, we still need containers to do the jobs that are not very suitable for serverless approach such as;

dealing with large files
higher hardware resource requirements
high traffic loads; cases where having containers will be more cost efficient.

We are still operating in a serverless infrastructure, meaning we have zero EC2 instances that are in our management. The containers that are initialised in AWS ECS service is managed by the AWS Fargate system.

Who we are ?

FD Media group(FDMG) is based in The Netherlands. FDMG operates “Het Financieele Dagblad” (FD) a daily financial newspaper, similar to The Financial Time s. In addition, FDMG operates the daily all-news radio station “Business News Radio” (BNR). We are a team of four data scientists and me as a data engineer, work on the Google DNI-funded “SMART Journalism” and “SMART Radio” projects, which revolve around personalisation, summarisation, and recommendation of news and (snippets of) radio.

These two projects are partly funded by the Google DNI (Digital News Initiative) details can be found here and here

Smart Radio is the non-linear radio experience that is fine-tuned to our readers.

Let’s get into more details about the Smart Radio project.

How it is made ?

In the Smart Radio project, our system receives the last hour’s recording of the live radio stream, and starts processing the audio file. It takes our systems around 18 minutes to prepare the content that is ready to be served via our quite popular mobile application; to our listeners.

Let’s take a look at the steps that are involved to complete the workflow.

Transcoding

First, we have to convert our audio file from WAV into MP3 since we don’t need the high-quality audio at the coming stages of the processing and to limit the high bandwidth necessity of the listening users. The system sends a job to the AWS Elastic Encoder to do the transcoding for us.

Transcribing

The next step is to transcribe the audio file using a third party SaaS tool which helps us to get the Dutch transcription of the radio stream with an acceptable degree of correctness.

Splitting

During the live radio broadcast, the BNR’s radio system generates XML files to indicate the jingles that are played during the live show. We use this meta information in the following steps of the Workflow to divide the audio into segments. In the process, the system also removes commercials out of the final segments.

Tagging

As the final step of the workflow, our system uses the transcriptions and acquired meta information to create segments, and then these segments are tagged with our state-of-the-art ML model. We train our models on the existing tagged articles. We predict the tags for the transcribed section of the corresponding audio segment.

Technology Stack

Our infrastructure and workflow code is written in Clojure . All the data science related code written on Python and SR API uses Python Zappa framework.

We heavily rely on multiple AWS.

S3 : Main storage unit for audio files and workflow in-between steps
RDS (MySQL) Main storage for audio catalog
API Gateway: Gate keeper of Real world to our systems
Step Functions: Handling workflows, gluing functions into each other
Lambda Functions: Do things, scale without effort, be nimble!
ElastiCache (Redis) Temporary event storage
Kinesis (Streams & Firehose) Events! System of records
ECS — Fargate : Container management like Kubernetes
Cloud Formation: Infrastructure Automation
Elastic Transcoding: Audio processing

We talked about the Smart Radio Project, how and why we aim to be serverless, walked you through the components of our system, and mentioned the systems we use within AWS. The next parts will be about the following topics;

In Part II, we will be looking at the Step Functions

In Part III, we will be talking about the Lambda Functions

In Part IV, we will be looking into API details

In Part V, we will dive into Clojure

In Part VI, we will discuss the Kinesis usage

In Part VII, how CloudFormation ties all the knot

I would like to thank Phillippe Bressers, Sven v.d Burg, Maya Sappelli and David Graus for the contributions.

Serverless Smart Radio