Operations | Monitoring | ITSM | DevOps | Cloud

Over the past few years, AWS has made incremental improvements to Lambda’s cold start performance. Nowadays, cold starts are much less an issue for most functions, unless you’re using Java or.Net Core.

At Lumigo, we keep improving the coverage and quality of our distributed tracing instrumentation to give you, through Lumigo’s transactions, the most accurate and intuitive representation of how your distributed system behaves. In this blog, we cover a recent development for the Amazon SQS instrumentation in Lumigo’s OpenTelemetry distro for Python, providing a seamless experience for a scenario that otherwise would result in confusing, broken transactions and lost insights.

Back in 2020, we covered the launch of Lambda Extensions and the subsequent release of the Lambda Logs API. These features aren’t designed for the average Lambda user. But they allow vendors to build better tools by giving them much-needed access to the Lambda execution environment.

Amazon CloudWatch monitors metrics of your Amazon Web Services (AWS) resources in real time and can trigger alarms when a metric goes above or below certain thresholds. Typically, Amazon CloudWatch sends out alarms by posting a message to an SNS (Amazon Simple Notification Service) topic, which distributes the message via several mediums, including email, SMS, and Lambda functions. Setting a CloudWatch alarm can be complex.

With serverless and containerized applications becoming a norm, workloads and integrations are spread across multiple cloud environments. As these apps become increasingly more distributed, monitoring also becomes more complicated with siloed and incomplete telemetry. This is where distributed tracing brings great value. It enables end-to-end visibility in your modern and complex application.

The internet of things is one of my favorite topics. IOT enables low-powered connected devices that opens gateways from the digital to the real world. While I love tinkering away with an Arduino sketch and the latest Espressif or Arduino board, there is always an air of frustration when trying to build out what at first seems like simple functionality using one of these “smart devices” because of the limited view we have into their operations.

Lambda is the glue that holds serverless architectures together. Before its release, most users felt it was a matter of luck as to whether AWS would let you connect a service to another. If not, you had to spin up a VM or a container to transform the events from one service in a way that your target service could handle them. Since Lambda was easier to set up, people assumed that all code they would deploy on it would run faster and cheaper than on other compute services.

As a developer, I love the versatility of Python. Over the years I have used Python for so many different use cases: game development, APIs, IoT, machine learning, and web development. It can scale tall applications in a single bound and take on any challenge faster than you can pip install flask. Something you learn very quickly in the world of app development is to build everything for scale.

Observability is a measure of how well we are able to infer the internal state of our application from its external outputs. It’s an important measure because it indirectly tells us how well we’d be able to troubleshoot problems that will inevitably arise in production. It’s been one of the hottest buzzwords in the cloud space for the last 5 years and the marketplace is swamped with observability vendors. Different tools employ different methodologies for collecting data.

When we set out to trace applications running outside of AWS Lambda, there was little doubt in our minds that building on top OpenTelemetry was by far the best course of action. There are many reasons for this, but chiefly, it is a question of coverage. At its most fundamental level, achieving coverage requires as-wide-as-possible support for technologies, and interoperability among instrumentations.