Let's start with the simpler of the two questions first—what is serverless computing? While there may be several ways to define serverless computing, or perhaps more accurately serverless architectures, most people can agree on a few key attributes. Serverless computing platforms share the following features:

• No operating systems to configure or manage
• Pay-per-invocation billing model
• Ability to automatically scale with usage
• Built-in availability and fault tolerance

While there are other attributes that come with serverless platforms, they all share these common traits. Additionally, there are other serverless systems that provide functionality other than general computing power. Examples of these are DynamoDB, Kinesis, and Simple Queue Service, all of which fall under the Amazon Web Services (AWS) umbrella. Even though these systems are not pay-per-invocation, they fall into the serverless category since the management of the underlying systems is delegated to the AWS team, scaling is a matter of changing a few settings, fault-tolerance is built-in, and high availability is handled automatically.

Arguably, this is where the term serverless came from and is at the heart of this entire movement. If we look back not too long ago, we can see a time when operations teams had to purchase physical hardware, mount it in a data center, and configure it. All of this was required before engineers even had the chance of deploying their software.

Cloud computing, of course, revolutionized this process and turned it upside down, putting individual engineers in the driver's seat. With a few clicks or API calls, we could now get our very own virtual private server (VPS) in minutes rather than weeks or months. While this was and is incredibly enabling, most of the work of setting up systems remained. A short list of things to worry about includes the following:

• Updating the operating system
• Securing the operating system
• Installing system packages
• Dealing with dependency management

This list goes on and on. A point worth noting is that there may be hours and hours of configuration and management before we're in a position to deploy and test our software.

To ease the burden of system setup, configuration software such as Puppet, Chef, SaltStack, and Ansible arrived on the scene. Again, these were and are incredibly enabling. Once you have your recipes in place, configuring a new virtual host is, most importantly, repeatable and hopefully less error-prone than doing a manual setup. In systems that comprise hundreds or even thousands of virtual servers, some automation is a requirement rather than a mere convenience.

As lovely as these provisioning tools are, they do come with a significant cost of ownership and can be incredibly time-consuming to develop and maintain. Often, iterating on this infrastructure-as-code tooling requires making changes and then executing them. Starting up a new virtual host is orders of magnitude faster than setting up a physical server; however, we measure VPS boot time and provisioning time in minutes. Additionally, these are software systems in and of themselves that a dedicated team needs to learn, test, debug, and maintain. On top of this, you need to continually maintain and update provisioning tools and scripts in parallel with any changes to your operating systems. If you wanted to change the base operating system, it would be possible but not without significant investment and updates to your existing code.

When Lambda was launched by AWS in 2014, a new paradigm for computing and software management was born. In contrast to managing your virtual hosts, AWS Lambda provided developers the ability to deploy application code in a managed environment without needing to manage virtual hosts themselves. Of course, there are servers running somewhere that are operated by someone. However, the details of these servers are opaque to us as application developers. No longer do we need to worry about the operating system and its configuration directly. With AWS Lambda and other Functions as a Service (FaaS) platforms, we can now delegate the work of VPS management to the teams behind those platforms.

The most significant shift in thinking with FaaS platforms is that the unit of measure has shrunk from a virtual machine to a single function.

Another significant change with the invention of serverless platforms is the pay-per-invocation model. Before this, billing models were typically per minute or hour. While this was the backbone of elastic computing, servers needed to stay up and running if they were used in any production environment.

Paying for a VPS only while it's running is a great model when developing since you can just start it at the beginning of the d``

ay and terminate it at the end of the day. However, when a system needs to be available all the time, the price you pay is nearly the same whether its CPU is at 100% usage or 0.0001% usage.

Serverless platforms, on the other hand, the bill only while the code is being executed. They are designed and shine for systems that are stateless and have a finite, relatively short duration. As such, billing is typically calculated based on a total invocation time. This model works exceptionally well for smaller systems that may get only a few calls or invocations per day. On many platforms, it's possible to run a production system that is always available completely for free. There is no such thing as idle time in the world of serverless.

Gone are the days of needing to overprovision a system with more virtual hosts than you typically need. As invocations ramp up, the underlying system automatically scales up, providing you with a known number of concurrent invocations. Moving this limit higher is merely a matter of making a support request to Amazon, in the case of AWS Lambda. Before this, managing horizontal scalability was an exercise for the team designing the system. Never has horizontal scalability for computing resources been so easy.

Different cloud providers provide the ability to scale up or down (that is, be elastic) based on various parameters and metrics. Talk to DevOps folks or engineers who run systems with autoscaling and they will tell you it's not a trivial matter and is difficult to get right.

Servers, real or virtual, can and do fail. Since the hosts that run your code are now of little or no concern for you, it's a worry not worth having.

Just as the management of the operating system is handled for you, so too is the management of failing servers. You can be guaranteed that when your application code should be invoked, it will be.

With a good understanding of serverless computing behind us, let's turn our attention to design patterns.

If you've spent any amount of time working with software, you will have heard the term design pattern and may very well be familiar with them to some degree. Stepping back slightly, let's discuss what a design pattern is.

I will assert that if you ask 10 different developers to define the term design pattern, you will get 10 different answers. While we all may have our definition, and while those definitions may not be wrong, it's relatively simple to agree on the general spirit or idea of a software design pattern. Within the context of software engineering, design patterns are reusable solutions or code organization applied to a frequently occurring problem. For example, the Model-View-Controller pattern evolved to solve the problem of GUI applications. The Model-View-Controller pattern can be implemented in almost any language for nearly any GUI application.

Software design patterns evolved as a solution to help software authors be more efficient by applying well-known and proven templates to their application code. Likewise, architectural patterns provide the same benefits but at the level of the overall system design, rather than at the code level.

