12Mar, 2022
Author Image Pat Saucier
The emergence of networking – Introduction to Serverless on AWS

The emergence of networking

Early mainframes were independent and could not communicate with one another. The idea of an Intergalactic Computer Network or Galactic Network to interconnect remote computers and share data was introduced by computer scientist J.C.R. Lick‐ lider, fondly known as Lick, in the early 1960s. The Advanced Research Projects Agency (ARPA) of the United States Department of Defense pioneered the work, which was realized in the Advanced Research Projects Agency Network (ARPANET). This was one of the early network developments that used the TCP/IP protocol, one of the main building blocks of the internet. This progress in networking was a huge step forward.

The beginning of virtualization

The 1970s saw another core technology of the modern cloud taking shape. In 1972, the release of the Virtual Machine Operating System by IBM allowed it to host multiple operating environments within a single mainframe. Building on the early time-sharing and networking concepts, virtualization filled in the other main piece of the cloud puzzle. The speed of technology iterations of the 1990s brought those ideas to realization and took us closer to the modern cloud. Virtual private networks (VPNs) and virtual machines (VMs) soon became commodities.

The term cloud computing originated in the mid to late 1990s. Some attribute it to computer giant Compaq Corporation, which mentioned it in an internal report in 1996. Others credit Professor Ramnath Chellappa and his lecture at INFORMS 1997 on an “emerging paradigm for computing.” Regardless, with the speed at which technology was evolving, the computer industry was already on a trajectory for massive innovation and growth.

The first glimpse of Amazon Web Services

As virtualization technology matured, many organizations built capabilities to auto‐ matically or programmatically provision VMs for their employees and to run busi‐ ness applications for their customers. An ecommerce company that made good use of these capabilities to support its operations was Amazon.com.

During early 2000, engineers at Amazon were exploring how their infrastructure could efficiently scale up to meet the increasing customer demand. As part of that process, they decoupled common infrastructure from applications and abstracted it as a service so that multiple teams could use it. This was the start of the concept known today as infrastructure as a service (IaaS). In the summer of 2006, the com‐ pany launched Amazon Elastic Compute Cloud (EC2) to offer virtual machines as a service in the cloud for everyone. That marked the humble beginning of today’s mammoth Amazon Web Services, popularly known as AWS!

15Feb, 2022
Author Image Pat Saucier
Cloud deployment models – Introduction to Serverless on AWS

Cloud deployment models

As cloud services gained momentum thanks to the efforts of companies like Amazon, Microsoft, Google, Alibaba, IBM, and others, they began to address the needs of different business segments. Different access models and usage patterns started to emerge (see Figure 1-2).

Figure 1-2. Figurative comparison of different cloud environments

These are the main variants today:

Public cloud

The cloud service that the majority of us access for work and personal use is the public cloud, where the services are accessed over the public internet. Though cloud providers use shared resources in their data centers, each user’s activities are isolated with strict security boundaries. This is commonly known as a multitenant environment.

Private cloud

In general, a private cloud is a corporate cloud where a single organization has access to the infrastructure and the services hosted there. It is a single-tenant environment. A variant of the private cloud is the government cloud (for example, AWS GovCloud), where the infrastructure and services are specifically for a par‐ ticular government and its organizations. This is a highly secure and controlled environment operated by the respective country’s citizens.

Hybrid cloud

A hybrid cloud uses both public and private cloud or on-premises infrastructure and services. Maintaining these environments requires clear boundaries on secu‐ rity and data sharing.

Enterprises that prefer running their workloads and consuming services from multiple public cloud providers operate in what is called a multicloud environment. We will discuss this further in the next chapter.

The Influence of Running Everything as a Service

The idea of offering something “as a service” is not new or specific to software. Public libraries are a great example of providing information and knowledge as a ser‐ vice: we borrow, read, and return books. Leasing physical computers for business is another example, which eliminates spending capital on purchasing and maintaining resources. Instead, we consume them as a service for an affordable price. This also allows us the flexibility to use the service only when needed—virtualization changes it from a physical commodity to a virtual one.

In technology, one opportunity leads to several opportunities, and one idea leads to many. From bare VMs, the possibilities spread to network infrastructure, databases, applications, artificial intelligence (AI), and even simple single-purpose functions. Within a short span, the idea of something as a service advanced to a point where we can now offer almost anything and everything as a service!

15Nov, 2021
Author Image Pat Saucier
Infrastructure as a service (IaaS) – Introduction to Serverless on AWS

Infrastructure as a service (IaaS)

IaaS is one of the fundamental cloud services, along with platform as a service (PaaS), software as a service (SaaS), and function as a service (FaaS). It represents the bare bones of a cloud platform—the network, compute, and storage resources, commonly housed in a data center. A high-level understanding of IaaS is beneficial as it forms the basis for serverless.

