Hi, welcome to another weekly update.
Welcome Thundra as our sponsor for Feburary!
It is my pleasure to welcome Thundra as sponsor for this month. Here’s a message from Thundra to explain what they’re building and their vision for Serverless observability.
A serverless application eliminates operational burdens and you only pay for what you use as your code is executed. However, when something goes wrong, it can be tough and time consuming to identify and debug where the issues lie. Even worse, what if you aren’t sure where to start your investigation? How do you see inside an environment you do not set up and have no control over?
Built for effortless implementation and full observability, Thundra provides deep insight into your entire serverless environment no matter if you are just starting to write code or maintaining large scale serverless applications. Thundra collects and correlates all your metrics, logs, and traces, allowing you to quickly identify problematic invocations and also analyzes external services associated with that function. With Thundra’s zero overhead and automated instrumentation capabilities, your developers are free to write code without worrying about bulking up their Lambdas or wasting time on chasing black box problems.
Lambda optimization tip – enable HTTP keep-alive. This is one of the simplest tweaks you can make, and yields significant return on performance. The default HTTP agent in Node.js disables HTTP keep-alive, so every request to AWS services would need to perform a three-way handshake for TCP. By enabling HTTP keep-alive for the AWS SDK, you can reduce the latency of a DynamoDB operation (or any other AWS service for that matter) from over 30ms to under 10ms.
Debugging serverless applications with Dashbird. I wrote a guest post for Dashbird to demonstrate how you can use it to help debug problems in a serverless application using a simple demo app (see below). I gave a general introduction to Dashbird and highlighted the various features it has. In general I think it’s a good service, has some definite value-add compared to the raw metrics in CloudWatch, and has some neat touches that makes debugging much simpler.
I gave the opening keynote at the recent ServerlessDays Cardiff, where I talked about why Serverless is more FinDev than DevOps. The slides is available on slideshare and the recording will be posted in the near future.
I will be in Hamburg next week and deliver the opening keynote for ServerlessDays Hamburg. My talk will be focused on debunking serverless myths, and we will talk about control vs cost of taking on additional responsibilities, and the risk of vendor lock-in vs potential returns. Hope to see you in Hamburg!
Open source contributions
serverless-step-functions plugin supports CloudWatch Alarms. You can now specify CloudWatch Alarms for your state machines using the serverless-step-functions plugin for the Serverless framework.
The syntax for declaring CloudWatch Alarms is straight forward, and supports the four CloudWatch metrics that Step Functions publishes for your state machines.
The auto-generated alarms are twitchy and would have the following configurations: