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.
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.
Whatever monitoring tool you use for AWS Lambda, privacy of the monitoring data is always a headache. It is very normal and common that monitoring data can include sensitive data or clues about sensitive data. To solve this, it is better to keep the monitoring data as a secret at your own instance(s). But, how will I visualize and extract insights from the data? Will I allocate time to query this data yourself? The queries will take too much, which fields will I index?
With Thundra, you can gather useful insights about your AWS Lambda function such as detecting errors and performance degradations. Thundra gives you flexibility to instrument your code either manually or by using automated approach with no code change. Now, it is time to send the monitoring data to Thundra for evaluation. Thundra gives you two options to send your monitoring data:
I remember my first times writing some code in C years ago. I was struggling to discover why my code got segmentation fault. To detect the point of failure, I was printing every single variable to console at some specific checkpoints which hopefully would tell me why. Back then, I wasn’t aware that my silly
printf s were primitive examples of manual instrumentation.
Suppose you want to buy a ticket to a concert of your favorite band and you know that the tickets are running out. You need to open your computer, wait for the launch of the browser, go to the website of ticket sales, see there is only one ticket remaining, and click to buy. Then boom, “Sold out” is the phrase you are going to hate for a while. We are sad to say but you are “cold started”. You would have been able to catch the last ticket if your browser window was open, showing the website, and ready for you to click the “buy” button. You should have kept your computer warm to buy this ticket.