What Do Serverless Applications Look Like?

Chapter 2. What Do Serverless Applications Look Like?

Link

Now that we’re well grounded in what the term Serverless means, and we have an idea of what various Serverless components and services can do, how do we combine all of these things into a complete application? What does a Serverless application look like, especially in comparison to a non-Serverless application of comparable scope? These are the questions that we’re going to tackle in this chapter.

A Reference Application

The application that we’ll be using as a reference is a multiuser, turn-based game. It has the following high-level requirements:

Mobile-friendly user interface

User management and authentication

Gameplay logic, leaderboards, past results

We’ve certainly overlooked some other features you might expect in a game, but the point of this exercise is not to actually build a game but to compare a Serverless application architecture with a legacy, non-Serverless architecture.

Non-Serverless Architecture

Given those requirements, a non-Serverless architecture for our game might look something like Figure 2-1:

• A native mobile app for iOS or Android

• A backend written in Java, running in an application server, such as JBoss or Tomcat

• A relational database, such as MySQL

In this architecture, the mobile app is responsible for rendering a gameplay interface and handling input from the user, but it delegates most actual logic to the backend. From a code perspective, the mobile app is simple and lightweight. It uses HTTP to make requests to different API endpoints served by the backend Java application.

User management, authentication, and the various gameplay operations are encapsulated with the Java application code. The backend application also interacts with a single relational database in order to maintain state for in-progress games, and store results for completed games.

Why Change?

This simple architecture seems to meet our requirements, so why not stop there and call it good? Lurking beneath those bullet points are a host of development challenges and operational pitfalls.

In building our game, we’ll need to have expertise in iOS and Java development, as well as expertise in configuring, deploying, and operating Java application servers. We’ll also need to configure and operate the relational database server. Even after accounting for the application server and database, we need to configure and operate their respective host systems, regardless of whether those systems are container-based or running directly on virtual or physical hardware. We also need to explicitly account for network connectivity between systems, and with our users out on the Internet, through routing policies, access control lists, and other mechanisms.

Even with that laundry list of concerns, we’re still just dealing with those items necessary to simply make our game available. We haven’t touched on security, scalability, or high availability, which are all critical aspects of a modern production system. The bottom line is that there is a lot of inherent complexity even in a simple architecture that addresses a short list of requirements. Building this system as architected is certainly possible, but all of that complexity will become friction when we’re fixing bugs, adding features, or trying to rapidly prototype new ideas.

How to Change?

Now that we’ve uncovered some of the challenges of our legacy architecture, how might we change it? Let’s look at how we can take our high-level requirements and use Serverless architectural patterns and components to address some of the challenges of the previous approach.

As we learned in Chapter 1, Serverless components can be grouped into two areas, Backend as a Service and Functions as a Service. Looking at the requirements for our game, some of those can be addressed by BaaS components, and some by FaaS components.

The Serverless Architecture

For example, while the user interface will remain a part of the native mobile app, user authentication and management can be handled by a BaaS service like AWS Cognito. Those services can be called directly from the mobile app to handle user-facing tasks like registration and authentication, and the same BaaS can be used by other backend components to retrieve user information.

With user management and authentication now handled by a BaaS, the logic previously handled by our backend Java application is simplified. We can use another component, AWS API Gateway, to handle routing HTTP requests between the mobile app and our backend gameplay logic in a secure, scalable manner. Each distinct operation can then be encapsulated in a FaaS function.

Those backend FaaS functions can interact with a NoSQL, BaaS database like DynamoDB to manage gameplay state. In fact, one big change is that we no longer store any session state within our server-side application code, and instead persist all of it to the NoSQL store. While this may seem onerous, it actually significantly helps with scaling.

That same database can be seamlessly accessed by the mobile application to retrieve past results and leaderboard data. This allows us to move some business logic to the client rather than build it into the backend.

What Got Better?

This new Serverless architecture that we’ve described looks complicated, and it seems to have more distinct application components than our legacy architecture. However, due to our use of fully-managed Serverless components, we’ve removed many of the challenges around managing the infrastructure and underlying systems our application is using.

The code we write is now focused almost entirely on the unique logic of our game. What’s more, our components are now decoupled and separate, and as such, we can switch them out or add new logic very quickly without the friction inherent in the non-Serverless architecture.

Scaling, high availability, and security are also qualities that are baked into the components we’re using. This means that as our game grows in popularity, we don’t need to worry about buying more powerful servers, wonder if our database is going to fall over, or troubleshoot a firewall configuration.

In short, we’ve reduced the labor cost of making the game, as well as the risk and resource costs of running it. All of its constituent components will scale flexibly. And if we have an idea for a new feature, our lead time is greatly reduced, so we can start to get feedback and iterate more quickly.