Is your Serverless as good as you think it is?

Building stuff on Serverless has been catching on like wildfire, and it should! FaaS architectures makes the impossible cheap and possible. However, I believe that many of us (and maybe even you 😱) have forgotten an important aspect about functions along the way.

Functions behave differently than servers

Duh! When we first started going Serverless in 2014 we inherited a concept from the good old server. And that is, how we measure application performance and track errors. Looking back (and around) this has been one of the biggest problems to get right. With Serverless, you should care about three things: invocation level performance and execution errors, account level metrics. Because…

Problems you (might) have right now: :

Snow blindness. Sometimes code (even yours 😬) behaves differently from the way you think it does. For instance, endpoints can perform slower than you expect and if you don’t measure it, you will never know (but your users will). You also might be close to timeouts or memory limits, without even knowing about it.

Silent failures. It’s good to catch errors and report them to a service that yells at you on Slack or e-mail. However, with Lambda functions, this does not work in all cases. Timeouts, configuration errors and early exits are not reported to error-tracking services.

No helicopter view. You know that your AWS account has a limit for concurrent executions but it’s a bit harder to know how many are going off at the moment and if you’re in the risk of running into this limit. Also it’s difficult to don’t know which functions trigger (and cost) you the most, and vice versa 😕.

All that is really hard to address by just attaching monitoring and reporting tools to your application code. On top of that, it’s an operational, performance and development overhead to attach it to every function and if you don’t you’ll leave blind spots to your system.

FaaS architectures require a new approach

An alternative to sending data out from the functions is to collect their emission gases 😎. I’m sure you know that AWS Lambdas send their logs to CloudWatch for each invocation. The log outputs enable us to detect whether the invocation was a success or not, if it was an error, how much memory and time was consumed, among other things.

The beauty is that this way you don’t have to worry about blind spots. You know that ALL your functions are being monitored and you can pick up any odd behavior (like errors, timeouts, inefficiencies) instantly.

Also, with that comes the opportunity to crunch the data and have insights into account (or service) level performance. You know exactly how parts of the system are performing and have a birds eye-view of the entire system.

No FaaS system should be tracked like a server

Dashbird

Services like Dashbird make it possible to monitor your AWS Lambda functions simply by hooking up to your AWS account. The setup takes 5 minutes and the result is marginally more accurate than is possible to achieve with tracking libraries.


If your Serverless stack is small, you can use Dashbird for free. If it’s a little bigger, you can try it out for 14-days without any commitments. Try it out!