Serverless in Five Minutes

This chapter explains the financial and technical constraints of serverless deployments. You will learn when and why AWS Lambda is a good option for hosting software, and when a different service might be a better choice.

Introduction to serverless architecture #

Serverless applications, at the most basic technical level, are software that runs in an environment where the hosting provider is fully responsible for infrastructural and operational tasks. These include receiving network requests, scaling the computing infrastructure on demand, monitoring, and recovery.

Instead of containers bundling application business logic with an operating system, network servers (such as web servers or message brokers) and business logic code, serverless applications only need to provide the code that should run when an event happens and configure the triggers in the execution environment to call that code.

In the Amazon Web Services cloud, the execution environment for serverless code is called AWS Lambda. It supports a wide array of potential triggers, including incoming HTTP requests, messages from a queue, customer emails, changes to database records, user authentication, messages coming to web sockets, client device synchronization, and much more.

Because application developers do not package or distribute the server code to control a network socket in AWS Lambda, their applications are serverless. The buzzword ‘serverless’ is a horrible marketing term, and the Internet is full of bad jokes about how there are still servers in a serverless environment. So, what do we mean by ‘running serverless’?

An analogy #

The right comparison to think about is WiFi. When you browse the internet using a ‘wireless’ connection in a coffee shop, your device talks to a router just a few feet away, and there is a wire coming out of that router that takes your packets to the internet. But you don’t need to care about that wire or manage it actively. AWS Lambda is serverless in the same way WiFi is wireless. There are network servers, virtual and physical machines running in the background, but you don’t really need to care about them anymore.

Benefits of serverless architecture #

Compared with running applications in a container cluster or managing virtual machines directly, serverless deployments have two significant​ benefits:

• Shorter time to market for new features, leading to faster innovation and delivering value to customers sooner
• Reduced operational costs due to better resource utilization

* A study by the research company IDC published in 2018 suggests that companies adopting serverless applications on average “lowered five-year operating costs by 60% and were 89% faster at compute deployment.” This is roughly consistent with my experience. After MindMup moved from a host where we paid for the reserved capacity to AWS Lambda, we reduced operational costs by almost two-thirds. Another popular case study is Yubl, presented by Yan Cui at various conferences over the last few years. Yubl reduced its operational costs by 95% by moving to Lambda. Both the MindMup and Yubl case studies are explained in more detail in the research paper Serverless Computing: Economic and Architectural Impact which Robert Chatley and I co-authored.

Adoption of AWS Lambda #

In March 2018, Cloudability published the results of its State of the Cloud research of AWS customers, which suggested that adoption of Lambda had increased by 667% in a year. This is not surprising, because the combination of reduced operational cost and a faster path to customer value provides a very strong financial incentive for companies to adopt AWS Lambda and other similar services. The key factor in both reduced costs and faster development is ​the same. It is the serverless pricing model.

In the next lesson, you’ll look at the pricing model of serverless architecture.