[PinkPigeon]

Small nitpick, I just read half the page with a 50% opacity overlay on it, as the cookie pop-up shows up in the middle of the page, not the middle of my current screen, which can be caused by setting an absolute width against a relative parent, or setting position to fixed but then using percentages instead of vw / vh attributes in CSS...

As someone knee deep in the 'serverless' world, I am also interested in what exactly this does that couldn't be solved by any number of key / value stores, like Cloudflare offer.

Call me a cynic, but it feels like we are slightly going round in circles, like "we have found that adding a database to our database-less services is a great idea" (even if that database is in the cloud and distributed and therefore low management and high reliability)

But maybe I am just missing the point here. Still seems like an interesting product and I don't want to come off as dismissive or discouraging.

[jroper]

With Akka Serverless, the mental model is that you are deploying entities, not code. Depending on the state model you select for a particular entity, Akka Serverless will shard or replicate these entities across many nodes to serve them - with the replicated entity state model, this means your state is at the place it needs to be already before a request is received regardless of where that request is received, with event sourced and value entity state models, this will route the requests to the correct node so that the processing is brought to where the state is. When you receive a request, there is no need to go get the state first, like you would with a key value store. Your entity already has the state, your entity is the state. You just write the logic to process the request given the state. You can do whatever operations you want on your entity without worrying about consistency or conflicts, because Akka Serverless ensures that that entity only lives on one node (or for replicated entities, using CRDTs to ensure conflict free updates). This is revolutionary compared to using a key value store - with a key value store, two nodes trying to update the same value at the same time will overwrite each other. With a key value store, two nodes trying to update the same value will contend with each other and potentially slow each other down, whereas with the sharded entity models, only one request operates on an entity at a time, or with replicated entities, two nodes can update the same entity independently and their updates will be merged without conflict asynchronously, they won't contend with each other or slow each other down.

Akka Serverless then also lets you define views on these entities - this is not something that is easy to do with a key value store, keeping the projection and the values in sync, ensuring that even when there's an error part way through an operation, that you don't end up with partial updates where the value is updated but the view isn't, ensuring that updates of the view are isolated from updates of the value to maximise performance, etc.

Akka Serverless is about inverting your view of how you see state. State isn't something that lives somewhere else that you manipulate, separate from your code. State is what you deploy. Akka Serverless gives you state models that are designed for distributed systems (which a serverless platform is), they scale, are fault tolerant, and are built on decades of computer science research.

[PinkPigeon]

Thanks for the explanation, much appreciated!