AI-Aided Coding
On average, how much time do you think you save per week by an AI-powered coding assistant such as GitHub Copilot or JetBrains AI Assistant?
I don’t use an AI coding assistant.
Up to 1 hour/week
1-3 hours
3-5 hours
5-8 hours
More than 8 hours
I don’t save any time, yet!
Frontend Development / Observability / Serverless

How Thundra Tackles Serverless Limitations and Platform Power

There is an emerging ecosystem of serverless startups building on top of AWS Lambda. Thundra, an observability and security product, is one of them.
Aug 24th, 2020 3:00am by
Featued image for: How Thundra Tackles Serverless Limitations and Platform Power

Richard MacManus
Richard is senior editor at The New Stack and writes a weekly column about what's next on the cloud native internet. Previously he founded ReadWriteWeb in 2003 and built it into one of the world’s most influential technology news and analysis sites.

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.

Reliance on AWS

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.

Serverless Limitations

It’s also worth noting that there are limitations in the serverless model itself.

“Function as a Service [FaaS] has some limitations which are meant to be there,” said Samdan. “So, a function can only run at most for 15 minutes, for example, or it can have at most three gigabytes of memory. So, this automatically eliminates some of the use cases.”

Gaming apps, for instance, are not a good match for serverless — since they typically require a high computational effort.

Another technical limitation in serverless apps has been managing data; serverless apps have, up till now, tended to be stateless. However that trend appears to be shifting, judging by last week’s KubeCon — which had several sessions on “stateful serverless” (I’ll be writing about this trend in an upcoming column).

There’s also a cultural barrier to switching your apps to serverless, said Samdan.

“You can’t just ‘lift and shift’ an application to run in serverless; you need to re-architect it a bit.”

The Future of Serverless

As a serverless vendor executive, naturally Samdan is bullish about the prospects of serverless going forward. But he thinks it’ll be five to ten years before it becomes “the default” for cloud services.

“[Over] this time, serverless technologies will continue to address the limitations that we currently have. And at the same time, when people are thinking about taking [their applications] to the cloud, they will just get used to this idea of ‘Hey, if I’m renting a server, why don’t I rent computation power’ — which is called Function as a Service.”

Interestingly though, Samdan has not seen a lot of take-up so far of multicloud — a vision for the future of cloud computing where customers use multiple cloud platforms.

“To be honest, we were not seeing much of that kind of usage before. So people were not using, like, AWS Lambda and Azure Functions together.”

With that said, Samdan has begun to notice “more and more people using” multicloud, so it is on the company’s roadmap to eventually support this.

Whatever the future of serverless, Thundra appears to have carved out a niche for itself in the crowded observability market. While most other observability and security products we cover on The New Stack focus on Kubernetes, Thundra has staked a claim to the emerging serverless ecosystem. Although it will be hoping that AWS continues to be a good steward of that ecosystem.

Thundra and Amazon Web Services are sponsors of The New Stack.

Feature image via Pixabay.

At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email:

Group Created with Sketch.
TNS DAILY NEWSLETTER Receive a free roundup of the most recent TNS articles in your inbox each day.