Web applications with the traditional request/response cycle are a sweet spot for serverless systems. Because serverless functions are short-lived, they lend themselves well to problems that are themselves short-lived and stateless. We have seen stateful systems emerge and become popular, such as WebSockets; however, much of the web and web applications still run in the traditional stateless request/response cycle. In our first set of patterns, we'll build different versions of web application APIs.

While there are three different patterns to cover for web applications, they will all share a common basis, which is the three-tier model. Here, the tiers are made up of the following:

REST APIs should be a common and familiar tool for most web developers. In Chapter 2, A Three-Tier Web Application Using REST, we'll build out a fully featured REST API with a serverless design. This API will have all of the methods you'd expect in a classic REST API—create, read, update, delete (CRUD).

While REST APIs are common and well understood, they do face some challenges. After starting with a serverless REST API, we'll walk through the process of designing the changes needed to make that same API work as a single GraphQL endpoint that provides the same functionality in Chapter 3, A Three-Tier Web Application Pattern with GraphQL.

Finally, in Chapter 4, Integrating Legacy APIs with the Proxy Pattern, we'll use a proxy pattern to show how it's possible to completely change an API  but use a legacy API backend. This design is especially interesting for those who would like to get started migrating an API to a serverless platform but have an existing API to maintain.

ETL patterns is another area of computing that lends itself very well to serverless platforms. At a high level, ETL jobs comprise the following three steps:

Often used in analytics and/or data warehousing, ETL jobs are hard to escape. Since this problem is again ephemeral and because users would probably like their ETL jobs to execute as quickly as possible, serverless systems are a great platform in this problem space. While serverless computation is typically short-lived, we will see how ETL processes can be designed to be long-running in order to work through large amounts of data.

In the fan-out pattern, discussed in Chapter 5, Scaling Out with the Fan-Out Pattern, a single unit of work will be broken up into multiple smaller units of work and processed in parallel. This pattern may be used as a standalone system or as a subcomponent in a more extensive system. We'll build out an application using the fan-out pattern in isolation, but later discuss how it can work as a piece in a more extensive system.

Messaging patterns themselves can be an entire class of design pattern. In our context, we will show how to use this as a general pattern to process data asynchronously with a known or fixed amount of processing power. Chapter 6,Asynchronous Processing with the Messaging Pattern, will walk through a full example of this pattern and its variants in a serverless context.

It may seem confusing that lambda can refer to both AWS Lambda functions as well as a pattern in and of itself. The lambda pattern was born from the need to analyze large amounts of data in real time. Before this, the big data movement, where large batch jobs would run to calculate and recalculate things, was in full swing. The problem faced by this movement was that these batch jobs, in order to get the latest results, would need to spend the majority of their computing resources recalculating metrics on data that hadn't changed.

The lambda pattern, which we will discuss in Chapter 7, Data Processing Using the Lambda Pattern, creates two parallel planes of computation, a batch layer, and a speed layer. The naming of these layers should give you an idea of what they're responsible for.

MapReduce is another well-known and tested paradigm that has been popular in the software world for some time now. Hadoop, arguably the most famous framework for MapReduce, helped to bring this pattern front and center after Google's original MapReduce paper in 2004.

As amazing as Hadoop is as a software system, there are substantial hurdles to overcome in running a production Hadoop cluster of your own. Due to this, systems such as Amazon's Elastic MapReduce (EMR) were developed, which provide on-demand Hadoop jobs to the developer. Still, authoring Hadoop jobs and managing the underlying computing resources can be non-trivial. We'll walk through writing your serverless MapReduce system in Chapter 8, The MapReduce Pattern.

Many of us are used to logging onto a machine via ssh and grepping through log files to look for problems. Our worlds are now turned upside down since there are no longer any servers to SSH into. Fortunately, there are methods of handling errors and getting the information needed to debug and monitor your programs. 

In Chapter 9, Deployment and CI/CD Patterns, we'll focus on error handling, as well as some of the dos and don'ts of serverless systems and what modern-day best practices look like in the serverless world. Many development practices change when building on top of a serverless platform and there are a lot of gotchas that, if you're unfamiliar with them, may surprise you. Chapter 9, Deployment and CI/CD Patterns, will walk through some of the biggest issues that may bite you if you're brand new to this ecosystem.

While some tooling and techniques may change, let's not forget a healthysoftware development life cycle consists of well-structured code, continuous integration (CI), continuous deployment (CD), and unit tests. Coupled with the myriad of hosted CI/CD platforms, running tests and deploying code automatically is quite painless and even fun. In Chapter 10, Deployment and CI/CD Patterns will discuss various options and examples with hosted CI and CD platforms. I'm confident that you'll find the velocity at which you can ship code using serverless technologies exciting and enabling.