Did you get your re:Invent holiday wish?
This is the latest edition of our newsletter. To receive the email version please subscribe here.
So another AWS re:Invent has come and gone and .. well, we've almost recovered. It was, as expected, another fascinating and stimulating week. We spent most of our time chatting to various folk about what they are doing with AWS now, and where they hope to proceed in 2019. AWS, for many organizations, is becoming the core, trusted, platform of how they work. And with the number of feature and product announcements made in November, AWS is becoming ever more valuable, and yet an also ever more vast world to work most effectively with.
If you'd like some help navigating the treasure trove / mine field that is this expanding AWS world then drop us a line! We have availability in Q1 and Q2 and would be delighted to talk to you.
In this issue of Serverless Insights I'm going to focus on announcements from re:Invent, and “pre:Invent” — the week before that offers overflow opportunities for launches that weren't quite interesting enough for the big keynotes. Specifically I'm almost entirely going to focus on Serverless, and Serverless related updates. There were many other fun ones (ARM Chips, Satellite Control, DIY self driving cars), and some pretty unexpected updates too (Blockchain, Kafka, AWS On Prem). But let's dig into the things I can talk about with some amount of knowledge and not just pithy snark.
Serverless, and related announcements, at re:Invent 2018
Serverless was a Very Big Deal this year for AWS. Lambda is 4 years old, and clearly one of AWS’ main paths forward, along with machine learning. Lambda, alone, had a treasure trove of updates:
- Python 3.7, Ruby, C++, and Rust are now Lambda languages directly supported by AWS. In any normal year this would be enough, but Amazon also announced “Custom Runtime” support, along with launch partners who released 3rd party Lambda runtimes for Elixir, Erlang, Cobol (yes, really), and PHP. This is definitely an interesting new path, and allows, obviously, for use of languages in Lambda beyond those supported by AWS. It also allows for all kinds of “Not Invented Here"-ness though, so make sure when you sign-up to build your own Lambda Runtime that it's really something you want to do. Also make sure that if you're using a third-party runtime that you trust where it's coming from.
- Along with Custom Runtimes comes Lambda Layers — artifacts that can be merged into your function's file system before the function is executed. These artifacts are shared across functions, and so allow for code and data sharing. This is great for things like Custom Runtimes, where the runtime itself is very much abstracted from the underlying function, but we caution about using layers as an arbitrary application library system. For this it's probably best to lean on your language's dependency management system, since this means you can test your code effectively in a unit-testing context.
- Also — “AWS Lambda Doubles Payload Size for Asynchronous Invocations", “AWS Lambda supports Kinesis Data Streams Enhanced Fan-Out and HTTP/2 for faster streaming", and Firecracker — “lightweight virtualization for Serverless Computing”. Firecracker is a replacement to Amazon's “Docker-like” runtime environments which they initially used for Lambda. Firecracker is cool, open source, will help the AWS team immensely … and of almost no direct use yet for Lambda developers at all (unless you're a SaaS company and care about multi-tenancy.) And this is fine! Firecracker is a great new low level foundation that will allow Lambda and Fargate to grow in functionality and performance, and we'll almost certainly see features next re:Invent that are enabled by Firecracker. But for now it's something I won't be spending much time thinking about.
- And one other “non announcement” — at an “AWS Lambda under the hood” session Mark Brooker explained that next year Lambda will be changing how it integrates with VPCs. This has been a pain point for many teams since the current implementation slows down Lambda Cold Starts and requires some careful thinking about IP address management. It very much sounds to me from Mark's talk that from some time next year, VPCs will no longer slow Lambda Cold Starts, and that Lambda will be significantly less IP address hungry. Both of these will be welcome changes. See for yourself in the recorded talk of SRV409 here.
Stepping into Lambda + HTTP world, we had 3 notable updates
- Web Sockets support for API Gateway was pre-announced. This has been on a lot of people's wishlists. Update —this is now available.
- Lambda can now process HTTP(S) requests via an Application Load Balancer (ALB), and not just API Gateway. ALB's are not a serverless component in and of themselves — they need to be managed — however this might be a very interesting path for people wanting to gradually move functionality out of a container / traditional app that is already behind an ALB, and into Lambda functions. Here the Lambda functions are an example of a Strangler Application, with the ALB taking responsibility for Event Interception. It might also be possible that ALB + Lambda is a better solution for simple, high throughput scenarios, but some TCO cost math would need to be done before going down that path.
- Talking of which, API Gateway announced tiered pricing. API Gateway is a wonderfully full-featured piece of tech, but it can get pricey at high loads. For certain classes of use this new pricing may help folk.
One of my favorite developments of 2018 in the AWS team has been the growth of their “Serverless Applications” efforts — what it means to build and manage entire apps, and not just individual functions. SAM has been coming on in leaps and bounds, as has the tooling around it. “SAM build” starts stepping earlier in the CD cycle into thinking of what a Serverless App is at source-code time — it's just for Python for now but we like where this is going. Even further up the lifecycle path, new “Serverless Toolkits” for several IDEs were announced. The Serverless App Repo (SAR) team announced support for more resources, and the ability to consume a SAR app as a nested stack within a larger application. This latter update is one of my favorites of re:Invent, and I'll be writing about that separately soon.
Moving out of the Lambda and API areas, there were a good number of other highly-relevant announcements.
- Aurora Serverless gets a Data API — allowing use of Aurora Serverless from Lambda without the need for a VPC or connection pool. This makes it feel much more like a “Serverless Native” service. Aurora Serverless also announced support for Postgres.
- DynamoDB, not to be upstaged, announced “On Demand” mode, where read and write provisioning don't need to be worried about. This is likely great for lower throughput and inconsistent workloads. Still to be seen is whether this is pricey for other scenarios, and whether there are “cold start” concerns for very low throughput (occasionally idle) tables. DynamoDB also gets transaction support.
- S3, that cool uncle of AWS Serverless technologies, also continues to thrive. Intelligent tiering should solve a few pricing headaches, but the real gem here was S3 Batch Operations. John spent a non trivial amount of time and dollars doing a bunch of S3 manipulation work earlier this year — work that would have been significantly faster to perform and quite possibly a lot cheaper if this new feature had been available at the time.
And now, let's take a look at how embarrassingly off I was with my predictions from just before the conference.
My crystal ball is broken
- X-Ray 2.0. This year was better than last, in that there were a couple of X-Ray announcements (1, 2) . I need to look at them further, but I still think that X-Ray needs some significant work. Unless of course you're a company like Epsagon, in which case you're happy that AWS isn't coming after you yet. Score — 0.5
- Step Functions ++ . Again, some movement here with many more service integrations . I would have hoped for more updates, specifically around local development support, but good to see there's continuing investment here. Score — 0.5
- Remote Lambda Debugging support . Hah! I had to put something in on Lambda, even though I had a pretty clear idea what was getting announced. Remote debugging probably won't happen for a while, but I'll keep on banging on about it. Local debugging continues to improve, especially with the new IDE integration I mentioned above. But still — Score — 0.
- More “Service Mesh” style functionality. Boom — nailed one! AWS App Mesh was announced, as was the related Cloud Map. Congratulations to Envoy, whose project is the basis of App Mesh. Score — 1
- Something, something Lambda@Edge … Oh dear, I don't think I heard Lambda@Edge mentioned once, which is a shame. Its time will come. Score — 0
- EKS Fargate. Nope. I was very wrong on this. Maybe AWS were waiting for KubeCon next week? Score — 0
- Adding new replicas on-the-fly to DynamoDB global tables. Err, no. Aurora Global was announced! Which is cool! But that's not at all the same. Score — 0
- CodePipeline boost. Not quite the updates I was hoping for, but there were a couple of announcements (1, 2). The speed improvements are a welcome change. AWS Amplify announced their own completely separate CD tool, in true Amazon “unified product vision? What unified product vision?” style. Score — 0.25
- API support for disabling / deleting sub accounts within AWS Organizations. And no. Control Tower got announced, bringing effective use of AWS Organizations to a new audience, but still no automatic way of killing off old accounts. Alas. Score — 0.
So, my grand score is … 2.25 out of 9. I think I'm better at discussing what has been released rather than what hasn't.
And that's your re:Invent wrap-up for 2018. We look forward to seeing what we're still talking about in a year's time.
That also wraps up our newsletters for 2018! It's been a great year, full of wonderful clients, conversations, and things that we've learned. John and I start our third year of Symphonia in January, and we're already excited for the new year. Until then we wish you all the happiest of holidays.
Mike & John
To receive the email version of this newsletter please subscribe here.