How to create a DSL

I have blogged about what the uber langauge of compute might look like, but the concept is only roughly sketched.  As the idea takes shape, adding more detail to the design will help in starting development.  As more detail is added, it is time to start thinking about the DSL's and the engines that they will control.
First, what is a DSL in the context of the Uber language?  A DSL (Domain Specific Language) for the Uber language is a specialized syntax that allows the core principles of each of the domains Data, Execution, Resource, and Routing to be expressed.

Envision an engine that handles all the tasks for a particular domain.  For the data domain we have identified different data scopes:   pod, node and data-center  (there may also be some levels between node and data center).  The engine would, among other things, be responsible for creation of data stores at the node and data-center level and volume bindings at the pod level.  It would facilitate the synchronization of data between the components of a solution. It would partition data and it would provide the ability to snapshot data and make this data available to execution (compute) DSL. 

At the implementation level, the DSL exists to define "instance" level data.  At the design level the DSL defines how the engine can be configured.   In UML this is referred to as model and metamodel.  The metamodel defines what valid syntax is, while the model defines instance data.

In the UML world, The first step in creating the meta model is to make a conceptual diagram that outlines all the relevant components in the scope of the DSL.  The goal of this conceptual diagram is to identify the relationships between the components.

Once the relationships have been identified the DSL can start to take shape.  Looking at the conceptual diagram as a representation of the "engine", the DSL's syntax should enable configuration of that engine.  The DSL focuses on what configuration information will change between instances of an engine; what varies from problem to problem.

If you look at Kubernetes and CRD's, this is exactly what is going on.  Kubernetes defines specifications for many objects and instance data is provided that transforms these specifications into working components.

There are many examples of Operators that help to install and maintain databases and data stores and applications.  What the Uber language envisions, is that the cross cutting concerns for a suite of applications can be handled by Domain Specific engines, and these engines can be configured with DSLs;  Operators can be made that maintain each engine and be configured with the DSL.