Mastering Serverless Computing with AWS Lambda: Unlock Scalability, Optimize Costs, and Drive Innovation with AWS Lambda Serverless Solutions for Modern Cloud Transformation

CHAPTER 1

Introduction to Serverless Computing

Introduction

This chapter provides a detailed overview of serverless computing, computing needs, the applicable designs in different cases and the advantages of each. The chapter delves into the traditional distributed cloud computing and deep dive into some challenges brought by those solutions, briefing how serverless computing overcomes those challenges, including scaling, infrastructure management, performance bottlenecks, and cost optimization.

The Vendor Lock-in concept will be explored to see how and when a cloud provider can be considered as a lock during transformation and afterward. Finally, the chapter puts a fair focus on challenges and complexities of serverless design, despite its well-suited characteristics.

Structure

In this chapter, we will discuss the following topics:

Serverless at a Glance

High-Performance and High-Throughput Computing

Serverless versus Traditional Cloud

Serverless Computing

Vendor Lock-In

Portability in Serverless

Challenges and Complexities when Designing Serverless

Serverless at a Glance

Defining Serverless computing is an interesting exercise due to the multitude of definitions and varied perspectives surrounding the concept. Different organizations and thought leaders have their own interpretations and nuances of what Serverless means. However, it can be confidently stated that serverless is an economic model primarily focused on minimizing costs associated with ownership and maintenance of technology.

Discussions about Serverless often revolve around its scalability, its cost-effectiveness, and its ability to reduce time-to-market in comparison to self-hosted or managed solutions, even with modern cloud platforms.

To better describe its differentiation, let us examine how Serverless addresses the following challenges:

Infrastructure Management Overhead

Scalability

Development Velocity

Cost

Infrastructure Management Overhead

Establishing a new infrastructure or foundation for digital platforms can be a lengthy process involving definition, evaluation, and strategic decision-making, particularly in large organizations. Assembling a team of experts and ensuring they are aligned in terms of vision is not a straightforward task. Maintaining and evolving these foundations also require time and effort.

Serverless can alleviate some of these overheads by offering solutions (or delaying some decisions) for some of these initial tasks, albeit sometimes with an opinionated approach.

Moreover, Serverless architectures reduce management overhead by abstracting away the need for server provisioning, scaling, and reduced maintenance.

Scalability

Traditional hosting on managed cloud services or on-premise servers may require teams to provision, manage, and scale servers, storage, and network resources in a more involved approach, leading to a more complex management process. Furthermore, it often requires upfront capacity planning, which involves predicting future demand to provision adequate resources and can lead to over-provisioning (provisioning more than workload requires) or under-provisioning (provisioning less than workload requires) if predictions are off.

In contrast, serverless offerings are specifically designed with scalability as a core feature. They automatically adjust resources based on demand, ensuring that applications can handle varying levels of traffic efficiently. This is often achieved without the need for upfront planning, allowing for a more responsive infrastructure.

As a result, serverless architectures are better equipped to provide a seamless scaling solution for modern applications.

Development Velocity

Traditional managed infrastructure entails responsibilities such as selecting server sizes, managing operating systems, and ensuring security, which can slow down development and deployment as teams need to focus more on infrastructure.

In contrast, serverless computing enables faster development cycles as developers can focus on writing code without worrying about infrastructure management. This leads to a more efficient development process and a shortened feedback loop.

Generally, serverless offerings often provide integration with other services and tools, further accelerating the development process.

Cost

Cost is a very important dimension for organizations when they need to scale. They mostly would like to pay for what brings value to their business. These organizations rely a lot on Return on Investment (ROI) and Total Cost of Ownership (TCO). Companies like to pay for what they consume.

Serverless can help reduce costs by eliminating the need for provisioning and maintaining physical servers, as the cloud providers automatically manage the scaling of resources based on demand. This pay-as-you-go model allows organizations to pay only for the actual computing time and resources used, optimizing expenses and minimizing waste.

Serverless on AWS

In this book, we will delve into the concept of serverless computing, specifically focusing on its implementation within the context of Amazon Web Services (AWS), with a particular emphasis on the AWS Lambda service. We will demonstrate how it can be utilized to build scalable and efficient applications.

We often associate serverless with AWS Lambda, but it is important to note that Lambda is just one, albeit iconic, among numerous serverless solutions offered by AWS.

