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.
If your AWS Lambda application is experiencing terrible latencies and delivering a frustrating user experience, you may target high CPU loads as the main problem to solve.
How to debug and identify parts of the code that cause a bottleneck effect in a serverless application can be a difficult question to tackle. For a regular application, you have many debugging and monitoring tools that enable you to observe your application while it is running, hence making it easier to identify any faulty and inefficient parts of your application. However, as you may already know, serverless is a brand new technology and, therefore, it lacks such tools that provide debugging and tracing capabilities. As first-hand users of AWS Lambda functions, we understand the agony that comes with not being able to trace and debug your functions, especially when there are errors or there is unexpected behavior. Considering how rapidly popularity of serverless is growing it is imperative for the programmers to have means of unimpeded, smooth development. This is where Thundra comes in, “Full Observability for AWS Lambda”, which aims to give, as the slogan suggests, full visibility of what is going on in your application to ease the programmer’s life.
Alexa is Amazon’s virtual assistant and the brain behind tens of millions of Echo devices like the Echo Show and Echo Spot. Alexa provides capabilities, (called skills), that enable customers to experience more personalized service. The Alexa Skills Store currently has more than 45,000 published skills and this number is increasing rapidly.