There is an emerging ecosystem of serverless startups building on top of AWS Lambda. Thundra, an observability and security product, is one of them.
What Kubernetes is to containers, AWS Lambda is to serverless. In other words, Lambda is the dominant platform of serverless. There’s one key difference, of course: unlike Kubernetes, Lambda isn’t open source. It’s owned by Amazon Web Services, one of the most powerful technology companies in the world. But that hasn’t stopped an emerging ecosystem of startups building on top of Lambda. Thundra, an observability and security product, is one of them.
I recently spoke to Thundra’s Vice President of Product, Emrah Samdan, to find out what he thinks of the AWS platform — including its limitations — and how he sees the future of serverless panning out.
Serverless is a set of tools that abstracts away the backend for developers, allowing them to focus on frontend code only. AWS Lambda is the clear market leader in serverless platforms, while Thundra provides observability and security for serverless applications built on Lambda.
“It can be plugged into your applications, quite easily,” said Samdan.
However, it’s not that Thundra is offering something completely new to the AWS ecosystem. Amazon CloudWatch is an existing observability and monitoring product, and there’s also AWS X-Ray — a debugging and tracing service that integrates with CloudWatch.
But according to Samdan, those AWS products are not meeting “the needs of the community.” Slowness is one issue, he says, but also (ironically) an inability to scale when dealing with serverless functions. He claims that CloudWatch and X-Ray struggle to cope with any application that has over five functions.
“Things are getting complicated when you have more than, let’s say, 20 functions and they are all interconnected to [an application’s] events,” he said. This, Samdan believes, is the market opportunity for Thundra.
Thundra also provides application observability outside the core serverless platform. Samdan told me that Thundra conducts “end-to-end tracing” across not only Lambda, but also containers, virtual machines, and anything else that the application touches.
He gave the example of an application that uses some data from Amazon Kinesis, an AWS product for managing real-time, streaming data. If the Kinesis stream is consumed by a Lambda function for the application, according to Samdan that transaction cannot be seen “with AWS native solutions.” But it is picked up by Thundra.
One of the disadvantages of building a third-party product on a commercial platform is that Thundra is reliant on AWS in many ways. I asked Samdan if there are any limitations to what it can provide to its customers? It turns out there are.
“[When] we want to retrieve some data, to take this data out [of Lambda], the only time that we have is the execution time of the customer’s function. So, it’s inevitable that we — and all the other third-party vendors — [are] adding some overhead to the applications.”
The problem is that Thundra has to extract data from the customer’s application running on AWS so that it can apply its own software intelligence — measuring things like request and response times, and time spent doing a particular job.
“In order to do this,” continued Samdan, “we are doing an HTTP connection to our REST endpoints, or we are writing this information [from] CloudWatch logs.”
The first solution, using an HTTP connection, adds an overhead. The second incurs an AWS CloudWatch cost to the customer.
It’s also difficult to provide other kinds of insights on AWS, said Samdan, such as business metrics on “the interactions between Lambda and other services.” Currently, Thundra has to write its own code to deliver those insights, so ideally it wants AWS to provide an SDK to assist.
But such is the life of a third-party vendor dependent on a commercial platform. It’s not like in Kubernetes, where a company like Thundra could simply spin off a new open source project to address a business need.
How to best monitor your external and third party API integrations and hold partners accountable to SLAs
And to achieve observability in serverless applications, it's important ... Monitoring checks “known” metrics to evaluate the health of the system.
Businesses need to understand serverless application with major pros and cons of serverless architecture, before deciding about serverless computing.
Bypass the complex middleware and consider a lightweight node.js implementation to deploy serverless functions from your mainframe CICS applications.
Fauna and Its Client-Serverless Application Model: Fauna aims to provide a powerful “data API” for serverless apps, so that developers don’t need to deal with a database system.