Designing a more approachable serverless experience
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.)
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:
- 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:
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.
Too good to be true? Try it yourself!
Booster is an open-source project under an Apache license. It’s currently under active development, but you can already try the pre-release versions installing them from npm:
> npm install --global @boostercloud/cli
-> Check out our step-by-step Getting Started guide to build and deploy your first Booster project in 10 minutes!.
-> Check out the project website or take a look to the Booster repository in Github. We will be happy to host you in our community channel in Spectrum, and you can always contact our team directly via email (info@booster.cloud) or Twitter — our DMs are always open!