MongoDB: Why AWS is pumped about serverless architecture

This is a guest post for the Computer Weekly Open Source Insider blog written by Mat Keep in his role as director of market research and analysis at MongoDB. The company is known for its MongoDB open source database that uses a document-oriented data model.

Keep writes as follows:

The next monster-trend in infrastructure is going to be another AWS popularised idea: serverless architecture. If you’ve not heard about it yet, you definitely will. Serverless architecture, also known as function-as-a-service, is promising to rapidly improve development times, make high scale apps simpler, and lower costs by tying fees to actual usage rather than provisioned capacity.

In these 600 words I’ll explain what this trend is and, I hope, convince you it’s something you should care about. Microservices got the world thinking modular for IT infrastructure but stuff’s about to get nano.

Abstraction layer

In the beginning there were data centres. Hardware was the unit of scale. If you wanted to scale an app you would allocate more compute, storage, and networking resources to handle the required load.

That was OK, but in a bid to make deploying and running applications even simpler, new technologies emerged to create additional abstractions. Infrastructure-as-a-Service abstracted away the data centre. Virtual machines abstracted away the physical hardware. Then with Platform-as-a-Service, the operating system and middleware was abstracted away, and the application became the unit of scale. Most recently discrete services within the application were packaged into microservices running in containers, and they became the unit of scale.

The next layer

Serverless computing is next layer of abstraction.

Now, the language runtime is abstracted

away and the function is the unit of scale. Developers create functions and depend on the infrastructure to allocate the appropriate resources to execute the function. If the load on the function grows, the infrastructure will create copies of the function and scale to meet demand.

Let’s use my startup as an example. Keep’s Flying Curry, is a service in which a drone delivers curries within 15 minutes of ordering (currently awaiting funding). The vast majority of traffic will come in the evening. Using a function-as-a-service infrastructure my system will generate new copies of the function as the load increases (i.e. new orders coming in). Once the order is completed the idle instances will be terminated, and the data can be persisted in a database.

Like microservices, serverless architecture is set to deliver massive benefits to savvy businesses and skilled developers. There are numerous advantages but for the sake of brevity here are the three that are most likely to get you excited:

  • Pay for only what you use: There’s no idle resources. So for the hours that Keep’s Flying Curry is not inundated with online orders, we will be paying for only the computer power to display my snazzy web page. As orders flood in and functions start firing (such as accepting orders, capturing customer details and processing payments) we’ll just pay for exactly what we use, but no more.
  • Build fast, change faster: Serverless computing is ideal for developers and organisations that need to quickly develop, prototype and iterate. Development is faster since there aren’t any dependencies on operations and, as a function is typically single threaded and focused on a single task, it also makes it easier to debug and deploy.
  • Scalability: Elastic scalability is also simple with a serverless architecture. If a function needs to scale, the infrastructure will make copies of the function to handle the load. Once the requests for a Jalfrezi have subsided, the environment will automatically terminate the idle instances and scale down, allowing costs to scale proportionally with user demand.

That was a quick scan of what serverless architecture is and peak into how it will be changing how we build and run applications  in the future. For those who want to dig deeper there are numerous further resources on the subject, here’s two I’d recommend: a white paper and a great article that give more detail on how it all works in practice.