Modern development - Thundra: The current (and future) state of serverless

This Computer Weekly Developer Network series is devoted to examining the leading trends that go towards defining the shape of modern software application development. 

As we have initially discussed here, with so many new platform-level changes now playing out across the technology landscape, how should we think about the cloud-native, open-compliant, mobile-first, Agile-enriched, AI-fuelled, bot-filled world of coding and how do these forces now come together to create the new world of modern programming?

This contribution comes from Emrah Şamdan in his role as vice president of products for Thundra — the company is known for its application observability and security platform for serverless-centric, container and Virtual Machine (VM) workloads.

Şamdan writes as follows…

It has been more than five years since the launch of AWS Lambda and serverless is winning the world over. 2020 has brought an unexpected amount of challenges along with extra time on our hands to dive into the past, present and future of serverless with industry experts: Tim Wagner and Tom Kowalski.

You most likely know Tim Wagner, a.k.a. the father of serverless. He was the first GM of serverless services, both before and after the launch of AWS Lambda. Tom Kowalski, chief architect at DaySmart, has been a serverless fanatic since its inception and leads one of the greatest teams with a serverless-first mindset.

How did serverless start?

Like many others, AWS Lambda was thought to be born out of EC2 to make computing more flexible with scaling from zero to infinity. According to Wagner, that’s actually a misconception. The idea of event-driven computing units actually grew into the S3 team and its customers. Funny to think that while the AWS team was deciding on a name, the developers threw out: Super Simple Scripting Service, or S4 for short.

During their long-running interviews with hundreds of customers, Wagner and the AWS team discovered that people needed a way of doing things on files on S3 after they changed. They realised that this idea could be applied in a more generalistic way in the AWS platform. Lambda was created and began as an event-driven, limited computing platform for small tasks and ephemeral jobs. [Fun fact: the limits were a lot stricter back then, with the first timeout limit being only one minute]. Considering the impressive use cases such as machine learning, e-commerce and data pipelines, we can see that a humble start by the S3 team created a paradigm shift that will change computing forever.

True or false?

Did the AWS team envision Lambda and serverless as a new computing paradigm from the beginning? False. At the start, they thought functions would be only for simple jobs that should take a minute or less with limited memory usage and so on. The idea was not to build fully-fledged backend applications or machine learning applications with Lambda. Wagner confessed that he’s now fascinated by all the use cases that can be done through supercomputing using Lambda functions with extended limits and provisioning capabilities.

Şamdan: There’s a whole (serverless) community out there.

Did the AWS team think the learning curve would be simple? True. They believed that users would adopt developing, testing, deploying and maintaining functions easily. This misconception impacted the adoption of serverless for the first several years. Wagner explains that the great serverless community pitched in by creating tools like Stackery and (if I may say) Thundra to make the lives of application teams easier and to make serverless enterprise-friendly.

Was Lambda created as an event-driven idea? True. The team had no doubts about the efficacy of introducing almost all of the AWS services as an event source to Lambda — even when they only had S3, DynamoDB and Kinesis as a trigger when AWS Lambda was launched. When we think of the many different ways we can fire a Lambda function now and the ways we can exchange events with Eventbridge, we can see how accurately they executed their vision throughout the years.

The state of serverless in 2020

Where are we in the serverless journey this year? Serverless has led to outsourcing all the undifferentiated heavy-lifting that internal teams were doing over and over again, according to Kowalski’s experience at DaySmart. His team now spends a minimal amount of time spinning up the production architecture to onboard a new engineer, to do a PoC on a new idea, or to try new features that have been rolled out by AWS. This agility and flexibility with managed services has allowed DaySmart to focus on what really matters to them: the value that they provide to their users. 

Wagner also notes that the VCs have been surprised by the maturity and operability of the Vendia product with a small team. That’s possible as a result of leaning on the serverless paradigm. Serverless also enables companies to re-shape their capital expenses for talent, they can now afford to invest in more reliable, resilient, and scalable applications. This in turn means the companies are focused on added talent that can bring more value to the application.

Is serverless perfect? No, there’s still room for improvement. At this stage, there is not a very clear path to migrating existing applications as they are or with minimal modifications to serverless. Interesting to note, one thing that cloud vendors will need to do is modify the first definition of FaaS, such as making it stateful. Considering that AWS lets users define a provisioned concurrency for Lambda functions (which is quite controversial compared to the idea of not managing or controlling the load), we can assume that the work has already started.

#awswishlist for re:Invent 2020

I highly doubt that we’ll have the re:Invent this year, due to the Covid-19 pandemic, but this won’t keep us from asking for features. Wagner and Kowalski share insight into their AWS serverless wishlist:

  • Make the serverless stateful: Kowalski explains that he is now using DynamoDB to manage the state when it’s required. However, this creates another complexity due to the addition of another product to the apps. If it was possible to share the state across Lambda invocations and run custom business logic between them, simplicity and speed would be underway in DaySmart applications. Wagner adds that in order for serverless to unlock the next big thing for software development, we need to modify its first definition and add a way of sharing state across functions.
  • A lot more granular cost structure: When Wagner first started the AWS Lambda service, 100ms seemed like a very small time and could be the most granular time for charging functions. However, there are now many very efficient tiny functions that run for just a couple of milliseconds, but are still charged with the same rule. He believes that 1ms granularity of cost will boost adoption and generate even more success stories with serverless from a cost perspective.
  • gRPC support: AWS provides different ways to interact with the outside world using API Gateway and EventBridge, but there are still numerous use cases where the support for a common remote procedure is handled by gRPC.
  • EFS attached to Lambda: We are doing great with datastore systems like DynamoDB, S3, and so on, but there might be some use cases where we need to work with a real file system structure. For this reason, we need to have the possibility of attaching EFS to a Lambda function.
  • More lifecycle hooks for the container: The possibilities that would open up on our end are countless, the ability to run and align with Lambda functions in a more secure, efficient, and fast way would be ideal.

Regarding the future of serverless, production readiness of serverless for many use cases will improve, the potential to cover many others is arriving, and expect serverless to be the default computing platform by 2025.