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?
First, let me introduce myself: My name is Christina Wong and I joined Thundra in May 2018 as VP of Marketing. My background includes roles in mechanical engineering, sales, product marketing, and partnerships across a variety of different sized organizations (from startup to large companies) and in several different industries (automotive, defense, software). I love working in the space where business and complex technical topics intersect and I am especially fascinated by new software challenges and adoption of new application paradigms of all sorts. This includes cloud, microservices, containers, devops, and, now, serverless. In my spare time, I am a mechanic and race car driver on a team called The Cosmonaughts.
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:
FAAS is a big success story. It allows us, the developers, to concentrate only on the application code. However, it’s worth noting what we often forget as we move away from monolithic service design to microservices: while we remove the complexity from the services, we add complexity to the system of services.
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.
We conducted our first webinar last week. After we released our public beta, we got some questions and feedback about Thundra. That’s why it was time to make this webinar, with Serkan Özal, our lead engineer, and me as product manager.