Go Serverless! But Why?

“Serverless will fundamentally change how we build business around technology and how you code.”

– Simon Wardley, Why the fuss about serverless?

Serverless Computing is coming here!

What comes to your mind when you hear the term Serverless? AWS Lambda functions? Google Cloud functions? Maybe Azure functions? Or some other service provided by yet another service provider? This is where most people get confused. What they don’t understand is that Serverless is not a service but a cloud computing execution model. Too hard to understand? Let’s break it down a little.

Oxford dictionary defines Cloud Computing as “the practice of using a network of remote servers hosted on the Internet to store, manage, and process data, rather than a local server or a personal computer”.

To quote AWS’s definition, Serverless Computing allows us to build and run applications and services without thinking about servers. Serverless applications don’t require us to provision, scale, and manage any servers.

Contrary to what most people interpret from the name “Serverless”, it doesn’t mean running your applications without ever needing any servers. It just means you can build your application without having to worry about scaling, availability, cost and management. Everything is handled for you (almost). So the name can be said to be a misnomer.

Why Serverless you ask?

I ask why not? It is cost effective, pay-per-use service, has enhanced scalability, faster to write and deploy and easy to manage (for both, developers and customers). It even follows the 12 factor app methodology at its core. It is stateless, explicitly declares and isolates dependencies, allows us to set configuration information in the environment and has robustness with fast startup and graceful shutdown.

As AWS explains it, “building serverless applications means that your developers can focus on their core product instead of worrying about managing and operating servers or runtimes, either in the cloud or on-premises. This reduced overhead lets developers reclaim time and energy that can be spent on developing great products which scale and that are reliable”.

But like everything else, it also has its cons. Issues like vendor lock-in, restriction on duration and debugging (although getting easier day-by-day) are something to keep in mind before jumping on this bandwagon. It being inefficient for long-running applications and the infamous “cold start” issue makes people second-guess if they should use it or not.

Granted, serverless is not perfect at the moment. But again, which framework is. It’s on the users to compare pros and cons and give a thought before selecting any stack (serverless or self-managed).

Serverless, the framework!

Yes! A framework. In December 2015, JAWS was renamed to Serverless. JAWS (Javascript Amazon Web Services) was a web framework specifically aimed at serverless development. IMO, this rename is also somewhat responsible for confusion among people when they hear `serverless`. But regardless of the name, this is easily one of the most widely used open-source framework providing `Function as a service`.

Serverless (framework) defines itself as “a single toolkit for deploying serverless architectures to any provider”. It can be explained as an abstraction over infrastructure configuration.

Under the hood, the serverless framework deploys our code to a cloud provider like AWS, Microsoft Azure, Kubeless, Apache OpenWhisk or Google Cloud functions. It supports NodeJS, Python, Kotlin, Java, Groovy, Scala, C#, F# and Go on platforms which support these languages.

Use Cases

Needless to say, serverless can solve many problems which are not so simple or elegant with traditional server-ful, for lack of a better term, can solve. From API based apps to event-based tasks, everything can be handled well in serverless. It even allows us to write multilingual applications. We are no more bound by the limits of a language we first chose and can write new/existing functions in a different language without affecting the rest of it.

At CauseCode Technologies, we use serverless for various tasks ranging from running background tasks to process files, taking and restoring frequent backups, creating auto-scalable websites and APIs, etc. With every passing day, we indulge in this world of serverless to solve yet another problem. The ease of wiring serverless functions with existing services is what makes it so powerful.

Show me the code!

Yeah! Enough talk. Let’s get our hands dirty.

The following shows yet another example of “Hello World” written in NodeJS for AWS following the quick start guide on serverless.com.

Yup. That’s it. This is what it takes to get started and running with serverless on AWS (Lambda). So what are you waiting for? Treat. Yo. Self.


“The most important benefit to me […] is the reduced feedback loop of creating new application components – I’m a huge fan of ‘lean’ approaches, largely because I think there is a lot of value in getting technology in front of an end user as soon as possible to get early feedback, and the reduced time-to-market that comes with Serverless fits right in with this philosophy.”

– Mike Roberts, Serverless Architectures


We have created a boilerplate for you to use with Serverless, DynamoDB & GraphQL in Typescript. Please feel free to use and contribute.

This is part one of many posts to come on this subject, I would love to hear from you on your own views and experience.


About CauseCode: We are a technology company specializing in Healthtech related Web and Mobile application development. We collaborate with passionate companies looking to change health and wellness tech for good. If you are a startup, enterprise or generally interested in digital health, we would love to hear from you! Let's connect at bootstrap@causecode.com
Have you subscribed to our blogs and newsletter? If not, what are you waiting for?  Click Here

Leave a Reply

Your email address will not be published. Required fields are marked *


Do you want to get articles like these in your inbox?

Email *

Interested groups *
Technical articles