AWS Re:Invent 2018 — Serverless Shock Drops
Last week our API Services team attended the AWS Re:Invent Conference in Las Vegas. In between trips to the El Cortez Casino and the Bacchanal Buffet, it was quite the week.
Here at S23NYC we rely on AWS Serverless technologies — mostly Lambda and DynamoDB — to support the Nike SNKRS App and its admin tools. DynamoDB and Lambda definitely have their strongpoints: automatic scaling, thorough documentation, concise, easy to maintain business logic and fast iterative development and deployment. And best of all, they’re fully managed, allowing our lean team to turn out APIs effectively and with lightning fast turnaround. While no platform is without its quirks or drawbacks, a handful of announcements last week whittled away quite a few big ones.
API Gateway Web Sockets
This one’s a doozy. Because most of our APIs run on Lambda behind a VPC, other than running a socket server on an EC2 Cluster (no thanks) or using a third party service like Pubnub, there was no obvious solution to real-time client-server communication.
But now with the announcement of web socket support for API Gateway, deploying our own, fully managed socket service is easier than ever. API Gateway sends and accepts socket requests to and from the client, invoking stateless lambda functions as needed while connection information can be persisted through DynamoDB. For a deeper dive on this, there’s a great write-up on a simple chat client implementation over at serverless.com.
Lambda Layers and Custom Runtimes
We love Python! But hey, maybe it’s not your language of choice. Maybe you prefer a functional language like Haskell or you’re ride-or-die PHP. Maybe you’d prefer a compiled language like C# or Java that isn’t C# or Java. Well, in addition to newly announced supported runtimes for Rust, C++, and Ruby, AWS now allows custom runtimes for Lambda. If it runs on Unix, you can run it on Lambda.
Of course, simplicity and ease of deployment are big advantages with using Lambda so it’s recommended that you use the prepackaged runtimes provided by AWS whenever possible. The core component that enables these custom runtimes is the ability to share code across multiple functions with Lambda Layers. This can be leveraged for much more practical outcomes, such as speeding up your CI builds, shrinking the size of your deployment packages, or potentially reducing your function’s cold start times.
Say for instance you have a shared API wrapper for an often used third-party service across your various Lambda functions. You can create a Lambda Layer containing these packages and modules and configure your function to reference it by ARN. We ran a test with one of our services and the size of our deployment ZIP dropped from 28MB to 9K. Layers can be isolated to a single AWS account or publicly available to other AWS developers. Some companies, such as Datadog, have already announced their own publicly available Lambda Layers.
As with any system of dependency management, there are a few gotchas when it comes to using Lambda Layers. Layers are immutable, meaning in order to update a layer’s shared code a Lambda’s configuration needs to be updated to point at a new ARN. When deleting a Layer or revoking its use permissions, functions that were using that layer will still run, but you won’t be able to create new functions that use the deleted layer. It’s also important to note that the overall size of the function code, its custom runtime and any configured layers must comply with the usual deployment package size limit.
DynamoDB On Demand Capacity
A major challenge we face working on SNKRS is intense bursts of API traffic, usually the result of a high heat product launch with a feature like SNKRS Pass. Without allocating a prohibitively expensive base capacity, this has required logging in to AWS and manually raising the read and write allocations to prevent throttling and service timeouts. Not a huge deal if a drop falls in the middle of the day here on the East Coast, but when supporting launches in China or Japan it can be quite the bummer.
Now with DynamoDB On Demand, instead of specifying a maximum RCU and WCU and enabling adaptive capacity (which can take a few minutes to kick in, leading to temporary throttling) you can opt to pay per request. Just make sure you know what you’re getting into, as this bypasses any estimated cost predictions.
DynamoDB ACID Transactions
Speaking of DynamoDB, on the last day of the conference I ran into my Uncle Bob on my way to the casino. I had no idea that he was in town, and to be honest, I didn’t think he’d be be interested in NoSQL—he’s a software engineer for the FBI and I just assumed they use Oracle—but one thing we were both super excited about was the announcement of DynamoDB Transactions.
What does this mean? Prior to this announcement, DynamoDB met two of the four requirements of ACID: Consistency and Durability. Thanks to ConditionExpressions, Atomicity and Isolation applied, but only pertaining to updates to a single item or row. Now with transactions, we can specify conditional reads or writes across not only multiple rows of a table, but multiple rows in multiple tables.
This means we can now leverage one of the key advantages of relational databases without any of the downside like unmanaged concurrency or deadlocks. Yes, the recommended use cases for DynamoDB encourage single table designs, a key tenant of non-relational document-store patterns, but situations can arise over the course of an application’s lifetime where conditionally manipulating data across multiple tables becomes useful or even necessary.
Recommended Viewing
These are my 3 favorite talks from last week. For a deeper dive on any of these subjects check out the following:
