Serverless Architectures on AWS, Second Edition

Peter Sbarski, Yan Cui, Ajay Nair

• Publisher: Manning
• Year: 2022
• ISBN:
  9781638354024
• Topic: Informatik
• Subtopic: Webservices & APIs

Design low-maintenance systems using pre-built cloud services! Bring down costs, automate time-consuming ops tasks, and scale on demand. In Serverless Architectures on AWS, Second Edition you will learn: First steps with serverless computing
The principles of serverless design
Important patterns and architectures
How successfully companies have implemented serverless
Real-world architectures and their tradeoffs Serverless Architectures on AWS, Second Edition teaches you how to design serverless systems. You'll discover the principles behind serverless architectures, and explore real-world case studies where companies used serverless architectures for their products. You won't just master the technical essentials—the book contains extensive coverage of balancing tradeoffs and making essential technical decisions. This new edition has been fully updated with new chapters covering current best practice, example architectures, and full coverage of the latest changes to AWS. About the technology
Maintaining server hardware and software can cost a lot of time and money. Unlike traditional data center infrastructure, serverless architectures offload core tasks like data storage and hardware management to pre-built cloud services. Better yet, you can combine your own custom AWS Lambda functions with other serverless services to create features that automatically start and scale on demand, reduce hosting cost, and simplify maintenance. About the book
In Serverless Architectures with AWS, Second Edition you'll learn how to design serverless systems using Lambda and other services on the AWS platform. You'll explore event-driven computing and discover how others have used serverless designs successfully. This new edition offers real-world use cases and practical insights from several large-scale serverless systems. Chapters on innovative serverless design patterns and architectures will help you become a complete cloud professional. What's inside First steps with serverless computing
The principles of serverless design
Important patterns and architectures
Real-world architectures and their tradeoffsAbout the reader
For server-side and full-stack software developers. About the author
Peter Sbarski is VP of Education and Research at A Cloud Guru. Yan Cui is an independent AWS consultant and educator. Ajay Nair is one of the founding members of the AWS Lambda team.Table of Contents
PART 1 FIRST STEPS
1 Going serverless
2 First steps to serverless
3 Architectures and patterns
PART 2 USE CASES
4 Yubl: Architecture highlights, lessons learned
5 A Cloud Guru: Architecture highlights, lessons learned
6 Yle: Architecture highlights, lessons learned
PART 3 PRACTICUM
7 Building a scheduling service for ad hoc tasks
8 Architecting serverless parallel computing
9 Code Developer University
PART 4 THE FUTURE
10 Blackbelt Lambda
11 Emerging practices

Part 1 First steps

If you are new to serverless architectures, you’ve come to the right place. The first three chapters of this book will give you an introduction to this exciting technology and even get you to build a small serverless application of your own. The first chapter provides an overview of serverless technologies and a discussion about where we are today. The second chapter is more practical; it focuses on giving you a hands-on experience with AWS and services such as AWS Lambda. The third chapter describes popular and useful serverless patterns. Let’s get started!

1 Going serverless

This chapter covers

• Traditional system and application architectures
• Key characteristics and benefits of serverless architectures
• How serverless architectures and microservices fit into the picture
• Considerations when transitioning from server to serverless
• What’s new in this second edition?

If you ask software developers what software architecture is you might get answers ranging from “it’s a blueprint or a plan” to “a conceptual model” to “the big picture.” This book is about an emerging architectural approach that has been adopted by developers and companies around the world to build their modern applications—serverless architectures.

Serverless architectures have been described as somewhat of a “nirvana” for an application architectural approach. It promises developers the ability to iterate as fast as possible while maintaining business critical latency, availability, security, and performance guarantees, with minimal effort on the developers’ part.

This book teaches you how to think about serverless systems that can scale and handle demanding computational requirements without having to provision or manage a single server. Importantly, this book describes techniques that can help developers quickly deliver products to market while maintaining a high level of quality and performance by using services and architectures offered by today’s cloud platforms.

1.1 What’s in a name?

