The ideal platform for real-time cloud native applications

If you are planning to design a new data model and a new API, this post might be interesting, otherwise, just skip it.

A mid-size Biopharma company recently asked us to design a few microservices with data store schema and API. They expected a first beta release with 2 people in 4 weeks. The API had to be super fast, resilient and elastic.

The lead engineer planned to use a commercial database and Spring Boot. He is a nice guy, open minded and pretty smart. He listened when we started questioning his technological stack and finally was willing to try something new.

So we proposed to use Domain-Driven Design (DDD) for the Data schema, Event-Sourcing for the type of Data store, Akka as distributed programming model and gRPC/Protobuf as a way to access the microservices.

We even went a step further than usual: instead of setting up our own Akka Cluster on K8s, we suggested giving Akka Serverless a try which was completely new for us as well.

Akka Serverless is Akka PaaS. It brings developers all the features of Akka (cluster, sharding, location transparency, event-sourcing, etc.) without having to install and configure it yourself. It enables you to focus on business modeling and coding.

Knowing Akka quite well, it did not feel too risky to try Akka Serverless. So, we started defining only two domain entities, to keep the first iteration rather simple. We wrote the Protobuf messaging code, the corresponding Scala code was generated by the Akka serverless SBT plugin and we had to write the code for the business logic.

From the entity point of view, everything is automatic. We didn’t need to care about the database, and storing or retrieving objects. Entity objects are just available if the code knows their unique ids. They are living somewhere as “sharded Actors”, ready to process messages. If they are not used for a period of time, they eventually get automatically passivated. Our testing showed very low latency and very high scalability. The platform seems ideal for real-time cloud native applications.

Our testing showed very low latency and very high scalability. The platform seems ideal for real-time cloud native applications.

Relationships between entities (in traditional database design, I would call it Foreign key relationships, belongsTo, hasMany in Rails or Grails) need a bit of thinking: should entities be in the same service package ? Or separated ? It depends a lot on our DDD model and on the structure of our aggregate roots and boundaries. We ended up implementing the relationships using the Action pattern in a Controller class.

Akka Serveless implements Command Query Responsibility Segregation (CQRS), thus, modifications are totally separated from queries. Those are built as views, similar to Database SQL views.

We are big fans of evolutionary database design, we have not tried it in Akka Serverless but I’m very confident it can be implemented easily.

There are still aspects we need to explore and to understand better. But so far our experience with Akka serverless has been marvelous!