Figure 1-3 shows a bird’s-eye view of AWS’s data center layout at a given geographic area, known as a Region. To offer a resilient and highly available service, AWS has built redundancy in every Region via groups of data centers known as Availability Zones (AZs). The core IaaS offerings from AWS include Amazon EC2 and AmazonVirtual Private Cloud (VPC).

Figure 1-3. An AWS Region with its Availability Zones

Platform as a service (PaaS)

PaaS is a service abstraction layer on top of IaaS to offer an application development environment in the cloud. It provides the platform and tools needed to develop, run, and manage applications without provisioning the infrastructure, hardware, and necessary software, thereby reducing complexity and increasing development velocity. AWS Elastic Beanstalk is a popular PaaS available today.

Software as a Service (SaaS)

SaaS is probably the most used and covers many of the applications we use daily, for tasks such as checking email, sharing and storing photos, streaming movies, and connecting with friends and family via conferencing services.

Besides the cloud providers, numerous independent software vendors (ISVs) utilize the cloud (IaaS and PaaS offerings) to bring their SaaS solutions to millions of users. This is a rapidly expanding market, thanks to the low costs and easy adoption of cloud and serverless computing. Figure 1-4 shows how these three layers of cloud infrastructure fit together.

Figure 1-4. The different layers of cloud infrastructure

12Sep, 2021
Author Image Pat Saucier
Database as a service (DBaaS) – Introduction to Serverless on AWS

Database as a service (DBaaS)

DBaaS is a type of SaaS that covers various data storage options and operations. Along with the traditional SQL relational database management systems (RDBMSs), several other types of data stores are now available as managed services, including NoSQL, object storage, time series, graph, and search databases.

Amazon DynamoDB is one of the most popular NoSQL databases available as a service (see Figure 1-5). A DynamoDB table can store billions of item records and still provide CRUD (Create, Read, Update, and Delete) operations with single-digit or low-double-digit millisecond latency. You will see the use of DynamoDB in many serverless examples throughout this book.

Figure 1-5. Pictorial representation of Amazon DynamoDB and its data tables

Amazon Simple Storage Service (S3) is an object storage service capable of handling billions of objects and petabytes of data (see Figure 1-6). Similar to the concept of tables in RDBMSs and DynamoDB, S3 stores the data in buckets, with each bucket having its own specific characteristics.

The emergence of services such as DynamoDB and S3 are just a few examples of how storage needs have changed over time to cater to unstructured data and how the cloud enables enterprises to move away from the limited vertical scaling and mundane operation of traditional RDBMSs to focus on building cloud-scale solutions that bring value to the business.

Figure 1-6. Pictorial representation of Amazon S3 and its data buckets

Function as a service (FaaS)

In simple terms, FaaS is a type of cloud computing service that lets you run your function code without having to provision any hardware yourself. FaaS provided a core piece of the cloud computing puzzle by bringing in the much-needed compute as a service, and it soon became the catalyst for the widespread adoption of serverless. AWS Lambda is the most used FaaS implementation available today (see Figure 1-7).

Figure 1-7. Pictorial representation of AWS Lambda service and functions

20Jul, 2021
Author Image Pat Saucier
Managed Versus Fully Managed Services – Introduction to Serverless on AWS

Managed Versus Fully Managed Services

Before exploring the characteristics of serverless in detail, it is essential to understand what is meant by the terms managed services and fully managed services. As a devel‐ oper, you often consume APIs from different vendors to fulfill business tasks and abide by the API contracts. You do not get access to the implementation or the operation of the service, because the service provider manages them. In this case, you are consuming a managed service.

The distinction between managed and fully managed services is often blurred. Cer‐ tain managed services require you to create and maintain the necessary infrastructure before consuming them. For example, Amazon Relational Database Service (RDS) is a managed service for RDBMSs such as MySQL, SQL Server, Oracle, and so on. However, its standard setup requires you to create a virtual network boundary, known as a virtual private cloud (VPC), with security groups, instance types, clusters, etc., before consuming the service. In contrast, DynamoDB is a NoSQL database service that you can set up and consume almost instantly. This is one way of distinguishing a managed service from a fully managed one. Fully managed services are sometimes referred to as serverless services.

Now that you have some background on the origins and evolution of the cloud and understand the simplicity of fully managed services, it’s time to take a closer look at serverless and see the amazing potential it has for you.

The Characteristics of Serverless Technology

Serverless is a technological concept that utilizes fully managed cloud services to carry out undifferentiated heavy lifting by abstracting away the infrastructure intrica‐ cies and server maintenance tasks.

John Chapin and Mike Roberts, the authors of Programming AWS Lambda (O’Reilly), distill this in simple terms:

