Not so serverless Neptune

Several years ago I wrote a post asking people to stop calling everything serverless. I even gave a keynote at Serverless Days Milan the following year pleading the same message. My contention was quite simple: “when everything’s serverless, nothing will be.”

Back then, “serverless” was still relatively new, and the possibilities were seemingly endless. Sure, there were a few people starting to mislabel things, and of course, haters were gonna hate, but for the most part, the argument was less about the nuances of the technology and more about the “nature” of serverless and the serverless-first mindset. But then something changed.

Continue Reading…

The cloud isn’t the issue, you’re just using it wrong

#Tech Twitter was all abuzz recently after DHH boldly proclaimed and explained why [37signals is] leaving the cloud. A lot of people cheered, some of us jeered, and everyone else just pitched web3 as an alternative solution. DHH’s success has earned him a giant platform and a tremendous amount of influence, and while I often disagree with him, it’s clear that many others do not. I spent quite a bit of time reading through all the retweets, reposts, comments, and hot takes, and I came to a fairly simple conclusion: these people are using the cloud wrong.

Continue Reading…

Serverless Tip: Don’t overpay when waiting on remote API calls

Our serverless applications become a lot more interesting when they interact with third-party APIs like Twilio, SendGrid, Twitter, MailChimp, Stripe, IBM Watson and others. Most of these APIs respond relatively quickly (within a few hundred milliseconds or so), allowing us to include them in the execution of synchronous workflows (like our own API calls).  Sometimes we run these calls asynchronously as background tasks completely disconnected from any type of front end user experience.

Regardless how they’re executed, the Lambda functions calling them need to stay running while they wait for a response. Unfortunately, Step Functions don’t have a way to create HTTP requests and wait for a response. And even if they did, you’d at least have to pay for the cost of the transition, which can get a bit expensive at scale. This may not seem like a big deal on the surface, but depending on your memory configuration, the cost can really start to add up.

In this post we’ll look at the impact of memory configuration on the performance of remote API calls, run a cost analysis, and explore ways to optimize our Lambda functions to minimize cost and execution time when dealing with third-party APIs.

Continue Reading…