For example, Amazon Simple Queue Service (SQS) is a serverless message queuing service that enables the decoupling and scaling of microservices. Amazon Simple Storage Service (S3) is another serverless service that provides object storage with a simple API, allowing you to store and retrieve any amount of data at any time. AWS App Runner, AWS Step Functions, and Amazon API Gateway are other examples of serverless services that help you build, deploy, and manage applications without the need to provision or manage servers.

By grounding our discussion in the AWS ecosystem, we aim to provide readers with practical insights and hands-on experience with serverless technologies on one of the leading cloud platforms.

High-Performance and High-Throughput Computing

Serverless solves a wide variety of computational challenges, primarily using Lambda service. However, not all computing needs can be managed by a single service like Lambda. Like all other services, Lambda has its pitfalls and limits. To solve different computing needs, there are other serverless services that can be used to solve these challenges collaboratively with lambda service.

To better understand the computational needs and delve further into this book to see how serverless helps to achieve different computational requirements, it is essential to understand how High-Performance Computing (HPC) and High-Throughput Computing (HTC) systems operate.

Overview

The HPC and HTC models are two design approaches to tackle computational problems. Both of these designs are valuable in their own place and can live alone or coexist as complementary to each other.

Computing is the core of any digital design, but choosing the right design is all about trade-offs and needs to be considered based on the priorities over the design principle pillars, such as performance, scalability, reliability, cost, and operational requirements at the core.

High-Performance Computing

High-performance computing describes systems with a higher need for computing power, such as Data processing or Simulations. In HPC design, we mostly rely on compute processors and nodes as the power of computation, and resource sharing and division as the power of parallelization. The HPC systems need mastery of computation and an understanding of how the process behaves. These are highly attached to a programming model, and not a programming language, but differ from traditional computing systems. In HPC, the parallel processes share some information while computing, introducing a tight coupling that is essential for the success of the process.

In modern HPC, based on needs and coupling, the process relies on distributed communication over the network. So, for a successful and reliable process, a high-speed and reliable network is necessary. While the network can be reliable, the doubt around its reliability brings overhead and needs good supervision and maintenance effort.

HPC Systems Characteristics

Here are some of the characteristics of HPC systems:

Speed: The HPC systems can perform computational treatments at a high speed due to their utilization of resources such as Processes and Tasks.

Parallelism: In HPC systems, parallel models are highly used to accelerate and achieve result accuracy at a higher rate by resource sharing at processor scope.

Throughput: HPC scales well at the computational level with its sole consideration on how to achieve consistent and accurate results at the workload level. However, HPC cannot scale well with high throughput with a precise time metric.

Figure 1.1 illustrates a typical HPC system on AWS:

Figure 1.1: Typical HPC system on AWS

High-Throughput Computing

High-Throughput computing describes systems that can treat too many tasks in parallel with a high rate of throughput at a given time. In HTC, scaling can be achieved well by using an arrangement of distributed nodes shaping a cluster. HTC systems have the capacity to be easily adopted and bring a higher level of flexibility in contrast to HPC systems. In HTC, the processes are decoupled and act independently; any process can use a different runtime.

HTC Systems Characteristics

Here are some of the characteristics of HTC systems:

Throughput: HTC systems, due to their core design, can handle many demands at a given time. They benefit from computational nodes in a distributed way to better handle the high rate of demands.

Parallelism: HTC helps to obtain parallel processing using a collection of computing nodes shaping a cluster. These clusters allow the system to go beyond normal needs and treat demands in a stateless and distributed manner.

Reliability: HTC runs small tasks in a distributed way, so the overall system has a high level of reliability due to the separation of running tasks, ensuring that no single task will affect the overall process reliability.

Figure 1.2 shows a typical HTC system on AWS:

Figure 1.2: Typical HTC system on AWS

Serverless versus Traditional Cloud

A growing number of organizations are embracing the cloud or are in the process of transitioning their workloads into the cloud. This shift is driven by the cloud’s operational model and its ability to accelerate innovation and growth. Transitioning to the cloud allows organizations to eliminate the challenges associated with managing data centers, resources, and costs.

When it comes to adopting serverless computing, there are often debates comparing on-premises hosting versus serverless. However, we believe that this isn’t the most effective way to assess the advantages of serverless adoption.

A better and more simplified approach for a meaningful evaluation involves comparing:

On-premises hosting versus Traditional cloud hosting

Traditional cloud hosting versus Serverless

By following this approach, we can gain a more comprehensive and insightful perspective as we navigate the evaluation process.

Advantages of Cloud Hosting Compared to On-Premises Hosting