Enterprises building and supporting serverless applications are not looking after that hardware or those processes associated with the applications. They are outsourcing this responsibility to someone else, i.e., cloud service providers such as AWS.

As Roberts notes in his article “Serverless Architectures”, the first uses of the term serverless seem to have occurred around 2012, sometimes in the context of service providers taking on the responsibility of managing servers, data stores, and other infrastructure resources (which in turn allowed developers to shift their focus toward tasks and process flows), and sometimes in the context of continuous integration and source control systems being hosted as a service rather than on a company’s on-premises servers. The term began to gain popularity following the launch of AWS Lambda in 2014 and Amazon API Gateway in 2015, with a focus on incorporating external services into the products built by development teams. Its use picked up steam as companies started to use serverless services to build new business capabili‐ ties, and it’s been trending ever since.

During the early days, especially after the release of AWS Lambda (the FaaS offering from AWS), many people used the terms ser‐ verless and FaaS interchangeably, as if both represented the same concept. Today, FaaS is regarded as one of the many service types that form part of the serverless ecosystem.

Definitions of serverless often reflect the primary characteristics of a serverless application. Along with the definitions, these characteristics have been refined and redefined as serverless has evolved and gained wider industry adoption. Let’s take a look at some of the most important ones.

16Jun, 2021
Author Image Pat Saucier
Pay-per-Use – Introduction to Serverless on AWS

Pay-per-Use

Pay-per-use is the main characteristic that everyone associates with serverless. It mainly originated from the early days of serverless, when it was equated with FaaS: you pay for each function invocation. That interpretation is valid for ephemeral services such as AWS Lambda; however, if your application handles data, you may have a business requirement to store the data for a longer period and for it to be accessible during that time. Fully managed services such as Amazon DynamoDB and Amazon S3 are examples of services used for long-term data storage. In such cases, there is a cost associated with the volume of data your applications store every month, often measured in gibibytes (GiB). Remember, this is still pay-per-use based on your data volume, and you are not charged for an entire disk drive or storage array.

Figure 1-8 shows a simple serverless application where a Lambda function operates on the data stored in a DynamoDB table. While you pay for the Lambda function based on the number of invocations and memory consumption, for DynamoDB, in addition to the pay-per-use cost involved with its API invocations for reading and writing data, you also pay for the space consumed for storing the data. In Chapter 9, you will see all the cost elements related to AWS Lambda and DynamoDB in detail.

Figure 1-8. A simple serverless application, illustrating pay-per-use and data storage cost elements

Autoscaling and Scale to Zero

One of the primary characteristics of a fully managed service is the ability to scale up and down based on demand, without manual intervention. The term scale to zero is unique to serverless. Take, for example, a Lambda function. AWS Lambda manages the infrastructure provisioning to run the function. When the function ends and is no longer in use, after a certain period of inactivity the service reclaims the resources used to run it, scaling the number of execution environments back to zero.

AWS Lambda Execution Environments

When a Lambda function is invoked, the AWS Lambda service runs the function code inside an execution environment. The execution environment is run on a hardware-virtualized virtual machine (MicroVM) known as Firecracker. The execu‐ tion environment provides a secure and isolated runtime environment for function execution. It consists of the function code, any extensions, temporary local filesystem space, and language runtime.

One execution environment is associated with one Lambda function and never shared across functions.

Conversely, when there is a high volume of requests for a Lambda function, AWS automatically scales up by provisioning the infrastructure to run as many concurrent instances of the execution environment as needed to meet the demand. This is often referred to as infinite scaling, though the total capacity is actually dependent on your account’s concurrency limit.

With AWS Lambda, you can opt to keep a certain number of function containers “warm” in a ready state by setting a function’s provisioned concurrency value.

Both scaling behaviors make serverless ideal for many types of applications.

Lambda Function Timeout

At the time of writing, a Lambda function can run for a maximum execution time of 15 minutes. This is commonly referred to as the timeout period. While developing a Lambda function, you can set the timeout to any value up to 15 minutes. You set this value based on how long the function requires to complete the execution of its logic, and expect it to finish before its timeout. If the function is still executing when it reaches its set timeout, the AWS Lambda service terminates it.

12Apr, 2021
Author Image Pat Saucier
High Availability – Introduction to Serverless on AWS

High Availability

A highly available (HA) application avoids a single point of failure by adding redun‐ dancy. For a commercial application, the service level agreement (SLA) states the availability in terms of a percentage. In serverless, as we employ fully managed

services, AWS takes care of the redundancy and data replication by distributing the compute and storage resources across multiple AZs, thus avoiding a single point of failure. Hence, adopting serverless provides high availability out of the box as standard.

Cold Start

