Off-by-none: Issue #16

December 18, 2018

Premature Serverless Optimization…

Welcome to Issue #16 of Off-by-none. Thanks for joining us. 🤘🏻

Last week we looked at Lambda Layers and custom runtimes. This week we’re going to talk about when we should worry about optimizations, plus highlight some recent discussions about the term “serverless” and what that actually means. We’ve also got some interesting articles, several product announcements, and (somehow) more stuff from re:Invent.

Let’s get started. 👍

When you spend too much time optimizing the wrong things… ⚙️

Mark Schwartz published an article on the AWS Cloud Strategy Blog entitled: Micro-Optimization: Activity-Based Costing for Digital Services? In it he outlines the fact that we can now meter individual units of compute to analyze costs. Simon Wardley (and others, including me) have been talking about capital flow for quite some time. Erik Peterson over at CloudZero uses the term FinDevOps to described it. But knowing your costs is different than trying to prematurely optimize them.

I wrote a post last week about the potential to overpay when waiting on remote API calls. This was a micro-optimization, and for my use case and company, it made sense. However, there are two slippery slopes that this type of fine-grained metering can introduce. The first is to tie your costs directly to customer pricing. Some services make sense to use metered billing, but don’t let this level of cost granularity influence the value your service provides to customers.

Second, is premature optimization. Compared to building and maintaining your own systems, cloud computing is ridiculously inexpensive, especially when you’re starting out and haven’t achieved significant scale. Don’t waste your developers’ time trying to shave off nickels and dimes from your bill. Focus on creating more value by delivering and iterating on features faster and worry about cost optimizations later.

Choosing serverless, however, is a MACRO optimization. I have some thoughts on that.

When you’re still confused by what serverless actually means… 🤷‍♂️

You’re not alone. Ben Kehoe called serverless a spectrum at one point, CloudZero wrote a post about it. AWS calls it an operational construct. Simon Wardley has his definition. Jeff Hollan wasn’t happy with the mischaracterizations in this paper that argues that current serverless offerings are “a bad fit for cloud innovation.” And Paul Johnston says that teaching people to do serverless is hard because it’s not about technology, but culture.

I have plenty of my own thoughts on this as well, but one thing is for sure, this debate won’t be settled any time soon. Regardless of the exact definition, I believe many of us “know it when we see it” and are starting to embrace the benefits it brings. And if you’re looking for some of those benefits, Zack Kanter makes the business case for serverless in his new post on TechCrunch.

What to do when you’re looking for some light serverless reading… 📚

Ory Segal published some Security Considerations for AWS Lambda Runtime API and Layers. AWS does a lot to protect you and your application from security issues, opening up custom runtimes, while a good thing, means more to consider from a security standpoint. Read this post to get an idea of some of these new risks.

Serverless Latency has been a common objection amongst the anti-serverless crowd for quite some time. Tim Bray dives deep into this and gives us some things to think about regarding state hydration, database considerations, and how we should really be thinking/talking about latency in our applications.

Yan Cui (AKA The Burning Monk), talks about Holistic Problem Solving using serverless. Yan just wrapped up his Production Ready Serverless course, which is a favorite among many of us in the serverless community.

For more on custom runtimes in Lambda, you can check out Adnan Rahic’s crash course on Serverless with AWS – Running Node.js 11 on Lambda. But just because it’s possible, doesn’t mean it’s a good idea. 😃

When you’re looking for more serverless announcements… 📣

Serverless, Inc. announced the release of the Serverless Framework v1.35. Good news for you Ruby folks, plus support for cross-region CloudFormation outputs and a bunch of bug fixes.

AWS announced that Amazon SQS now Supports Amazon VPC Endpoints using AWS PrivateLink. It’s a pain to need NATs just to connect to some AWS services, so for bunkered apps, this removes another external call to the Internet.

AWS also announced support for nested applications for AWS SAM and the AWS Serverless Application Repository. Nested applications were announced at re:Invent, but now that AWS SAM supports them, I’m guessing we’ll see some interesting use cases emerging. Easier reusability in our serverless applications is a big deal.

If you really want to geek out, there’s a post on How to use the new Amazon DynamoDB key diagnostics library to visualize and understand your application’s traffic patterns. Not sure I would spend a lot of time with this one, but it’s nice to know it’s there if you need it.

Beyond some of these bigger announcements, there were also quite a few Invisible Improvements made by AWS. Alex DeBrie broke them all down for us in his new post.

When weeks go by and we’re still talking about re:Invent…

It seems that no matter how many hours you’ve spent watching re:Invent videos and reading recaps, there’s always more to discover. There’s another post here that lists several great talks, and here are two more that I really enjoyed.

Accelerate Innovation & Maximize Business Value w/ Serverless Apps (SRV212)
Linda Lian talks about how Amazon thinks about serverless. It’s explained as an operational construct, rather than an architectural model or a way to think about packaging and deploying code. Christopher Dixon from Comcast then shows us how Xfinity used serverless to integrate Netflix streaming into their set top boxes. Pretty cool stuff.
Watch the talk

CI/CD for Serverless and Containerized Applications (DEV309)
Clare Ligouro, Principal Engineer at AWS Container Services walks us through the three pillars of releasing modern applications. Lots of great information in here about blue-green and canary deployments, plus how to use Lambda to add verification hooks and automatically rollback ones that fail. Watch the talk

Also, if you want a bit of an inside look at re:Invent, check out Marcia Villalba’s video series on her Foo Bar channel. She interviewed a lot of people, so it’ll be great when the full versions come out. Maybe start with Day 2 if you want to see a snippet of yours truly. 😉

Serverless Star of the Week ⭐️

There is a very long list of people that are doing #ServerlessGood and contributing to the Serverless community. These people deserve recognition for their efforts. So each week, I will mention someone whose recent contribution really stood out to me. I love meeting new people, so if you know someone who deserves recognition, please let me know.

This week’s star is Ory Segal (@orysegal). Ory is the CTO and Co-Founder of PureSec, a serverless security platform. Beyond their core product, Ory and his team are responsible for a number of innovations around serverless security. These include their free FunctionShield and Least Privileged Role Generator tools for Lambda, their creation and contribution to the OWASP Serverless Top 10 project, and their collaboration with AWS to bring application security to Lambda using Layers. Ory is also active on the PureSec Blog and just launched a new eBook all about AWS Lambda Security Best Practices. Serverless empowers developers to build and release software quickly, but that can introduce significant security risks. I feel much better knowing that Ory is watching our backs. 👀

Final Thoughts 🤔

The more popular “serverless” gets, the more people try to overload the term and subscribe it to everything. I’m a firm believer that serverless is not a buzzword, and that it means something very specific, even if the definition continues to be blurred by marketing departments. If I thought this was just an argument about semantics, then I’d probably let it go. But I think there is more to it than just that, and that the distinction will become important. More thoughts to come on this.

I hope you’ve enjoyed this issue of Off-by-none. All of your feedback and suggestions are incredibly helpful, so please keep them coming. Reach out to me via Twitter, LinkedIn, Facebook, or email and let me know your thoughts, criticisms, and ideas for making Off-by-none better.

Until next time,
Jeremy