To Rust, or not to Rust, that is the question

When it comes to serverless, speed is paramount! I am not just talking about saving a few milliseconds of development time here and there; we're talking about the critical relationship between speed and cost without manual intervention. In today's hyper-connected world, where lightning-fast access to information is vital, those who can leverage this concept at scale will reap the rewards of cheaper cloud costs!

Rust is the key to unlocking the performance of the next generation of serverless applications. In recent years, we have seen the rise of other JS engines, such as Deno or Bun. These engines aim to improve the performance of JavaScript. Deno is implemented in Rust, while Bun is built in Zig. These languages have lower-level control and very good performance as they compile to machine code. However, they contain a lot of APIs and code that isn't needed in a serverless environment.

Meet LLRT - the low-latency runtime built from the ground up with one goal: delivering unbeatable AWS Lambda performance for JavaScript developers. Say goodbye to unnecessary APIs and code - LLRT is explicitly designed for serverless environments, so you can enjoy lightning-fast access to information and reap the rewards of cheaper cloud costs.

Serverless computing requires fast and efficient processing to keep costs low. Rust provides high-performance capabilities for next-generation serverless applications. A new runtime for JavaScript developers called LLRT has been designed explicitly for serverless environments, focusing on low latency. It delivers exceptional AWS Lambda performance by removing any unnecessary APIs or code.

Serverless architecture as enabler for low code solutions

ProSiebenSat.1 Media SE is one of the largest German television companies operating in the entertainment sector, offering various products. Joyn, their streaming application used in the DACH regions across multiple platforms, faces many challenges. Serving millions of customers during significant events such as popular shows or live sports events is crucial, where customers expect a fast, seamless experience. Slow responses or unavailability can lead to frustration, dissatisfaction, and loss of trust. It is hard to predict the number of requests because several factors, such as the event's popularity and marketing efforts, can influence it. The "core teams" must design the system to handle high loads. Developing and implementing a robust and scalable system that can endure sudden spikes in traffic is essential. Because of the speed of the entertainment market, it is crucial to ensure that applications can be maintained and extended easily without having to rebuild from scratch every time. My experience leading the ContentDiscovery team has been transformative. I have leveraged a serverless-first approach, event-driven architecture, and no-code development methodology. This combination has allowed for rapid scalability and fundamentally altered how we approach backend unification. Introducing serverless technologies has empowered our team to build a robust and scalable system. The integration of no-code development has been a game-changer in efficiency and innovation. It enables quick prototyping and testing of new features, significantly shortening our product development lifecycle. The versatility of serverless and no-code solutions has facilitated team expansion without requiring deep serverless knowledge. This has allowed us to build a diverse and skilled team capable of navigating the intricacies of our streaming applications. The no-code approach has simplified onboarding processes, enabling team members to contribute effectively without the steep learning curve.
Moreover, combining serverless events and a no-code approach has resulted in substantial cost savings. It has accelerated time to market and reduced overall development costs by freeing developers from focusing on complex tasks and seamlessly integrating with existing applications and data sources. In essence, the marriage of serverless technologies, event-driven architecture, and a no-code approach has propelled our ContentDiscovery team into a realm of faster innovation, heightened agility, and simplified collaboration. It has not only met the challenge of unifying our backend into a single, scalable system but has also set the stage for continuous growth, ensuring that our applications remain maintainable and extensible in the ever-evolving entertainment market landscape.

ProSiebenSat.1 Media SE is a major entertainment industry player known for its cutting-edge streaming app, Joyn, which serves millions of customers in the DACH region. However, delivering seamless experiences during high-volume events can be challenging. By adopting a serverless-first approach, an event-driven architecture, and a no-code development methodology, we have enabled lightning-fast scalability, streamlined collaboration, and significantly reduced costs. This has resulted in a remarkable boost in speed to market.

Serverless Latency is a Thing

Serving millions of customers during significant events, such as a popular show or live sports events, is crucial. Customers expect a fast, responsive and seamless experience, and slow responses or unavailability can lead to frustration, dissatisfaction and loss of trust.
It is hard to predict the number of requests because several factors can influence it, such as the event’s popularity, the marketing efforts. We expect that there might be a spike in requests in a short time.
This unpredictability can lead to slow responses and a bad user experience because the system may need help to handle the sudden increase in traffic. If we do not design the system to handle high loads, it may become overwhelmed and unable to respond to requests on time. This can lead to long waiting times, errors and even crashes, resulting in a poor customer experience and damaging the brand’s reputation.
To prevent these issues, it is essential to design and implement a robust and scalable system that can handle sudden spikes in traffic.
With a Serverless First mentality, our engineering team is always looking to experiment with the latest serverless technology to solve the continuous needs of better scalability, faster response, and less infrastructure maintenance.
But in reality, it may turn out that Serverless Applications are subject to many limitations, and therefore we talk about event-driven architectures(EDA). This talk will show the relationship between best practice and scalability in a synchronous application scenario, ending with an EDA application.
Can a Serverless application scale? The short answer is it depends on the workload. However, several strategies can minimize latency and impact the application’s scalability. If you are wondering what the effects of best practices on a serverless application are, this talk will show the correlation between best practise and scalability.

What I learned building a Scalable, Highly Available Serverless Backend Across Multiple Regions

Managing multi-region applications has traditionally been complex and costly. However, the rise of the "serverless" infrastructure model has transformed this landscape.

I will share what I learned in the last years running a multi-region production services and the benefits and disadvantages of achieving:

Enhanced Accessibility: Serverless infrastructure streamlines scaling and deployment across regions, eliminating the need for manual configurations and expensive hardware.
Cost Efficiency: The pay-as-you-go model removes hefty upfront costs, allowing businesses to pay only for the resources they actually use.
Simplicity: Serverless solutions abstract much of the operational complexity, enabling teams to focus on delivering exceptional products and services.
Superior Performance: Distributing workloads across multiple regions leads to faster load times and improved reliability, enhancing the user experience.

Multi-region applications were once complex and costly, but with "serverless: infrastructure it is not the case anymore. I will share what I learned in the last years running a multi-region production services and the benefits and disadvantages of achieving:

Accessibility: Simplified scaling and deployment.
Cost Efficiency: Pay only for what you use.
Simplicity: Focus on building, not managing.
Performance: Faster, more reliable user experiences.
Serverless makes global-scale applications more accessible and affordable than ever.

Blazing fast serverless with Rust

As a developer, I am requested to optimise only:

* Bootstrap the runtime
* Code run
* Use arm64 architecture

Serverless engineering means we need to take care of many moving parts, software, architectures, security and so on.

The best practise developing with AWS Lambda functions are:

* The Lambda package should be as small as possible
* Initialise my classes, SDK clients and database connections outside of the function handler
* Cache static assets locally in the /tmp directory.
* Doing all this will save execution time and cost for subsequent invocations (Warm start).

On top of these basic rules, maybe it is good to mention:

* Avoiding fat lambda function
* Executing code in parallel when possible

When we are talking about serverless, speed is essential. I am not talking about spending hours of development time saving a few ms, but I am talking about the relation between speed and cost without moving a finger. Speed in a world hyperconnected where everything must be available in real-time is essential, and for few that use this concept at scale, it will result in a cheaper cloud cost.

Rust is the key to unlocking the performance of the next generation of serverless applications. However, thanks to the Single Responsibility Function that reduces the code complexity, Rust has become just a tool, another language syntax that allows me to increase the execution speed more than 9 times. Speed is money.