Designing a more approachable Serverless experience

The Agile Monkeys
Oct 30 · 4 min read

By The Agile Monkeys’ innovation team: Javier Toledo, Álvaro López Espinosa, & Nick Tchayka, with reviews and contributions from many other people in our company.

After having used serverless technologies for a wide range of projects over the past two years, we still see a couple of friction points (You can dig into more about that in this previous post.)

It’s easy to underestimate the effort required to learn serverless technologies!

If a genie gave us three “wishes for Serverless,” we would probably ask for:

  • Smoother learning curves beyond the getting-started guides.
  • Easy-to-use conventions and standards for common recurring problems.
  • Abstractions that make it easier to represent business rules in the cloud and keep the domain model consistent.

But looking at the cloud service offerings available, you can see that instead they’re becoming more and more powerful at the expense of higher learning curves: the number of low-level details that you have to learn just to choose the right services and configure them effectively is overwhelming. That’s why we have started to think about the cloud as a new kind of operating system. In the same way that any classic OS fully abstracts out the hardware of a machine and provides a set of basic services, the cloud providers hide the fact that there are some physical servers running the code of your lambda function somewhere, and provide plenty of services as building blocks to build complex applications on top of them. The cloud provider guarantees that they’ll take care of resource allocation as needed and free you from the management and security responsibilities.

This realization made us start thinking that, while we have compilers/interpreters for high-level programming languages that allow you to use OS services transparently, we still don’t have a tool that provides the same experience for serverless applications. Could we make a high-level program, fully written at a business-logic level, to work on the cloud without having to write a single line of configuration or learn any low-level details of cloud services?

This is how we started our boldest project to date:

Booster is a new kind of framework that allows you to write a high-level Typescript program in terms of commands, events, entities, and handlers and run it seamlessly in your cloud provider in a zero-config fashion.

Booster is built on top of a set of highly opinionated conventions and sensible defaults, based on our experience developing and managing high-scale applications. The whole infrastructure is inferred from code on deploy time, so you can focus on your business logic.

Booster’s architecture is heavily inspired by the CQRS (Command-Query Responsibility Segregation) and Event-Sourcing patterns:

Booster Architecture is based on CQRS and Event-Sourcing patterns
  • Commands: A command is a class that defines an intent. In addition to the data fields, it requires a handler method that can process the commands and optionally generates and persists one or more events to the event store. Commands define the mutations or write API.
  • Events: An event is a data structure that represents a record of a fact; events are the source of truth for the whole application. Events can have handler methods attached that allow the system to react to them, creating new commands or events. Events are stored in an event store, a database optimized for event-streaming and fast reductions of entity states.
  • Entities: Entities are domain objects that represent concepts within the problem you’re solving. They’re instantiated dynamically from the event stream to be able to make decisions in command handlers based on the current state. All events in Booster are tied to a specific entity instance, so a stream of events and the entity state are two different views of the same data.
  • Read Models: Read Models are cached denormalized data, optimized for reading. They’re updated reactively using a set of projection methods. They define a schema that can be queried or subscribed to from a user application. The Read Models are automatically stored in a Read Model Database and they define the query or read API.

The best way to get a feeling for Booster is to watch the demo video. Let’s build a scalable cart service in less than 10m that can handle 300 requests/second over 10 seconds:

With Booster you can create a Cart service that can deal with the traffic of a Black Friday in less than 10m!

Booster is currently under active development, and we will release it under an open-source Apache license as soon as we get to the 1.0 version. That will allow anyone to use Booster in their projects or extend it in ways we never imagined. If you just can’t wait to get your hands on it, there’s a waiting list to access the private beta on the project website.

This is how we envision the future of Serverless: “Serviceless” and “Configurationless.”

Trying to remove the accidental complexity from code has been a goal for the software development communities for decades, and with Serverless technologies we can get closer than ever to that goal. This is how we envision the future of Serverless: “Serviceless” and “Configurationless.”

Booster sets a new level of abstraction to build cloud applications, being able to focus just on code that really brings value to your organization and users.

Feel free to send your questions and thoughts to labs@theagilemonkeys.com or contact us via Twitter — our DMs are open!

We write about what we learn and what we think.

The Agile Monkeys

Written by

The Agile Monkeys’ Journey
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade