Decreased operational responsibilities

Serverless architectures typically allow you to shift more of your operational responsibilities to a cloud provider or third party.

When you decide to implement FaaS, the only thing you should have to worry about is the code running in your function. All of the server patching, updating, maintaining, and upgrading is no longer your responsibility. This goes back to the core of what cloud computing and by extension serverless attempts to offer—a way to spend less time managing infrastructure and spend more time building features and delivering business value.

Heavy use of managed services

When leveraging managed services, the services usually assume responsibility for providing a defined set of services and are serverless in the sense that they do not require any server operations, scale seamlessly, and require no need to manage uptime but most importantly they are essentially codeless.

Scalable

One of the primary advantages of going serverless is out of the box scalability. When building your application you don’t have to worry about what would happen if your application becomes wildly popular and you onboard a large amount of new users, the cloud provider handles this for you.

The cloud provider automatically scales your application, running the code in response to each interaction. In a serverless function, your code runs in parallel and individually processes each trigger (in turn scaling with the size of the workload).

Not having to worry about scaling your servers and databases is indeed great. It’s one less thing you have to worry about when architecting your application.

Cost

Serverless architectures differ greatly in the pricing model from traditional cloud based or on premises infrastructure.

With the traditional approach you were often paying for computing resources whether or not they were being utilized. This meant that if you wanted to make sure your application would scale you needed to prepare for the largest workload you thought you might see regardless if it actually reached that amount. At the end of the day this traditional approach meant you are paying for unused resources the majority of the life of your application.

With serverless technologies, you pay only for what you use. With FaaS, you’re billed based on the number of requests for your functions and the the time it takes for your function code to execute. With managed services like Amazon Rekognition for example, you only get charged for the images processed, minutes of video processed, etc.., again only paying for what you use.

This allows you to build features and applications with essentially no up-front infrastructure costs. Only if your application begins seeing large adoption and scale do you begin to have to pay for the service.

The bill from your cloud provider is only one part of the total cost of your cloud infrastructure, there’s also the operations’ salaries. That cost decreases if you have fewer ops resources.

There’s also development costs. Building applications in this way facilitates a faster time to market, decreasing overall development time and therefore development cost.

Developer Velocity

With less features to build, developer velocity increases. Being able to spin up the types of features that are typical for most applications (databases, authentication, storage, APIs) quickly and with a much smaller up-front time investment allows you to more quickly get to writing the core functionality and business logic for the features that you want to deliver.

Experimentation

When you are not investing a lot of time building out repetitive features you are able to experiment more easily and with less risk.

When shipping a new feature you often assess the risk (time and money involved with building the feature) with the possible return on investment (ROI). As the risk involved with trying out new things goes down you are free to test out ideas that in the past may have not seen the light of day.

We are also enabled to a/b test different ideas much more easily.

Security and Stability

Because the services that you are subscribing to are the core competency of the service provider you are getting something that is much more polished and usually more secure than you could have built ourselves.

Imagine a company that’s core business model is focusing on delivering a pristine authentication service and has been iterating on it for years, having dealt with and fixed issues for thousands of companies and customers.

Now, imagine trying to replicate a service like that within your own team or organization. While completely possible and feasible, chances are that choosing the service built and maintained by people who’s only job is to build and maintain that exact thing is a safer and more secure bet.

Another main focus of these service providers is to simply have the least amount of downtime possible. This means that they are taking on the burden of not only building, deploying, and maintaining these services, but also doing everything it they can to make sure that they are stable and do not go down.

Less Code

Most engineers will agree that at the end of the day code is a liability. The only thing that has value is the feature that the code delivers, not the code itself. When you find ways deliver these features while simultaneously limiting the amount of code you have to maintain, and even doing away with the code completely, you are reducing overall complexity in your application.

With less complexity comes less bugs, easier onboarding for new engineers, and overall less cognitive load for those maintaining and adding new features.

A developer can hook into these services and implement features with no knowledge of the actual back-end implementation, and with little to no back-end code at all.

Serverless Framework

One of the first and most popular serverless frameworks is the Serverless Framework. The Serverless Framework is a free and open-source framework, launched in October 2015 originally under the name JAWS, and written using Node.js.

At first the Serverless Framework only supported AWS, but then adding support for cloud providers like Google and Microsoft Azure among others.

The Serverless Framework utilizes a combination of a configuration file (serverless.yml), CLI, and function code to provide a nice experience for people wanting to deploy serverless functions to the cloud from a local environment.

When getting up and running with the Serverless Framework there can be a somewhat steep learning curve especially for developers new to cloud computing. There is a lot of terminology to know and a lot to understanding of how the cloud services work needed in order to build anything more than just a “Hello World” application.

Overall the Serverless Framework is a good option if your managing and working with a large number of cloud functions and are looking for something that doesn’t just work with AWS.

AWS SAM (AWS Serverless Application Model)

The AWS Serverless Application Model (AWS SAM) is an open-source framework, built and maintained by AWS and the community, that was released on Nov 18, 2016. This framework only supports AWS.

SAM allows you to build serverless applications by defining the API Gateway APIs, AWS Lambda functions, and Amazon DynamoDB tables needed by your serverless application in YAML files. It uses of a combination of YAML configuration, function code, and a CLI to create, manage and deploy serverless applications.

One advantage of SAM is that it is an extension of CloudFormation which is very powerful and allows you to do almost anything in AWS. This can also be a disadvantage to developers new to cloud computing and not familiar with AWS services, permissions, roles, and terminology.

SAM is a good choice if you are familiar with AWS and are only deploying your serverless applications to AWS.

Amplify Framework

The Amplify Framework is a combination of 4 things: CLI, client library, tool-chain, and hosting platform. The focus of Amplify is to provide an easy way for developers to build and deploy full stack web and mobile applications that leverage the cloud.

Amplify not only enables features like serverless functions and authentication, but also GraphQL APIs, machine learning, storage, analytics, push notifications, and more. Amplify provides an easy entry-point into the cloud by doing away with terminology and acronyms that may be unfamiliar to newcomers to AWS by using a category name approach for referring to services. Instead of referring to the authentication service as Amazon Cognito it’s referred to as auth and the framework just uses Amazon Cognito under the hood.

How do the 4 pieces fit together?

• The CLI allows you to create, configure and deploy cloud services from your command line.

• The Client library allows you to connect to and interact with the cloud services from your web or mobile application.

• The tool-chain helps facilitate and speed development by doing things like generating code and serverless function boilerplates.

• The hosting platform allows you to deploy your application to a live domain complete with atomic deployments, continuous integration, and continuous deployment.

Other Options

There are more and more companies providing abstractions over serverless functions, usually intending to improve the negative user experience traditionally associated with working directly with AWS Lambda.

A few other popular ones are Apex, Zeit Now, and Netlify Functions.

Many of these tools and frameworks still actually use AWS or some other cloud provider under the hood, so you are essentially going to be paying more in exchange for what they argue is a better user experience.

Most of these tools do not offer much of the other suite of services available from AWS or other cloud providers, things like authentication, AI and ML services, complex object storage, and analytics may not be part of their offerings.

If you are interested in seeing other ways of developing serverless applications, I would recommend checking these out.

Amplify Client

Building full stack applications requires a combination of both client-side tooling and back end services. In the past, the main way to interact with AWS services was using one of the AWS SDKs (Java, .NET, Node.js, Python, etc..). These SDKs work great, but none of them are particularly well-suited for client-side development. Before Amplify there was no easy way to build client-side applications using AWS. If you look at the documentation for the AWS Node.js SDK you’ll also notice that it is steep learning curve for developers new to AWS.

The Amplify Client is a library made especially to provide an easy to use API for JavaScript applications that need to interact with AWS services.

The approach that the Amplify Client takes is to provide a higher level of abstraction and bake in best practices to provide a declarative, easy to use API while still giving you full control over the interactions with your back end. It’s also built especially for the client in mind, with features like websocket and GraphQL subscription support. It utilizes localStorage for the browser and AsyncStorage for React Native to store security Tokens like IdTokens and AccessTokens to persist user authentication.

Amplify also has support for popular front end and mobile frameworks including React, React Native, Vue, Angular, Ionic, Native Android, and Native iOS. These framework-specific components allow you to quickly get up and running with common features like authentication and complex object storage and retrieval without having to build out the front-end UI and deal with state.

The Amplify framework does not support the entire suite of AWS services; instead it supports a subset of them with almost all of them falling into the category of serverless. Using Amplify, it wouldn’t make much sense to offer support for interacting with with EC2 but it makes a lot of sense to offer robust support for working with serverless functions and APIs.

With Amplify they have created an end-to end solution to fill a gap that previously was not filled, and in doing so created a new way to build full stack applications that has never really been seen before.

AWS AppSync

AWS AppSync is a managed API layer that uses GraphQL to make it easy for applications to interact with any data source, REST API, or microservice.

One of the most important parts of an application is the API layer. Modern applications typically interact with a large number of back end services and APIs; things like databases, managed services, third party APIs and storage solutions among others. This is usually referred to as a microservice architecture, when a large application is built using a combination of modular components or services.

One challenge with working with a microservice architecture is that most of the services and APIs will have varying implementation details. This leads to inconsistent and sometimes messy code as well as more cognitive load on the front end developers that are making requests to these APIs.

One good approach to working with a microservice architecture is to provide a consistent API gateway layer that then takes all of the requests and forwards them on to the back end services. This allows a consistent interaction layer for your client to interact with, making development easier on the front end.

GraphQL, a technology created and open-sourced by Facebook, offers an especially good abstraction for creating an API gateway. GraphQL introduces a defined and consistent specification for interacting with APIs in the form of three operations: Queries (reads), Mutations(writes / updates), and Subscriptions(real-time data). These operations are defined as part of a main Schema that also provides a contract between the client and the server in the form of GraphQL Types.

GraphQL operations are not bound to any specific data source so you as a developer are free to use them to interact with anything from a database to an HTTP endpoint or microservice to even a serverless function.

Typically when building a GraphQL API you need to deal with building, deploying, maintaining, and configuring your own API. With AWS AppSync, you can instead offload the server management as well as the security to AWS.

Modern applications also have concerns such as real-time data and offline support. Another benefit of AppSync is that it has built-in support for offline (AWS AppSync GraphQL Client) as well as real-time(GraphQL subscriptions) to enable developers to build these types of applications.

In this book, you will be using AWS AppSync along with various data sources (like DynamoDB for NoSQL and AWS Lambda for serverless functions) as the main API layer.