Introducing Akka Serverless (Open Beta)
Akka Serverless - Serverless and State, Without the Hassle
We are proud to announce the open beta of Akka Serverless. Akka Serverless is the first and only developer platform that combines the scalability and ease of use of current serverless models with the responsiveness of business-critical stateful applications into one managed, cloud-based environment.
If you want to try out our new platform and experience the magic of stateful serverless, you can:
- Register for a free Akka Serverless open beta account
- Watch our launch event on June 16th, featuring Jonas Bonér (our founder and CEO), James Ward (Developer Advocate at Google), Rob Howes (CTO of Judopay), and myself.
The spectrum of serverless
Serverless is a spectrum of capabilities that developers can leverage without having to worry about undifferentiated heavy lifting. I know that for a lot of people the terms Functions-as-a-Service (FaaS) and serverless are equivalent, but they are quite separate.
FaaS is absolutely the cornerstone of serverless technology today, but there is so much more out there. There are serverless databases, message brokers, analytics tools, object storage, and I can probably go on for some time. In other words, FaaS is always serverless but serverless does not always mean it has to be FaaS, many other tools and technologies fit into the spectrum.
With Akka Serverless we’re changing the game! Akka Serverless combines the database and function runtime into a single package. That combination allows developers to take a radically different approach with serverless. It lets developers think about the data structure for their service and not about the database. It enables developers to think Stateful Serverless, and it empowers them to think databaseless!
We live in a world where we will generate more data in the next three years than in the last 30 combined! At the same time, we need to use that data to make better decisions faster than ever before. To sustain that, developers build complex application topologies with different databases, message brokers, caches, and clustering technologies to make sure that the thing that sets us apart, our business logic, works.
One of the best features of serverless is not worrying about servers. At the same time, traditional FaaS platforms can be limiting. Looking at all that data, you almost need a Ph.D. in distributed computing and distributed data to make everything work. That just isn't going to cut it, you want to use tools, technologies, and languages you know.
That's where Akka Serverless comes in! With Akka Serverless we bring together the database and functions into one package so that you don't have to worry about maintaining any of the infrastructure, version compatibility, or other Ops nightmares.
Now show me the code!
I understand talk is cheap! Let's walk through how you can build services for Akka Serverless using three straightforward steps. With Akka Serverless we've taken an API first approach using Protocol Buffers.
Step 1 - Defining your API
The first step in the process is to describe not only the API itself but also the data structure for a service. That way, a developer can focus on the data structure for their service without needing to think about a database. It means a developer can make the structure as complex, or straightforward, as it needs to be for the service without thinking about how it fits in a relational database or NoSQL database.
In the example below I've created the outline of a shopping cart API and modeled a data structure for the method to find a specific shopping cart for a customer. The CartRequest message has a special annotation next to the user_id field. That annotation tells Akka Serverless how to find the right data, the shopping cart, when this message arrives.
A major benefit of using Protocol Buffers to describe the API is that you get a gRPC endpoint right out of the box and you can add in additional ways to expose a service, like HTTP or a message bus, knowing that Akka Serverless handles the connectivity needed. As a developer, I only need one line of configuration to add an HTTP endpoint for the shopping cart.
Step 2 - Choosing a state model
The second step in the process is to choose a state model. A state model impacts how your data behaves at runtime. While you can easily change them later on, it doesn’t hurt to think about choosing the most appropriate one for your use case. Akka Serverless supports Value Entities and Event Sourced Entities:
- Value Entities: These follow a more traditional approach of storing data, only the current state is persisted;
- Event Sourced Entities: These store all events in a journal, so every data change is kept and services can read all events to keep current.
The state model reflects how a developer would think about using persistence. The five lines below essentially represent how the developer interacts with a database without ever knowing or needing to know it’s there.
Step 3 - Writing the business logic
The magic of Akka Serverless
requestis the data of the request which gets sent to your code
cartis the current state of the shopping cart, which Akka Serverless keeps up-to-date at all times
ctxmakes sure you can interact with other parts of the Akka Serverless runtime
The thing you don't see in that code is a call to a database, either to get data or save data. That's all taken care of by Akka Serverless. For me, as a developer, it means I don't worry about the exact SQL syntax of an update statement or how I ensure that my data is consistent across service invocations. That's all done for me, by Akka Serverless!
Sign up and learn more
Today we're proud to launch the Open Beta of Akka Serverless, so you can try it for yourself and experience the “magic” of Akka Serverless. Simply visit the registration page and you're off to build your first stateful serverless service. You can also watch our public launch event where we dive even more into the technology.