My Serverless Story

Sonika Jindal
Feb 4, 2019 · 2 min read

The ‘serverless’ buzzword is exciting developers and organizations. My association with the serverless world is about 10 months old and I am sticking to it. I got interested in serverless applications because it is literally the fastest medium to get started with your idea. The concept of just writing code sounds very productive and enriching from a developer’s point of view.

I began my joy ride by learning to deploy network functionalities to fully managed serverless platforms. This means the deployment of network functions as serverless functions. The list of services offered by cloud providers had been adequate for supporting all the functionality of network functions. I used Function-as-a-Service, Datastore, Metrics, API Gateway and Logging. With abundant documentation and tutorials, the learning curve is pretty steep. For each design challenge, I could find an alternate. I was freed from the worry of load balancing and scaling. I was assured that when the traffic grows, the platform will scale up my deployment and also scale down when not in use. I was convinced that I will not be charged for the idle time. Overall, my experience was very positive and fulfilling except for some hiccups discussed next.

When it comes to price, the biggest contributor for applications was Data store followed by API Gateway. Data store costs might be unavoidable if we want reliable and available storage. But API Gateway cost looks redundant and wasteful. With $3.50 per million calls at AWS’s API Gateway, and applications broken down into small independent units, cost increases drastically. Although managed services can still win the cost battle for small organizations because of zero management burden.

Another big obstacle for this use case had been the supporting interfaces. Like any managed service, Functions/Lambdas also expose a limited number of ways to interact with them. Whereas network supports various protocols for different functionality. Control and data plane of a network work separately on different protocols. This means that network functions cannot be directly ported to managed platforms which expose limited interfaces. Specifications need to be reshaped to be able to leverage the real benefits of serverless platforms. Foreseeing the need, 3GPP is redefining 5G using a Service Based Architecture which allows easy adoption of managed platforms.

The delays introduced because of the serverless framework and cold starts is another thing organizations are concerned about. In its current form, it is not usable for latency-sensitive network functions like data plane applications. AWS Lambda takes about 60ms to process a simple request and respond. This delay is higher with Azure Functions and Google Cloud Functions. So, it is best suited for background operations and tasks which are not prone to time sensitivity.

I have used a combination of proprietary and open source solutions like AWS Lambda, OpenFaaS, DynamoDB, Cassandra DB and many more. My personal favorite had been OpenFaaS because of its simplicity and active developer community. I am an admirer of speed of on-boarding with serverless platforms. I will continue my experiments and keep delving deeper into cloud technologies. Feel free to leave comments and reach out to me to discuss.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store