The thought behind Tracepaper

In a previous post, I mentioned we are over the hill, the complex technical preparations are completed. We started designing our application. Designing what exactly? We don't have a roadmap after all.

Our mission is, enabling business-minded people to model performant cloud-native applications while reducing operational burden. We selected Model-Driven Development to separate design from implementation details.

In Tracepaper (our design studio) we promote monolithic thinking because from a business perspective the system has to be viewed as a whole otherwise it would lose its fundamental properties.

A system is a whole that cannot be divided into independent parts. The defining properties of any system are properties of the whole, which none of its parts have.

The essential property of an automobile is that it can carry you from one place to another. No part of an automobile can do that.
The wheel can’t, the axle can’t, the seat can’t, the motor can’t.
The motor can’t even carry itself from one place to another.

You can write; your hand can’t write. That’s easy to demonstrate: cut it off, put it on a table, and watch what it does… nothing!

And, therefore: when a system is taken apart, it loses its essential properties. - Russ Ackoff

For the performant cloud-native application part we chose to use serverless concepts and selected AWS as a vendor to do so. This means that for now at least Tracepaper will only support AWS... sorry folks.

Stitching together monolithic design and serverless implementation means we have to look for a common denominator between those two perspectives. The answer is events. This means we have to treat events as first-class citizens and subsequently use event-driven architecture. I can not tell you how we visually support this in Tracepaper because this is one of the things we are designing at this moment. But we will address this in-depth once we have succeeded.

The important part is, from the business perspective we have a model. And with the aid of a generator, we convert this model into deployable code.

One of our core values is transparency. You may choose to use Tracepaper for your next back-end application, and although we generate code for you, it is your code. We built a modeling studio and a generator, that is ours. But the code that this generator spits out reflects your thoughts. And your thoughts are certainly not our property.

Furthermoe, running your own code in a managed serverless platform is an agreement between you and the cloud provider. You should be reticent to whom you give insight into your applications at runtime. A need to know basis as you will, and we at Draftsman just don't need to know, and thus we won't.

We do trust another company to help us monitor our serverless applications, but I will discuss why we selected lumigo.io in another post.

To sum up, we create an application to manage models that reflect your business domain, this is our design studio Tracepaper. We need a component that converts said models into code. And we want to give our clients full ownership over code and operations.

Component view and ownership perspective

In the high-level design depicted below, you can see a clear distinction between our cloud environment and the client cloud environment. The commit from the generator to GitHub is the handover in ownership.

This does mean, that you will need an AWS and GitHub account besides your Draftsman account. We are aware this may be an extra hurdle for using our platform but we accepted this drawback. Why? because it supports an excellent exit strategy. If at any point in time you decide you don't like Draftsman anymore, you can cut us out, no problem. The code is yours, in a repository that you own and running on machinery that you rent. We strive to make the generated code readable and as maintainable as possible, what you do with it after that, that's up to you.

What we are working on

At the moment we are designing the back-end for Tracepaper, we do this in the XML-based modeling language we invented as input for our generator. A very useful process, we already added some missing features in language and generator. We aim to conclude this stage by the end of this month. The next step is for Delano to integrate the Tracepaper front-end using the prepared building blocks. Meanwhile, I will focus on integrating the last iteration of our generator into the Draftsman Serverless landscape and start working on automation to aid the client in attaching Draftsman, GitHub and AWS together.