Cold start is commonly associated with FaaS. For example, as you saw earlier, when an AWS Lambda function is idle for a period of time its execution environment is shut down. If the function gets invoked again after being idle for a while, AWS provisions a new execution environment to run it. The latency in this initial setup is usually called the cold start time. Once the function execution is completed, the Lambda service retains the execution environment for a nondeterministic period. If the function is invoked again during this period, it does not incur the cold start latency. However, if there are additional simultaneous invocations, the Lambda service provisions a new execution environment for each concurrent invocation, resulting in a cold start.

Many factors contribute to this initial latency: the size of the function’s deployment package, the runtime environment of the programming language, the memory (RAM) allocated to the function, the number of preconfigurations (such as static data initializations), etc. As an engineer working in serverless, it is essential to under‐ stand cold start as it influences your architectural, developmental, and operational decisions (see Figure 1-9).

Figure 1-9. Function invocation latency for cold starts and warm executions—requests 1 and 2 incur a cold start, whereas a warm container handles request 3

12Mar, 2021
Author Image Pat Saucier
The Unique Benefits of Serverless – Introduction to Serverless on AWS

The Unique Benefits of Serverless

Along with the core characteristics of serverless that you saw in the previous section, understanding some of its unique benefits is essential to optimize the development process and enable teams to improve their velocity in delivering business outcomes. In this section, we’ll take a look at some of the key features serverless supports.

Individuality and Granularity of Resources

“One size fits all” does not apply to serverless. The ability to configure and operate serverless services at an individual level allows you to look at your serverless applica‐ tion not just as a whole but at the level of each resource, working with its specific characteristics. Unlike with traditional container applications, you no longer need to set a common set of operational characteristics at the container level.

Say your application has several Lambda functions. Some functions handle user requests from your website, while others perform batch jobs on the backend. You may provide more memory for the user-facing functions to enable them to respond quickly, and opt for a longer timeout for the backend batch job functions where performance is not critical. With Amazon Simple Queue Service (SQS) queues, for example, you configure how quickly you want to process the messages as they come into the queue, or you can decide whether to delay when a message becomes available for processing.

Amazon SQS is a fully managed and highly scalable message queu‐ ing service used to send, receive, and store messages. It is one of AWS’s core services and helps build loosely coupled microservices. Each SQS queue has several attributes; you can adjust these values to configure the queue as needed.

When you build an application that uses several resources—Lambda functions, SQS queues, DynamoDB tables, S3 buckets, etc.—you have the flexibility to adjust each resource’s behavior as dictated by the business and operational requirements. This is depicted in Figure 1-10, which shows part of an order processing microservice.

The ability to operate at a granular level brings many benefits, as you will see throughout this book. Understanding the individuality of resources and developing a granular mindset while building serverless applications helps you design secure, cost-effective, and sustainable solutions that are easy to operate.

Figure 1-10. A section of an order processing microservice, illustrating how each server‐ less resource has different configurations

15Jan, 2021
Author Image Pat Saucier
Ability to Optimize Services for Cost, Performance, and Sustainability – Introduction to Serverless on AWS

Ability to Optimize Services for Cost, Performance, and Sustainability

Cost and performance optimization techniques are common in software develop‐ ment. When you optimize to reduce cost, you target reducing the processing power, memory consumption, and storage allocation. With a traditional application, you exercise these changes at a high level, impacting all parts of the application. You cannot select a particular function or database table to apply the changes to. In such situations, if not adequately balanced, the changes you make could lead to perfor‐ mance degradations or higher costs elsewhere. Serverless offers a better optimization model.

Serverless enables deeper optimization

A serverless application is composed of several managed services, and it may contain multiple resources from the same managed service. For example, in Figure 1-10, you saw three Lambda functions from the AWS Lambda service. You are not forced to optimize all the functions in the same way. Instead, depending on your requirements, you can optimize one function for performance and another for cost, or give one function a longer timeout than the others. You can also allow for different concurrent execution needs.

Based on their characteristics, you can exhibit the same principle with other resources, such as queues, tables, APIs, etc. Imagine you have several microservices, each containing several serverless resources. For each microservice, you can optimize each individual resource at a granular level. This is optimization at its deepest and finest level in action!

Optimizing for Sustainability

In addition to the traditional cost and performance optimization strategies, there is now a need to consider sustainability as well. Chapter 10 explains this in detail, presenting several patterns for developing and operating your applications in a sus‐ tainable AWS cloud environment.

Optimizing for sustainability may have an impact on cost and performance. As a general principle, when you optimize to reduce cost, you are likely to consume fewer compute resources, resulting in lower power consumption, thus promoting sustaina‐ bility. However, optimizing for higher performance often results in consuming more energy and may not align with sustainability goals. In such situations, you’ll need to make trade-offs: identify the expected performance level, and optimize up to it and not beyond.

Copyright © 2025 randolphfly.com