Can we use a functional programming language with AWS Lambda?

Someone in our team, a year ago

It is incredible how a single question can direct you into an exciting place.

Journey through that rabbit hole turned out to be a crazy, but excellent chance to build know-how which we can leverage for our clients.

Today I do not tell you how much yak-shaving is required to use our beloved functional languages in serverless. Instead, let’s start with providing a common ground for everyone. We are going to discuss what does serverless actually mean in the first place.

So it means no servers and no operations people, right?

There is no cloud, it’s just someone else’s computer.

I do not know if you agree with me, but we suck when it comes to naming stuff.

We all know the old joke that there are two major problems in computer science:

  1. Cache Invalidation.
  2. Naming.
  3. Off-by-one errors.

We definitely hit number 2 when it comes to serverless. It is noisy, overhyped at the moment and simplifies the reality.

Of course, there are servers in the end. We have to execute our code on the hardware eventually. The only difference is that you do not own that silicone. The same when it comes to ops - there are operations people needed. Someone has to monitor and manage those services - they responsibilities shift a little bit, but they are still the essential piece.

The whole concept described as Serverless is the natural evolution that we observe in the IT infrastructure world - the movement that represents the transition from owning infrastructure to consuming it.

A Brief History of Cloud

Some of us got used to the situation when you had to buy racks and servers, assemble everything, take care about cooling, connectivity, redundancy, and all that stuff - we still do that, there is nothing wrong with it. However, for some companies, it is much easier to no think about such stuff, and they are perfectly fine with the more consumer-oriented way of thinking about infrastructure.

Additionally, in the current landscape, we can distinguish three flavors of Serverless: backend as a service (BaaS), function as a service (FaaS) and common software as a service (SaaS) solutions.

Available Flavors of Backend Serverless

If you are familiar with Firebase or good, old and unfortunately dead Parse - you have used backend as a service solution. The same goes with services like Auth0 that provides a well-known implementation for a specific problem.

I want to focus on “function as a service” solutions. It is a way of running your code, on demand, on someone else’s infrastructure with the minimal operational hassle. No more worrying about how many and how big instances you should provision or how to scale them up and down.

It is worth to emphasize that the whole concept is much more than computing power and similar services. As we are consuming services, new requirements, and the shift in the demand spawned a whole new branch of various products that are providing very specific services - giving an examples like Amazon Athena, Google BigQuery (query interfaces over unstructured data), Algolia (search algorithms) or Zapier (connecting various APIs and services).

Serverless is much more than executing code on demand. It is an ultimate mashup machine. It fits very well in our current state of culture that is based on remixes and combining ideas. It is a perfect visualization of synergy between multiple elements that at first sight are not connected at all.

How does serverless computing work?

Let’s start with a disclaimer. You still need to write the code - and you need to adjust your thinking.

Let’s assume that you are writing an API with some business logic. As a first step, you would look for a popular HTTP server for your language of choice. If you would choose to leverage serverless, that is the first place when you need to adjust your thinking. In most cases, there is no need for setting up web server inside your code. You need to prepare for consuming incoming events - with use of the SDK from your serverless provider. HTTP layer is fully decoupled and mostly handled via separate service.

Mind shift required for Serverless Computing

In that approach, we are preparing a package with our code, which implements that handler in our API. Additionally, to that, we are configuring only a couple of aspects of the execution unit. Then, we are uploading it to the service in which we are managing those functions. Everything else - including spawning machines on demand and operating their lifecycle - is done on the provider side.

Hopefully, you start to see patterns - our code executes on demand, based on the events that are coming to the system. Worth noting is that we have many constraints during execution, about which we are going to talk later. Giving up control in that place gives us a significantly smaller operational overhead and the promise of almost infinite scalability.

Pricing model of Serverless Computing

Such execution model heavily influences the pricing - we are paying for execution time, and memory tier either consumed or declared upfront. Additionally, we are paying for batches of consumed incoming events, e.g., in case of AWS Lambda for every million requests we pay 20 cents.


Knowing how serverless works and what it is, let’s talk why we should be bothered by this new paradigm.

Everything that I wanted to say about why we should consider serverless seriously, is compiled into this fantastic research paper (and into Gojko’s talk from GOTOConf 2017). What is even more critical those are not tips given by a random guy from the internet. They provide clear and understandable context supported by examples and measurements.

Serverless Computing: Economic and Architectural Impact

Research Paper

Paper covers cost-effectiveness, architectural impact, and operational factor. For those areas, I have prepared three quotes which should encourage you to read it.


Pricing comparison for Cloud Computing consumption models

Cost-effectiveness is an essential aspect of why we should consider such a paradigm, and that paper reflects that in structure and references inside. One of the most critical element is attached table, which compares different consumption models (IaaS, PaaS and Serverless), from different tiers between - serverless wins (represented by AWS Lambda) - and it even covers failover costs.


[…] breaking the monolith into functions that could be independently deployed, meant that they were better able to split the team up to work on more things in parallel, and to deploy each feature separately.

The second most important area covered by this paper is related to the architectural impact. There is a multitude of references, but most predominant one is related to the modularity. It is still hard to achieve, but it looks like we are getting closer to the holy grail. If you squint, you may see that posted quote is similar to the microservices architecture definition. Wouldn’t it be useful to have such elasticity and less operational burden?


[…] so their estimate is that moving to Lambda gave an operational cost reduction of greater than 95% for a comparable amount of compute.

Last, but not least I would like to emphasis topic close to my heart, which is not reflected in the paper’s title. However, it screams from between the lines. Advantages of embracing Serverless approach in this particular aspect cannot be overlooked. Everyone would love to reduce their operational costs by such factor. A key thing to remember is applicability and context - if those sounds similar to your situation you can benefit from such an approach for sure.

You may say that it is only one paper, and you are right. We should not judge the book by the cover, even if it is the most beautiful cover we have ever seen.

Other case studies of Serverless Computing usage

Thankfully I can support paper by other case studies and significant in size companies that are using Serverless. Including such fascinating use cases as fully functional subscription based MOOC platform or online collaborative mind mapping tool.


So we know that we can leverage serverless to achieve exciting results. The promise of cost-effectiveness, less operational burden and infinite scalability is inviting, but should we blindly use that everywhere? Not really - business and technical contexts are the kings here. An additional question that immediately pops up is, do we, as functional programmers, have a handicap when it comes to using that paradigm? We argument both theses in the next article, so stay tuned!

Make Serverless a Competetive Advantage of Your Business

Cloud Computing and Serverless are our core expertise. Partner with our experienced and pragmatic builders that help you innovate move quickly and be cost-effective with use of cloud platform.

Schedule a call with our expert