Is there an alternative to spaghetti?

When it comes to food: definitely no. Spaghetti Bolognese needs few ingredients, is quickly prepared and always tastes great - at least to me ;) What I am actually getting at: Spaghetti Code. In contrast to a meal, Spaghetti Code is not eaten up in a few minutes. It stays, is extended, changes, grows and grows and grows. It is the same with microservices. If you start with microservices, you always have to consider how fine-grained services are cut. In the end, the spaghetti effect shifts from code to orchestrating components. This component must now know all the small services and connect them with each other. The same can be found in manual activities that have not been automated or digitalized so far. The process is laid down in a document that is constantly being expanded and changed. Above a certain size and amount of manual activity, maintenance is very expensive.

The described scenarios are of course very exaggerated, and it is of course not set that the spaghetti effect occurs after a certain period of time. Nevertheless, I can report from my own experience that (unfortunately) it ends far too often.

But there are approaches that help to ensure structure, readability and above all maintainability. I would like to take a closer look at one approach here: executable processes or workflows. These include services such as Zapier, Pipedream or IFTTT. These services make it possible to define a process that is understandable and executable. But the services are either too limited or too specialized. A more flexible approach is offered with BPMN. Yes, I know: BPMN? Isn’t that from the time of Cobol? Or before that? Short answer: No. It is not quite that old, but it has been around for over 15 years.

To put it (super) simply, software consists of an action and an execution. The execution can consist of several smaller tasks. At the end of the execution a result is generated.

async function doSomething() {
  const responses = await Promise.all([firstAsyncTask(), secondAsyncTask()]);
  if (responses[0].someAttribute === true) {
    // do some very complex things here
  } else {
    // do some even more complex things here
  }

  if (responses[1].someOtherAttribute === false) {
    // http request to a random service
  }

  return "a very hard-earned result";
}

async function firstAsyncTask(): Promise<{ someAttribute: boolean }> {
  return { someAttribute: true };
}
async function secondAsyncTask(): Promise<{ someOtherAttribute: boolean }> {
  return { someOtherAttribute: false };
}

If you try to explain an execution with more than two tasks to someone, you often use visual aids and write these tasks in circles or boxes, connect them, possibly add branches and so on. BPMN has standardized this visual description. And I would say that someone who has not read the BPMN specification can understand what is happening.

Now what would happen if this visual representation were technically executable? This is where workflow engines come into play. Essentially, the tasks only have to be configured so that they can be executed by software. This can be a script or an HTTP request.

So much for the theory - and for the wish list. And now you can safely think: sure, nice idea, but in practice it won’t work.

With this article I will try to convince you of the opposite. Since it’s not only about theory, I also want to encourage you to see the whole thing in action. What I can already anticipate: you don’t need any BPMN knowledge, you don’t need any technical knowledge about workflow engines and you don’t need to install any software locally. All you need is a Camunda Cloud account and use Restzeebe to quickly see first results.

So if you’ve made it so far, you can sacrifice maybe 10 more minutes? That’s all you need to get your first workflow up and running in the cloud.

Minute 1

Register for Camunda Cloud. Fill out the registration form and confirm your email address.

Minute 2

Log in to the cloud console and create your first cluster. Jump to the cluster details by clicking on the cluster.

Minute 3

Create an API client: this is necessary to communicate with your cluster. You can see it as a key to your cluster. Without this key the door to your cluster will remain closed. Once you have created your client, you will see a dialog with your credentials. You also have the possibility to download a file that contains export statements. This file is the easiest way, because it bundles all information in one file.

Minute 4

Log in to Restzeebe. You can answer a few questions about yourself that will help make the product better and then you’re ready to go.

Minute 5

Import the created client. When you have just downloaded the file, you can enter the entire content into the input field. The necessary information will then be extracted. Alternatively, you can enter all the necessary data one by one: ClusterId, ClientId and ClientSecret.

With the import you have successfully completed the first achievement of Restzeebe.

Minute 6

In the next step you interact with your cluster for the first time. Get the status of your cluster. If this action is successful, you have communicated with your cluster for the first time. So far it was relatively boring - you have so to speak given a ping and received a pong.

Minutes 7 to 10

Now comes the exciting part :) Deploy the first model. Restzeebe deploys a simple first workflow consisting of a start and end event. In between there is an intermediate message event. This means that a started instance waits in the message node until a message arrives that matches the configured parameters.

Open Operate (the link is highlighted) to see your workflows (and instances). Since you have only deployed one workflow so far you will only see this entry on the dashboard.

Now start a new instance. Basically you can start any workflow with Restzeebe. You only need the BPMN Process Id. Since you have deployed the workflow described above it makes sense to start a new instance. The BPMN Process Id of the workflow can be found in the response of the deployment. You have to enter this Id in the input field.

If you now jump back to Operate and refresh the page you will see an active instance. This instance is waiting in the message node.

In the last step you can now send a message to your cluster. In the description of the action you will find an icon that prepopulates the input fields. Send the message and switch back to Operate. The instance should now be finished.

Congratulations, you have executed your first workflow in the cloud!

Isn’t that a bit too easy?

Admittedly it is a very simple workflow. Maybe you are thinking now: Whoa, seriously? I wasted 20 minutes of my life for this? I can only tell you: this is just the beginning. It is your Hello World process.

As described at the beginning, everything is a process. It is certainly not reasonable to model a workflow for every use case and let it run through a workflow engine. But: there are enough examples where it makes more than sense.

I would like to finish this article with spaghetti. Can’t the spaghetti effect occur quickly as well when I design and execute processes? And the answer is very clear: yes. But the big difference from my point of view is that it is clearly visible. And that quickly leads to headaches ;)

I hope you did not expect an alternative recipe that plays in the league of Spaghetti Bolognese ;)