Datera’s Front-End Architecture 1: A Broader Scope

Our product is made up of several layers, of which the front-end is just one. Below it is a control plane, which is responsible for persistent state management, orchestration, monitoring, and exposing a northbound interface to the front end. Through this interface, the front end reads data from and writes data to the control plane.

The front end itself is responsible for:

  • mapping or translating data from the underlying control plane representation into front-end representation
  • exposing user-facing interfaces for interacting with and managing the product (i.e. GUI, CLI, REST, etc.)

An interesting aspect of Datera’s front end is that it encompasses a broader scope than what we’ve found to be typical in similar products. While the second point above is the basic requirement of any front end, let’s look again at the first point: we have a self-contained mapping layer whose purpose is to define a front-end schema and map objects and data from the control plane’s schema to our front-end representation.

In one sense, this could be seen as duplicating functionality between the front end and control plane, adding seemingly unnecessary complexity. So why did we design the front end this way?

The key overall benefit of this design is that it decouples the modeling and data structures of the front end from those of the control plane. It gives us flexibility to determine, with relative independence, how data should be structured on the front-end in a way that is optimal for the end user. The control plane has other concerns and design priorities — constraints of other layers of the product below it, scalability and efficiency of data structures, etc., which shape their design.

However, I’ve found that the biggest benefit is not a technical one; it is more subtle. The data modeling of the control plane is, of course, a direct reflection of the mental models used by our colleagues in the control plane team. The mental models that we use on the front end — the language, the concepts, the workflows, the object models, etc. — are often very different because they reflect a top-down, user-driven design philosophy.

Reconciling the differences in vocabulary and concepts between the control plane and front-end teams is often a difficult process, and is inherently opinionated and subjective more than it is technical or objective. Rather than dedicate a good portion of our energy on the front-end to continuous discussions and negotiations that require the front-end and control plane teams to agree on a common model that fulfills the needs of both, we’ve instead redirected those efforts to designing and building a layer of abstraction between us.

So, in my opinion, we’ve actually saved ourselves quite a bit of time and energy with this design. In addition, we now have a large degree of flexibility to shape the front-end exactly as we want it, in a way that’s guided first and foremost by our customer’s experience — giving us the tools necessary to deliver on our goals of an elegant, simple user experience.