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:

  1. Register for a free Akka Serverless open beta account
  2. 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.

Instead, Akka Serverless takes care of all database tasks and ensures the right data finds your service at the right time and in the right context. The best part about that? Those services are written in the language you choose, deployed, and tested with tools you already know! And yes, for the non-Java developers among us (myself included), that means you can use languages like JavaScript and TypeScript to build your services.

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 third, and final, step in the process is all about writing the business logic. Developers only need a single line of code to determine how to handle commands and events and tie them to JavaScript functions. The getCart function gets the data (your shopping cart) delivered to it when it needs to handle commands rather than needing to do a database lookup first.

The magic of Akka Serverless

Those three input parameters of the JavaScript function provide the magic, the databaseless-ness, of Akka Serverless:

  • request is the data of the request which gets sent to your code
  • cart is the current state of the shopping cart, which Akka Serverless keeps up-to-date at all times
  • ctx makes 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.

Share



Filter by Tag