The Missing Abstraction: Why Serverless Feels So Complex
Delegating infrastructure complexity to reclaim focus on business logic.
Software Engineering has constantly strived to climb the ladder of abstraction. The goal has always been the same: let developers focus on the application logic (the “what”) and let the underlying system handle the infrastructure constraints (the “how”).
Today, Serverless computing, and specifically Function-as-a-Service (FaaS), promises to be the next step on this ladder. The idea is fascinating: write a function, deploy it, and let the cloud provider handle scaling and servers. But if you have ever tried to build a complex, stateful application on FaaS, you know the reality is a bit more complicated.
The leaky abstraction of Serverless
Because FaaS functions are stateless, developers are forced to manually manage the state of their application. We aren’t just writing business logic; we are writing code to connect to databases, lock resources to prevent race conditions, implement retry mechanisms for failures, and ensure data consistency.
In a way, we have regressed. While the servers are abstracted away, the complexity of distributed systems is not and it forces us writing “infrastructure glue code” inside our business functions.
Delegating Correctness to the Infrastructure
We believe it is time to raise the level of abstraction again. Developers shouldn’t spend their time ensuring that a counter doesn’t update twice because of a network retry. That guarantee should be provided by the execution environment, not the application code.
This is the vision behind Histrio, a new programming framework developed at Politecnico di Milano.
Histrio revisits the Actor Model and applies it to the Serverless world. By adopting this high-level paradigm, we can hide the messy details of the cloud:
Automated state management. Developers define the actor’s data; Histrio automatically persists it to the database.
Concurrency. Actors process one message at a time. The developer doesn’t need to handle locking code explicitly.
Reliability. The system guarantees “exactly-once” processing. If a failure occurs, the infrastructure handles the recovery, ensuring the application behaves correctly without the developer lifting a finger.
The Cloud as a “Compilation Target”
There is an even more powerful implication to raising the abstraction level.
By decoupling the programming model from the underlying infrastructure, we can treat the cloud provider merely as a compilation target.
With Histrio, application code describes logic, not vendor-specific APIs for FaaS or database services. This opens the door to true portability. Imagine writing an application once and “compiling” it to run efficiently on diverse cloud platforms, on a Kubernetes cluster on-premise, or even across a distributed edge network. This approach naturally solves the issue of vendor lock-in, giving control back to the engineers.
What’s Next?
We are currently working on extending Histrio to support this vision of multi-environment portability (stay tuned for future updates).
In the meantime, if you want to see how we managed to combine the Actor Model with Serverless to reduce code complexity and guarantee data consistency, you can read our full paper:
L. De Martini, G. N. Buttiglieri, A. Margara. “Histrio: a Serverless Actor System”, published in Proceedings of the 19th ACM International Conference on Distributed and Event-Based Systems (DEBS 2025). https://doi.org/10.1145/3701717.3730541
Spot on about the regression here. The actor model approach is clever because its guaranteeing exactly-once semantics at the runtime level rather than making devs hand-code it. I've shipped serverless stuff where like 30% of LOC ended up beign state coordination and retry logic, which is just painful to maintian. Compilation target idea is interesting too btw.