It has been 2 weeks after Re:Invent. Last week, as I recovered from the Las Vegas-to-Turkey trip jet lag, I took some time to evaluate what we learned from the event, made some adjustments to the Thundra roadmap, and got back into the daily work routine. Now, I finally have some time to share my thoughts from the event with this recap blog.
First, the AWS team does a great job putting on the conference. Previously, I followed Re:Invent via live streams but this was my first in Vegas and I really admired the quality of work by the team to manage, educate, and entertain tens of thousands of attendees.
I was often on duty at our Thundra booth, giving demos to visitors curious about AWS Lambda, Thundra, or simply just curious. Traffic was non-stop, giving me the opportunity to validate assumptions and clarify some open questions I had gathered before coming to Re:Invent. I want to thank the +1300 visitors who stopped by our booth and shared their experiences and needs regarding serverless, monitoring or both.
As a developer, one of the most irritating things I face is that my attempts to implement good coding practices often renders my code broken and filled with bugs. It is quite the tragicomedy of code development, all in the effort to comply with the ecosystem of DevOps. The problem usually occurs when I try to configure tools I am not familiar with, only to result in my code base inevitably throwing errors or behaving unexpectedly. I thus end up barraging senior developers with Slack messages, and Google with endless searches in order to unravel the correct way of configuring these tools. Obviously if one follows the tooling docs to the letter, it should be simple, right? Wrong! More often than not, the documentation does not always address the specific use case you are trying to implement. Most typically, developers suffer through lots of easily-avoidable errors in the journey to become an expert on how to configure and implement that particular tool.
One example of a difficult tooling scenario is implementing a typical serverless monitoring tool. In order to collect even basic monitoring data, you often need to perform an excessive amount of in-code configuration. Usually, you are required to ‘wrap’ your code with the monitoring tool for monitoring to actually occur. Wrapping is the most popular way to integrate monitoring tools and collect basic data from your functions. However, this approach means you need to wrap numerous functions in order to successfully monitor an entire application.
Furthermore, in addition to the integration burden, configuring these tools can also prove tedious. It’s too complicated to expect, for example, a single simple-minded stooge like an unpaid intern, to wrap hundreds of functions and also expect him to do so successfully. No, there needs to be a more simple, less risky way of implementing monitoring for serverless applications.
Our team at Thundra realizes that this manual, labor-intensive approach simply isn’t efficient, and we’ve thus tried hard to design a monitoring tool which is easy and simple to use. Thundra offers its own serverless plug-in that allows automated wrapping to set up basic monitoring, along with automated instrumentation for more detailed monitoring. You don’t need to change your code base just to monitor your code. Finally, adding monitoring to your Lambda functions is actually easier than writing your Lambda functions. This is the way it should be!
Our previous blog showed you how our automated instrumentation (for detailed monitoring data) works, especially for Node.js. Now, let’s take a look at how automated wrapping is implemented. For now, we support automated wrapping for Node.js and Python functions.
I attended the keynote speech of Charity Majors at Serverless Computing London, where she highlighted the term observability-driven development to create highly available and resilient systems. Her speech inspired me to write about what observability-driven development is and it means for serverless.
In his GA announcement, Emrah outlined the newest features in our GA product, including rich support for Node.js applications. Here, I want to go into our support for manual and automated instrumentation and show you how to add this to your Node.js applications. But, first, let’s talk about why instrumentation is useful in serverless environments...
We believe that your data should not exist in a silo and you should be able to view, manipulate, and analyze it in the way best suited for your business, using your favorite platforms. With this goal in mind, we feel integrations with popular data platforms are an important part of Thundra’s offering to the serverless monitoring and observability space.
First, heads to all our beta customers. In order to see data in the Thundra Web Console and take advantage of our GA features, you need to update your existing agents. Currently, all beta agents send data to “beta.thundra.io”. However, this platform will be discontinued by November 1st. We recommend that you immediately update your agents to the latest versions, which will allow you to receive data in console.thundra.io.
Greetings everyone! I’ve been looking forward to this moment for a long time now. After a year of development work, I am very excited to announce that Thundra is taking flight out of beta.