One of the biggest challenges in serverless development is identifying which of the myriad of services offered is the right one for your use case. With over 100 services, AWS offers solutions to every problem — usually multiple solutions! In this article, we’ll review some of the top contenders for Serverless Guru and how we might use them.

AWS AppSync

Per AWS: AWS AppSync is a serverless back-end for mobile, web, and enterprise applications. AppSync creates a GraphQL implementation and provisions resources to access it, including client-side implementation of offline data access. It supports existing AWS services (such as DynamoDB for data and Cognito for access control) and intelligently creates schemas in cases where you already have those resources. AWS AppSync — Build data-driven apps with real-time and offline capabilities based on GraphQL

Why do we use it?

AppSync allows for a simple approach to several complex issues including offline data access, GraphQL support, access control, data searching and filtering, and resource management. It effectively cuts a large slice of the work out of setting up your app while giving you an even larger slice of convenient and useful features.

But what does this mean for serverless development?

AppSync effectively reduces the lift needed to design and build data-driven applications. Something like a news app with a serverless backend would normally require setting up several Lambdas, struggling with auth, custom offline access integrations, complicated access control code, etc. And that’s not even looking at a GraphQL implementation!

AWS Lambda

Per AWS: AWS Lambda lets you run code without provisioning or managing servers. Doesn’t that sound wonderful? Being able to set up some small function that does one explicit job, but not needing to manage an EC2 and all the fun that comes with that. Highly configurable: memory, time allocation, language, permissions, networking — all a click or two to get what you want. Lambda can power a surprisingly large portion of apps, and with every update to the service, the use cases grow. For instance, recent changes have allowed up to 3008MB of memory and 15 minutes of execution time per invocation, as well as the ability to use just about any language you like with custom runtimes. AWS Lambda — Serverless Compute — Amazon Web Services

Why do we use it?

Aside from removing the management of servers? Lambda allows for particularly fast iterations in code — deployment happens in a matter of seconds. It’s also incredibly well suited to power HTTP APIs through AWS API Gateway (First Serverless Project), and AWS has made it rather easy to set this up. Lambda functions also have powerful and easy access control, via IAM policies. VPC setup couldn’t be easier. Concurrency is handled by AWS and available right there in the console to configure yourself.

But what does this mean for serverless development?

One of the more common use cases is creating an HTTP API via Lambda, API Gateway, and DynamoDB. When a request to your API Gateway endpoint is initiated, it passes the request through to your Lambda function, which takes the request (referred to as the event in Lambda) and executes whatever action is necessary (in this case, imagine we’re querying our DynamoDB table for a user). It then returns the data via HTTP to the user.

A non-serverless version of this exact same model would require an EC2 with an HTTP server to handle routing and non-trivial amounts of code to power things. Iteration speed would decrease significantly, as changing the code behind /users would usually require re-deploying your entire code base — even if you didn’t touch /posts. With Lambda, /users could be one function, while /posts could be another. Changing the functionality of /users wouldn’t require any changes to /posts. Regression testing for your team just got much easier!

AWS DynamoDB

Per AWS: Amazon DynamoDB is a key-value and document database that delivers single-digit millisecond performance at any scale. It’s a fully managed, multi-region, a multimaster database with built-in security, backup and restores, and in-memory caching for internet-scale applications. DynamoDB can handle more than 10 trillion requests per day and support peaks of more than 20 million requests per second. Essentially, this means DynamoDB is a NoSQL database capable of most any level of scaling you could imagine. It’s suitable for everything from your app with 3 users up to…well, I think you’d be hard-pressed to find the upper limit with it. Amazon DynamoDB — Overview

Why do we use it?

DynamoDB is fast, scalable, robust, and flexible in implementation. For many use cases, it can be a cheaper alternative to using AWS RDS, while also being much faster (generally, though not ALWAYS true). It doesn’t tie you to a relational model (though you can still use relational data if you wish). It doesn’t use SQL. It works for simple key/value data, large document storage, and everything in between.

But what does this mean for serverless development?

Despite some caveats around cost (especially considering throughput on large tables that are used often), it is generally a faster, easier, more scalable option than anything else. And referring back to Lambda: iteration speed is incredible. Unlike the rigid structure of SQL databases, DynamoDB allows for arbitrary property (aka column) names and types, and nuking and re-creating a table in the middle of development is just a few clicks. Got the index key as a string but now realize it should be a number? No problem! Just re-create your table and be going again in 10 seconds — with no SQL (NoSQL, get it?) involved! And to circle back to scaling: it’s dead simple and highly configurable, such that you could easily create a custom timer solution to scale your table throughput very low in off hours and higher during peak hours. With RDS, you’d be stuck with a static cost per hour and just turn the database off if you wanted to cut costs at night (or use Aurora Serverless and struggle with 30 second startup times and writing SQL queries).

AWS X-Ray

Per AWS: AWS X-Ray helps developers analyze and debug production, distributed applications, such as those built using a microservices architecture. Essentially, X-Ray gives us the ability to see what our connected web of AWS services is doing at each step to help us identify performance issues and edge cases. X-Ray | Tracing | AWS