In this book, we won't be focusing on software design, but rather architectural design in serverless systems. In that vein, it's worth noting that the context of this book is serverless architectures and our patterns will manifest themselves as reusable solutions that you can use to organize your functions and other computing resources to solve various types of problem on your serverless platform of choice.

Of course, there is an infinite number of ways to organize your application code and hundreds of software and architectural patterns you can use. The primary focus here is the general organization or grouping of your functions, how they interact with one another, the roles and responsibilities of each function, and how they operate in isolation but work together to compose a larger and more complex system.

As serverless systems gain traction and become more and more popular, I would expect serverless patterns such as those we will discuss in this book to grow in both popularity and number.

Many types of computing problem can be solved with a serverless design. Personally speaking, I have a hard time not using serverless systems nowadays due to the speed, flexibility, and adaptability they provide. The classes of problem that are suitable for serverless systems are extensive. Still, there is a sweet spot that is good to keep in mind when approaching new problems. Outside of the sweet spot, there are problems that are not a good fit.

Since serverless systems work on the basis of a single function, they are well suited to problems that are, or can be broken down into, the following subsystems:

• Stateless
• Computationally small and predictable

Serverless functions are ephemeral; that is, they have a known lifetime. Computation that is itself stateless is the type of problem where FaaS platforms shine. Application state may exist, and functions may store that state using a database or some other kind of data store, but the functions themselves retain no state between invocations.

In terms of computing resources, serverless functions have an upper bound, both in memory and total duration. Your software should have an expected or predictable upper limit that is below that of your FaaS provider. At the time of writing, AWS Lambda functions have an upper bound of 1,536 MB for memory and 300 seconds in duration. Google Compute advertises an upper limit of 540 seconds. Regardless of the actual values, systems, where you can reliably play within these bounds, are good candidates for moving to serverless architecture.

A good, albeit trivial, an example of this would be a data transformation function—given some input data, transform it into a different data structure. It should be clear with such a simple example that no state needs to be or is carried between one invocation and the next. Of course, data comes in various sizes, but if your system is fed data of a predictable size, you should be able to process the data within a certain timeframe.

In contrast, long-running processes that share state are not good fits for serverless. The reason for this is that functions die at the end of their life, leaving any in-memory state to die with them. Imagine a long-running process such as an application server handling WebSocket connections.

WebSockets are, by definition, stateful and can be compared to a phone call—a client opens up a connection to a server that is kept open as long as the client would like. Scenarios such as this are not a good fit for serverless functions for the two following reasons:

• State exists (i.e., state of a phone call is connected or disconnected)
• The process is long-lived because the connection can remain open for hours or days

Whenever I approach a new problem and begin to consider serverless, I ask myself these two questions:

• Is there any global state involved that needs to be kept track of within the application code?
• Is the computation to be performed beyond the system limits of my serverless platform?

The good news is that, very often, the answer to these questions is no and I can move forward and build my application using a serverless architecture.

In this book, we'll discuss four major classes of serverless design pattern:

• Three-tier web application patterns
• Extract, transform, load (ETL) patterns
• Big data patterns
• Automation and deployment patterns

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:

• Content Delivery Network (CDN) for presentation code/static assets (HTML, JavaScript, CSS, and so on)
• Database for persistence
• Serverless functions for application logic

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:

• Extracting data from one data source
• Transforming that data appropriately
• Loading the processed data into another data source

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 healthy software 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.

With the advent of serverless platforms came the creation of multiple frameworks to help us manage our serverless applications. Just as Ruby on Rails, Spring, Django, Express, and other web frameworks aid in the creation and management of web applications, various serverless frameworks have sprung up that make the software development lifecycle easier for serverless applications.

An essential difference between web frameworks and serverless frameworks is that serverless frameworks often help with the management of application code on a serverless platform. In contrast, much of the help web frameworks provide revolves around web logic and tasks such as the following:

• Producing HTML output via templating engines
• Managing database records via Object Relational Mappers (ORMs)
• Validating submitted form data
• Dealing with the details of HTTP requests and responses

Not all applications that run on a serverless platform are HTTP-based. Therefore, serverless frameworks do not necessarily have application-specific functionality baked in but, instead, they have deployment and management functionality. Some frameworks do target web developers and aid in web-centric tasks; however, there are several other frameworks that do not and instead focus on managing arbitrary application code.

A few popular serverless frameworks worth noting are the following:

• Apex
• Serverless
• ClaudiaJS
• Kappa
• SAM (Serverless Application Model from AWS)
• Chalice (from AWS)
• Zappa

Throughout this book, I'll be using a serverless framework to manage application code and the entire stack of resources that we will deploy during the examples. Serverless works with a variety of programming languages and various platforms, such as AWS, Azure, Google Compute Cloud, and IBM Open Whisk. We will build all of our examples using AWS, but the patterns discussed should apply to other cloud providers unless explicitly noted otherwise. Since serverless frameworks such as Zappa don't give us any web-specific functionality, we will be responsible for some of the lower-level web application details in Chapter 2, A Three-Tier Web Application Using REST, and Chapter 3, A Three-Tier Web Application Pattern with GraphQL.

In this introduction, we covered the main points regarding serverless platforms and discussed the attributes that make a system serverless. We covered the main differences between building software on top of self-managed systems, either physical or virtual, compared to building software systems on a serverless platform. Additionally, readers should have a clearer perspective of when serverless architectures are a good fit and when they are not.

We also reviewed the main categories of design pattern that I will cover in this book and gained a high-level overview of each one. Finally, I covered the differences between web and serverless frameworks and gave some examples of the latter.

With the stage set, we can jump into our first pattern with a real-world example. By the end of Chapter 2, A Three-Tier Web Application Using REST, we will have produced a complete three-tier web application using REST API, all with serverless technologies.