Here are some of the advantages of Cloud Hosting in comparison to On-premises Hosting:

Operational versus Capital Expense: Moving from Capital Expenses (CapEx) toward Operational Expense (OpEx) means you no longer need to pay in advance for any underlying infrastructure; instead, you pay based on operational activities.

Elasticity: You can reduce the effort spent on estimating your application’s capacity requirements upfront. Instead, you can easily implement horizontal scaling with simplified capacity planning and system configuration activities. Resources will then be dynamically allocated, scaling in and out based on your runtime requirements.

Global infrastructure: You can go globally from one geographical location (region) to another and all just within a short period.

TTM: Reducing TTM (Time-to-Market) by focusing more on application and business constraints than infrastructure.

Economy at scale: By using the cloud and benefiting from its shared infrastructure design, you move closer to Pay-per-Consumption billing mode as the infrastructure is highly shared between customers with high-security considerations.

Innovation: The cloud fosters innovation by offering faster access to computing resources and services compared to traditional on-premises hosting environments, enabling businesses to quickly scale and experiment without the limitations of physical hardware. The cloud’s agility enables quicker deployment and testing of new applications and services, accelerating development cycles and enabling companies to rapidly iterate and innovate.

Advantages of Serverless Compared to Traditional Cloud

Here are some of the advantages of Serverless in comparison to Traditional Cloud:

Adaptive Scaling: Many serverless solutions automatically scale according to demand, ranging from zero to peak demand and inversely based on your runtime needs. As a result, capacity planning activities are even less involved compared to traditional cloud.

Pay-per-consumption: Serverless computing offers an attractive billing model, where you typically pay for your actual consumption. This cost-effectiveness benefits businesses and increases motivation for adopting serverless. Sometimes, a recurrent fee may apply, but it still proves advantageous compared to the management overhead associated with traditional infrastructure.

Software Quality: With serverless, we can expect improved software quality because the focus shifts from configuring infrastructure to building applications. This shift allows development teams to concentrate more on writing high-quality code and implementing features, resulting in more robust and efficient applications that better serve the end users.

Even more Improved TTM: Serverless computing improves even more TTM (Time to market) by eliminating operational overhead, allowing for more agility through iterative releases, and tightening the feedback loop.

Moving to the Cloud

In the previous section, we have seen that Cloud hosting offers numerous advantages over on-premises hosting. However, this can be just the beginning of a migration journey toward the Cloud. By choosing a more comprehensive strategy, we can further optimize our cloud migration with the 6 R’s of the cloud migration framework:

Re-host

Re-platform

Re-purchase

Re-factor

Retain

Retire

The decision to migrate to the cloud or retain a solution on-premises is a significant one, and we won’t delve deeper into it in this book. However, it’s crucial to ensure that your decision brings long-term value to the enterprise.

Agronomy of Traditional Computational Cloud Solutions

Let us create a visual representation to make it more comprehensive for anyone.

Here, we are exploring four application deployments in a single region of cloud providers.

Figure 1.3: Traditional cloud computing solutions

Let us suppose these four applications use the EC2 compute platform along with autoscaling groups and for some multi-AZ deployment:

Application #A, #C: Both are deployed in three availability zones with auto-scaling configured for a minimum desired capacity of three. Whenever their peak load grows or a failure occurs, there will be other nodes going up to respond to the application need.

Application #B: It is deployed in a large instance configured in two availability zones with a minimum desired capacity of one. Whenever the peak raises or a failure happens in the first instance, a second instance will be initiated in a secondary availability zone.

Application #D: It is deployed in a single availability zone with a minimum desired capacity of two instances. In case of growth or failure, another instance will be initiated in the same availability zone.

Note: An availability zone (AZ) is a physically isolated data center within a cloud provider’s geographic region, designed to enhance redundancy and high availability by ensuring that if one zone experiences an outage, services can failover to another.

Issues to addresse

This design could certainly be improved, as it has some issues, including:

Fault tolerance: When it comes to autoscaling and high availability, it is crucial to ensure that any critical workload is prepared for any type of failure. This includes software failures, resource failures, and availability zone failures.

In our example, Application D has two nodes in a single availability zone that impacts the fault tolerance pillar of his solution

Provisioning: Determining the required software resources can be challenging, and over-provisioning presents its own set of problems for Applications B and D.

There are no one-size-fits-all best practices for provisioning resources, as it depends on the workload running on the node. While you can optimize your resource provisioning, doing so requires analyzing workload metrics, which means you need initial provisioning and subsequent monitoring of the metrics, or automating the metric analysis.

