Look, Ma! No Server!
At Nu Echo, we have adopted Amazon Web Services (AWS) for quite some time now, and have moved various kinds of workload into the cloud. As we progress with our own adoption of AWS technologies and services, we try to keep track of the various industry trends, so we can perform operational optimization while facilitating innovation.
One such trend right now is serverless computing, which
is a cloud computing execution model in which the cloud provider dynamically manages the allocation of machine resources. — Wikipedia
In other words: small bits of code instantiated and executed out of thin air. Almost.
In a constantly evolving world, this model is an enabler for a faster development lifecycle. The operational tasks of managing server instances gets completely bundled into a more DevOps type of role where serverless components are simply deployed as part of a deployment pipeline without any consideration for server resource allocation.
Most cloud providers out there now support such serverless execution model in some form or another. Google has the Cloud Functions, Microsoft the Azure Functions, and Amazon the AWS Lambdas. As we have already invested in AWS — and it is a terrific platform — , we’ve recently explored ways to move some of our workloads to the serverless world of Lambda service.
Call Recording Voice Quality Post-Processing
As part of our infrastructure deployments, our NuBot Platform to name one, running voice quality analytics on top of our call recordings remains crucial. How’s the quality of the call doing over time? For each and every single call recording, we typically have a processing pipeline where upon call completion, call recording is fetched off a remote location, chunked into small interval segments, sent off to our MOS computation algorithm, with results fed to our data layer in a timeseries format.
Every single call means a plethora of data to process and an associated processing power to have access to — unless you’re ok to have the results next year. So you go on and set up a batch processing pipeline where the actual processing would occur within a bunch of server instances, or you set up auto-scaling facilities to adjust processing units based on call volume.
Or….You go on and adopt the serverless model!
The recordings gets pushed over an S3 bucket, which in turn generates an Object Creation Event, which can then be consumed by a Lambda function performing the bulk of both chunking and MOS computation itself. No server required. Battery included.
That’s all there is to this Lambda handler, which is essentially an event handler, performing some on-demand operation. As for our specific case, once computed, the MOS result is then fed into CloudWatch as a custom metric, for which we can set alarm triggers, as well as to a Kinesis stream for further processing and aggregation.
While this very Lambda runs on a Java Virtual Machine (JVM), deployed as an archive bundle (Fat or Uber Jar), we have also experimented running Lambdas on Node.js. In order to manage the lifecycle, we’ve also leveraged the Apex toolkit, which, like other available toolkits such as serverless and more recently AWS SAM local, provides facilities to deploy, get logs off CloudWatch, invoke handlers and such.
From a continuous release perspective, the workflow remains rather simple and fits nicely within a deployment pipeline where unit tests are continuously performed as part of code commit while integration tests — including full interaction with AWS infrastructure — would be done as part of a release tag triggered job.
As with anything, the challenge remains in the testing strategy. Depending on whether one uses version pinning for specific Lambda releases or not, tests may or may not fully encompass not only unit test but also integration test. Your milage may vary.
Great! We now have a call recording post-processing pipeline to run completely serverless.
My thanks to my colleague Florian Parga for crafting the actual MOS computation Lambda.
