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 ?
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.
- 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…
- 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 Times. 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.
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.
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.
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.
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.
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.
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 IV, we will dive into Clojure
In Part V, we will be looking into API details
In Part VI, we will discuss the Kinesis usage
In Part VII, how CloudFormation ties all the knot