Many cloud native open source components start with the service and add visualization later. Today I had a brainstorm and went the opposite way: first the visual interaction, then the underlying design.
1. One Canvas Covers Half of Cloud Native
Users only need one canvas. Define the Workflow, and they can roam freely across all kinds of fancy Cloud Native applications.
2. Why This Strange Idea
2.1 Look at Istio
This is Istio’s Bookinfo project. One canvas, drag a few boxes, fill in a few parameters, done.
2.2 Look at Knative
Three typical application scenarios: aggregated services, building lightweight services, and massive pay-as-you-go. Remember to shut it down when you are done, to save money. One canvas, drag a few boxes, fill in a few parameters, done.
2.3 Look at Tekton
A few Tasks and Steps, executed serially β a typical CICD scenario. One canvas, drag a few boxes, fill in a few parameters, done.
3. Abstract It
Whether Serverless or Service Mesh, both have a clear data flow direction. Based on the data flow, you can model it with a tool like BPMN, and ultimately present it graphically.
The process starts with an event. After being processed by the Workflow, the data is converted into the format the underlying layer needs, triggering the corresponding action. Whether it ends up as FaaS or a long-running service can be freely chosen by the user.
The figure below is a demo from the BPMN official site, which can serve as the canvas for the Workflow.