Why do we use it?

One of the common complaints regarding the serverless model is the innate complexity added to debugging when your app is a set of distributed services. Whereas if your app runs on a single server you have all of your information in one place if your app runs on 20 services you have to gather bits and pieces from logs here and metrics there to try to assemble the big picture together. X-Ray gives us the ability to drop-in tracking on whatever we may need, whether it’s tracking DynamoDB scan speeds to figure out if you need to modify your dataset or tracking function execution time to know if certain file processing is causing slowdown for your users.

But what does this mean for serverless development?

As stated before, X-Ray helps address one of the larger concerns around a serverless architecture. End to end tracking of your entire stack allows you to discover and squash hard to find bugs without having to dig and go from log to log comparing timestamps and trying to overlay that against a metric graph.

AWS SQS

Per AWS: Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. SQS is a simple to use message and queue system. Messages can be used as triggers for other services, such as Lambda functions. Amazon Simple Queue Service (SQS) | Message Queuing for Messaging Applications | AWS

Why do we use it?

Other than it’s obvious use as a message queue, SQS really shines — for me — when used as a trigger for Lambda functions. You can effectively set up a recursive Lambda function with the addition of an SQS queue. Imagine you were doing some kind of data processing on a large array of files, and some files might have URLs linking to other files. You could send each file reference in as a message to SQS that triggers your Lambda, and each newly discovered file is added to the queue as well which triggers another Lambda. Your function executes against messages until the queue is empty, removing a lot of the async woes around chained Lambda executions. SQS also offers a FIFO queue (first in first out, IE process specifically in order of messages), which — while it can’t be used as a Lambda trigger — is very useful when the order of your messages matters. A use case for this would be if you had a series of dynamically generated queries to run against a database that needed to be run in a specific order. Set up a poller to grab messages and process them one by one.

But what does this mean for serverless development?

One of the biggest advantages SQS gives us in serverless development is the ability to batch. Batch operations in serverless (looking at you, Lambda functions) are one of the more common pain points. Lambda functions don’t run long enough for most batched operations or are difficult to configure to operate on specific batch size. When setting up your trigger, you can specify a batch size in the config. If you set it to 10 messages, your function won’t be invoked until there are 10 messages in the queue. This removes a lot of config and logic around when to execute, as well as the actual invocation itself — added benefit here of more modular components of the app. There’s really a lack of bad use cases for SQS, it’s very powerful and straightforward in use.

AWS SNS

Per AWS: Amazon Simple Notification Service (SNS) is a highly available, durable, secure, fully managed pub/sub messaging service that enables you to decouple microservices, distributed systems, and serverless applications. An appropriate question here (after reading about SQS) is “how is SNS different from SQS”? SNS uses a publish/subscribe system and has no queue, as well as features that allow sending push notificationsemailsSMS. With powerful filtering abilities, a large list of compatible services, and robust built-in security SNS offers a hearty helping of event-driven processing. Amazon Simple Notification Service (SNS) | AWS

Why do we use it?

One of the more common use cases for SNS is sending an email or text alerts, such as when a specific error is thrown in your app or when a resource has completed its task. Considering the wide variety of services it can connect to, it could be used for any number of notifications. Invoke Lambda functions when your RDS instance finishes a backup, push to an SQS queue when objects are put into S3, push notifications to user devices when your dataset is finished updating, or use the fanout concept and publish messages to multiple subscribers on an event.

But what does this mean for serverless development?

Getting an email when a scheduled job fails can save a lot of headaches. A pattern I often use is to send an email containing the error message and where the error occurred for mission-critical jobs, especially ones that run in the background and are easy to forget to check. If you’re building a mobile app the push notification abilities are invaluable. Sending SMS messages to users when events happen, CloudWatch metric alerts, RDS alerts…the use cases are wide.

AWS Cognito

Per AWS: Amazon Cognito lets you add user sign-up, sign-in, and access control to your web and mobile apps quickly and easily. Cognito is a user/identity management service, allowing for a much less painful auth setup. It can also incorporate federated login via Facebook, Google, and Amazon (as in amazon.com, not AWS) — or even your own custom OAuth solution! Amazon Cognito — Simple and Secure User Sign Up & Sign In | Amazon Web Services (AWS)

Why do we use it?

Safe and secure user management is hard to come by. Setting up your own OAuth server is complicated and very easy to do incorrectly. Adding federated Google login is not usually as easy as it should be. Cognito addresses all these issues, giving us a relatively easy to configure auth platform. Using groups and preferred IAM roles Cognito also gives us the ability for fine-grained access to AWS services or parts of our app.

But what does this mean for serverless development?

In a recent app scoping I was part of using a custom OAuth solution vs Cognito was estimated to be a 20+ hour difference, with a non-zero cost difference due to the extra services needed for a custom implementation. Should the client want to enable Google federated sign-in in the future, retooling our entire auth service won’t be required. Management of passwords is out the window for us, removing what will almost always be some security risk. Adding access control to admin tools is as simple as setting up an IAM role for the admin group with the proper permissions. Resetting passwords is a simple API call away. Cognito has — simply put — removed 90% of the work and worry from user auth.