There are services on AWS, like AWS Compute Optimizer, that help you in this analysis and provide recommendations for optimizing your workloads.

In our example, whether all four applications are highly available or not, achieving a design based on well-architected pillars requires continuous refinement. It is essential to monitor any solution in real-time, anticipate new behaviors, and always be prepared to reassess the scaling, performance, and cost requirements to better align with the business needs.

Agronomy of Serverless Computing Solutions

Let us now have a look at a serverless deployment using AWS Lambda:

Figure 1.4: Serverless computing solutions

Each request is executed in a micro container with its own runtime environment and execution context. After fulfilling a request, the container is ‘frozen’ to preserve the same context, and ‘thawed’ again when the same context experiences a new request. If no request is happening for a certain period of time, the micro container will be shut down and cleaned, freeing up resources for other customer needs.

All the aspects related to AZ, Networking, Scaling, and more, are handled under the hood. Customers are not involved in these under-the-hood decisions.

AWS Lambda naturally facilitates the sharing of underlying infrastructure, which is how it helps reduce unnecessary resource consumption. The reason some folks consider serverless a great candidate for sustainability is its attractive economic model.

Design Comparability

Let us start by examining two simple design diagrams to better understand two distinct designs. Later, we will discuss the differences between them based on important design pillars.

Figure 1.5 shows the traditional design of a three-tier application:

Figure 1.5: Traditional design of a three-tier application

Figure 1.6 shows the Serverless design for a three-tier application:

Figure 1.6: Serverless design for a three-tier application

High Availability: Both Serverless and Traditional cloud designs can achieve high availability, but there are some key distinctions to highlight.

In the traditional cloud design, high availability can be attained through configurations such as multi-AZ setups. However, even when the workload has zero or very low demand, you still pay for some level of resource usage.

This is where serverless becomes compelling due to its ‘Scale to 0’ capability. When designing serverless solutions, you rarely have to consider the High Availability pillar, and in many scenarios, there is no need to configure high availability for your solutions.

Serverless services are inherently designed with high availability in mind and managed by the service provider, so you can trust the service guidelines and your design remains highly available without extra effort.

Fault Tolerance: Another crucial aspect of design is fault tolerance. A system’s design must respond gracefully to failures without impacting the workload or causing degradation in other parts of the system. This can be achieved with both serverless and classic designs, but there are some significant differences in how it is implemented.

The traditional design uses health checks and load balancing to achieve fault tolerance. You need to define deployment across multiple Availability Zones (AZ’s) and have a load balancer that distributes the load across all the instances with health checks configured.

The serverless design achieves the same fault tolerance with a different conceptual model. In the serverless model, each single request is handled by a single container, called a Micro-VM. The queue of requests does not occur at the instance or container level but rather within the AWS Lambda service, which is highly available and fault-tolerant.

A failure at the container level will impact only one request, and the Lambda service will replace that container if any inconsistent situation is detected. This means that you only need to set up your application code, and all fault tolerance aspects are managed by AWS.

Cost: Cost is also an important design pillar. In traditional design, it is necessary to study the workload and identify the pricing model that best fits that workload. This means there is always a trade-off between performance and cost, and you need to reassess your decisions if any changes occur. To achieve a fair balance between performance and cost, you need to estimate upfront or perform reserved instance calculations to overcome high expenses.

In traditional design, there is often a waste of money since your workload does not have a 24/7 demand. To combat this and optimize costs, it is essential to first examine the total cost of ownership (TCO). This includes evaluating costs such as workload costs, operational costs, monitoring costs, time costs, maintenance costs, and more. In serverless architectures, we benefit from a "Pay as you go" billing model and a Scale to 0 approach, where costs are generally reduced to zero when there is no demand.

Scaling: Scalability is one crucial aspect of design these days, which means your design needs to respond to any change in terms of load.

In traditional design, we use auto-scaling that can be configured per some metrics such as CPU consumption. Let’s say, we consider the need for a new instance when the instance CPU consumption reaches 75% of the available CPU, this means that during high load or any unpredictable peak, we go beyond actual capacity and will be able to handle that load. However, what if we set the threshold to 95%? Can our workload be consistent between 75 and 95? How do we detect which part of the software consumes extra resources? Is it because of higher throughput, or is it because of database latency?

The responses to all of these questions are based on workload and how the workload behaves in different situations.

In summary, with the traditional