Before going in any further, we think it’s important to come to terms with the word serverless. There are various attempts at this already, including an official one from AWS (https://aws.amazon.com/serverless/) and a community favorite from Martin Fowler (https://martinfowler.com/articles/serverless.html). Here’s how we define it:

Definition Serverless is a qualifier that can be applied to any software or service offering, which requires that it is consumed as a utility service and incurs cost only when used.

Simple enough, right? But there’s a lot to unpack in that simple definition. Let’s dive into each of the following two required criteria to call something serverless:

• Consumed as a utility service—The “software as a service” consumption model is well understood. It means that anyone using the software uses a prescribed application programming interface (API) or web interface to use the software and customize it, while staying within any published constraints for the software and usage policies for the API. Salesforce, Office365, and Google Maps are well-known software packages delivered as a service. What’s key here is that the actual infrastructure (servers, networking, storage, etc.) hosting the software and powering the API is completely abstracted from you as the consumer; all that is visible (and all that matter) is what the API permits.
  A service also typically comes with accompanying availability, reliability, and performance guarantees from the service provider. A utility service, further, has the billing characteristics that we’d expect from any utility computing offering; that is, you pay for usage not for reservation, subscriptions, or provisioning. All existing public cloud offerings have some form of utility billing associated with them. For example, Amazon Elastic Compute Cloud (EC2) allows you to pay by the second for the rent of virtual machines.
• Incurs cost only when used—This means there’s zero cost for having the software deployed and ready to use. Think of this as the same cost model we expect from our public utilities like electricity and water. You, as the consumer, pay a per granular usage unit cost if you use any, but you pay zero if you use nothing. This aspect of pure usage-based pricing is a distinguishing criterion of serverless offerings from the other utility services that came before it.

In the rest of the book, we will use the “serverless” qualifier only for software that fits these criteria. For example, software that requires you to provide a server to host a website (like the Apache web server) would not qualify because it does not meet the first criterion. Software that is available as a service but requires you to pay by subscription (like Salesforce) would not qualify as well because it does not meet the second criterion. A serverless architecture, by extension, is one composed entirely of serverless components. But which components of an architecture need to be serverless for it to be called as such? Let’s look at this next with an example.

Just to clear up any misperceptions . . .

One of the common misunderstandings is that the “-less” in “serverless” implies “absence of or without” (think “sugarless,” “boneless,” and so on), which leads to some colorful debates on social media on how any application architecture can claim to run without servers. We think “-less” here means “invisible in context of usage” (think “wireless,” “tasteless”). There obviously are servers somewhere! The difference is that these servers are hidden from you. There’s no infrastructure for you to think about and no way to tweak the underlying operating system or virtual hardware configuration. Someone else takes care of the nitty-gritty details of infrastructure management, freeing you from that operational overhead and giving back to you the most expensive commodity there is—time.

1.2 Understanding serverless architectures

Let’s take the example of a typical data-driven web application, not unlike the systems powering most of today’s web-enabled software. These typically consist of a backend (server) that accepts requests from a client and then processes the requests.

The backend server performs various forms of computation, and the frontend client provides an interface for users to operate via their browser, mobile, or desktop device. Data might travel through numerous application layers before being saved to a database. The backend then generates a response that could be in the form of JSON or in fully rendered markup, which is sent back to the client (figure 1.1). These kinds of applications are conventionally architected as tiers (a presentation tier that controls how the information is captured and provided to the user, an application tier that controls the business logic of the application, and a data tier with the database and corresponding access controls).

Figure 1.1 A basic request-response (client-server) message-exchange pattern that most developers are familiar with. There’s only one web server and one database in this figure. Most systems are much more complex.

Software architectures have evolved from the days of code running on a mainframe to a multitier architecture where the presentation, data, and application/logic tiers are traditionally separated. Within each tier, there may be multiple logical layers that deal with the particular aspects of functionality or domain. There are also cross-cutting components such as logging or exception handling systems that can span numerous layers. The preference for layering is understandable. Layering allows developers to decouple concerns and have more maintainable applications. Figure 1.2 shows an example of a tiered architecture with multiple layers including the API, the business logic, the user authentication component, and the database.

Figure 1.2 A typical three-tier application is usually made up of presentation, application, and data tiers. A tier can have multiple layers with specific responsibilities.

Tiers vs. layers

There is some confusion among developers about the difference between layers and tiers. A tier is a module boundary that provides isolation between major components of a system. For example, a presentation tier that’s visible to the user is separate from the application tier, which encompasses the business logic. In turn, a data tier is another separate system that manages, persists, and provides access to data. Components grouped in a tier can physically reside on different infrastructures.

Layers are logical slices that carry out specific responsibilities in an application. Each tier can have multiple layers that are responsible for different elements of functionality, such as domain services.

1.2.1 Service-oriented architecture and microservices

One blunt approach would be to combine all the layers (the API, the business logic, the user authentication) into one single, monolithic code base. This may sound like an antipattern today, but that was indeed the approach we adopted in the early days of cloud-based development. Most modern approaches, however, dictate that you architect with reusability, autonomy, composability, and discoverability in mind.

Among the veterans of our industry, service-oriented architecture (SOA) is a well-known buzzword. SOA encourages an architectural approach in which developers create autonomous services that communicate via message passing and often have a schema or a contract that defines how messages are created or exchanged.

The modern incarnation of the service-oriented approach is often referred to as microservices architecture. Modern application architectures are composed of services communicating through events and APIs with business logic inserted as appropriate. We define microservices as small, standalone, fully independent services built around a particular business purpose or capability. Ideally, microservices should be easy to replace, with each service written in an appropriate framework and language.

The mere fact that microservices can be written in a different general-purpose language or a domain-specific language (DSL) is a drawing card for many developers. Benefits can be gained from using the right language or a specialized set of libraries for the job. Each microservice can maintain state and store data. And if microservices are correctly decoupled, development teams can work and deploy microservices independently from one another. This approach...