In our first post, we described our primary wish "Model complex business domains in a no-code environment" and two core values:

1. Full code transparency.
2. Full run cost transparency.

In our second post, we described our key constraint "limited manpower", 2 engineers, and the project has to be built during free-time. Although this project started in 2020 and with the absence of social activities the amount of time available for learning, fiddling, and experimenting was above average compared to other life years.

Nevertheless, we decided to focus our efforts towards our primary wish, modeling an application with visual concepts will be our core business. Everything else on our wishlist will be handled by a large cloud vendor, to select a vendor we have to figure out what we need. So let's make a high-level design (HLD).

High-level design

Context

The purpose of this HLD is to select a cloud vendor, this means we can ignore parts of the desired solution that are supported by every large vendor. Commodity services like, build pipelines or version control.

We know we want to use serverless concepts, Function as a Service (FaaS) springs to mind. But, serverless is more than just FaaS.

What is Serverless?

If you search the web you will find different definitions for serverless, there is no right or wrong but to understand the context of this project I will state what our definition of serverless is:

If we, at Draftsman, talk about serverless we mean, making optimal use of fully-managed services be it compute, storage, IAM, workflow management, in essence, everything that normally requires a server. By fully-managed we mean, we don't want to worry about maintenance, patching, upgrading, or scaling and we expect to be billed for use and not per hour.

HLD

For the design, we started with what we know, we know we want to talk about commands, aggregates, and events. The reason for this is, it a great way to accommodate Ubiquitous Language a crucial ingredient to make our idea work. I perform an "action" on a "concept" in my domain and "something" happens.

It also made sense to us to use separate models for reads and writes, this pattern is called Command Query Responsibility Segregation. Maybe we are biased by our day job, but it looks fairly common that a lot of mapping is involved to create a read API.

To accommodate the two choices we made this far we will use an event-driven architecture. Events are great to maintain loose coupling in our systems, components react to "stuff" that has happened in the domain, this is called choreography and it is a great pattern to model "if-then-that" relations. Although this pattern is great, it comes with complexity and we always should be reticent about adding more complexity. Not everything is an "if-then-that" interaction, sometimes there is an intention behind our interaction and in these cases, we should use orchestration, this is where workflow management comes in.

Shopping list

Once we know the broad strokes of our design we can assemble a shopping list containing the services we need.

1. Function as a Service for al computation.
2. Database, to hold state.
3. Queues and topics for messaging.
4. Orchestration service for workflow management.
5. Identity and access management.
6. API gateway, to access our functionality.
7. Infra as Code, to stitch everything together.
8. Build tools & pipelines to enable zero-touch deployments.

The criteria to be classified as fully-managed in our context:

• maintenance
• patching
• upgrading
• scaling
• pay per use not per hour

Vendors
We looked at a couple of large vendors who offered FaaS like AWS, Azure, Google Cloud, IBM, and Oracle. And in all honesty, in the end, the decision was made on "feel". AWS was the first vendor that was researched because this was the only vendor we had no experience with (positive or negative) and there was an immediate spark. The documentation was comprehensible and they were feature complete, and that they are named cloud leader for 10 consecutive years by Gartner doesn't hurt either. We did take a look at the other vendors, some were feature complete some were not. Could we built what we want to built with one of the other vendors? Probably, but once you are in love, you are in love, right?

I'm not giving more detail about the other vendors because I made this choice almost 1 year ago and as we all know, a year is a long time in the realm of cloud technology, so everything I'll say will hopelessly be dated.