Language of the Fog

Situational Awareness

Prior to the introduction of Object Oriented Programming, software development was focused on Data Flow & Logic Programming, or what is also known as concurrent Functional or concurrent Imperative Programming. For those seeking to develop effective software in Fog or Distributed Cloud Computing (i.e. multiple public clouds). The embrace of Logic and smaller chunks of deployed software is critical.

The challenge is management, where previously one Monolithic application could be deployed on a single Virtual Machine, now the same code-base is broken into tens of containers or hundreds of functions. As an industry, we have embraced this trend, continually pushing towards the hundreds of functions as evidenced in TOGAF, OSIMMv2, MicroService Architecture, and C4 Model to name a few.

While the trend towards containerization and atomic functions is largely beneficial for development, the operational complexity increases exponentially, and the need for common approaches and standards for managing this complexity arise.

Foggy Ubiquity was created as a vehicle for sharing a Configuration & Continuous Delivery Meta Language maintained by Keidrych Anton-Oates originally crafted via collaboration with 3 Universities & 35 Industry Publications as a way to address the looming complexity challenge of DevSecOps.

Foggy Ubiquity’s Language was originally authored: June 2017, with companies using the Kubernetes implementation in July 2017

Architectural Compatibility

This is compatible with C4 Model architecture specification, which also means it can be dropped directly into the Arc42 processes.

The selection of C4 was not an easy decision. Ask any Enterprise Architect & they can list of numerous software architecture patterns and standards. C4, however maintained the highest synergy and compatibility with Cloud & Fog Computing at the time of original language authorship. One of the key goals of Foggy Ubiquity’s Language was to maintain compatibility with everyday discussion about DevSecOps. As such the container concept so closely aligning with OCI Containers became a much welcome enabler for Development Security and Operations when using Foggy Ubiquity.

CA Technologies Parallel Decomposition approach naturally integrates with Foggy Ubiquity, C4 Model & Arc42.

Should your software development approach follow a different architecture, Foggy Ubiquity’s Language is still relevant and suitable, as the concepts transcend any specific specification.

Summary of Architecture Equivalence

C4 Model



Software System

Suite of Services






NanoService / Function


Why not use XaaS

CloudFoundry, Kubernetes, MesoSphere, Docker Swarm, and number other Infrastructure, Container, Function, & Flow Programming implementations exist today, and the number will not get smaller over time. But none of them are cross-compatible by design.

Some poignant thoughts about this:

  • shouldn’t you choose how and where your code executes?

  • What if today you wanted to move 100,000 Serverless Functions from one XaaS to another?

  • How long would that actually take to reconfigure and support the new XaaS specification?

Even moving from a 12 month old Kubernetes implementation to the latest can result in significant time-sink due to the API’s migrating and defaults drifting over time.

By providing a Configuration & Continuous Delivery Meta Language, any company’s ability to move between providers on demand is restrained only by the providers implementation of this language. Or one configuration approach to rule them all.

OSIMMv2 paints a picture of 7 Organizational maturity layers, from 3 foundational to layer 7, nirvana or totally Serverless / Function driven. It also demonstrates that moving between any of these layers is a significantly complex operation and often requires redevelopment of software to support the new layer.

This Language enables progression between the layers, and decentralization between XaaS platforms. Or simply Agnostic Computing, or Foggy Ubiquity (hence the name)


Centralized, Decentralized, Federated, are all common Governmental approaches leveraged in both Cloud & Fog Computing. Additionally is becoming more common for companies to transition between these approaches over time. When creating Foggy Ubiquity the Governance challenge was about enabling Federated Governance globally. Even when not in-use by the organization.

This was achieved through setting the expectation that implementations would utilize two types of repositories.

  • Governance

  • Code

Where Software System(s) & Deployment Targets (environments) may choose to place their configuration in the Governance repository while the vast majority of configuration would reside alongside the individual software’s code-base as per the GitOps approach.

To enable Governance, Foggy Ubiquity’s Language providers the concept of Technology Descriptors

componentTarget is not necessary as by definition components are a subsection of container(s) and inherit all of the container configuration.