of disorderliness or “chaos” in a system, or it is a measure of how many states a given system can be in, with more states corresponding to a higher entropy. The First Law of Complexodynamics (Aaronson, 2011) Kolmogorov complexity (1963): The length of the smallest program to output a string. Thus high entropy can have low complexity. Information value of a message is thus linked to its entropy and complexity. 4. Ensure the symbols are correctly recognized (know what API struct to decode into) 5. Interpret the message with the right meaning (=semantics). (Shannon, 1948 + Burgess, 2013) *All information transmission in the end happens through physical particles one way or the other, so there is always room for error and distortion. **Kubernetes was not necessarily designed with Promise Theory in mind. We don’t know if Promise Theory had influence on the Kubernetes design. The Promise of Kubernetes Promise Theory: Based around the idea that actors (humans, controllers, etc.) of a system announce what they can promise to do (define an interface), in a “bottoms up” way, compared to military-style “top-down obligations” (that might be ambiguous). Promises, modelling real-world interactions, might succeed, or not, which forces the system designer to plan for failure, compared to it being an afterthought. You can look at a system’s promises at various scales/levels of detail, where at a larger scale low-level promises “cancel out”. How does Kubernetes relate to Promise Theory?** Kubernetes is a set of controllers promising to fulfill user desired state, communicating through a consistent declarative view of the infrastructure state, defined through APIs with strong semantics. Controllers either promise an outcome to a user or another controller and make use of promises given to them to fulfill actions. Implementation complexity is encapsulated into these controllers, to yield users a lower-entropic / higher-level state-driven interface that can be inspected (unlike Turing machines). The API machinery of Kubernetes designed to transmit intent as reliably as possible, through JSON with explicit type metadata and strong & uniform API semantics. Internal vs external: Consider how controller-to-controller promises in Kubernetes kind of “cancel out” for the end user, they do not need to know how a Deployment implements workload orchestration, only the API surface. Caveat: Hyrum’s law says that all observable behavior is depended upon. CNCF Ecosystem and Entropy Similar to the origin of life, is there a region of time in the growth of the CNCF ecosystem that is favourable to innovation, adaptation and adoption? Kubernetes as a “Platform for Platforms”: It is meant to be built on top of, beyond containers, for controlling arbitrary infrastructure in an uniform way. Kubernetes provides a declarative, extensible, yet uniform API server for storing both (users’) desired and (observed) actual state of the infrastructure. Dunbar (1992) showed that humans have limited capacity for social relationships: this includes technology tools as well. One cannot “know” more than a certain number of tools and patterns. (Just try reading a sentence with 5 clauses). This limits feasible growth opportunities of the CNCF ecosystem, especially if projects do not find ways to “cancel out” complexity through joint promises and interoperability. Can we achieve that? Call To Action: As we grow further, we need to focus on better standards and semantics in the ecosystem to be able to innovate and keep users’ “complexity budget” (Hockin) in check. Avoiding the Heat Death of Kubernetes and the CNCF Landscape Lucas Käldström and Madhav Jivrajani As entropy increases, the ability of a system to do productive work, its free energy goes down. Second Law of Thermodynamics: Entropy can only spontaneously stay constant or increase. Often more entropy => more “complexity”, but a uniform heat death is not really “complex”. Schrödinger explored entropy and meaning of life in 1944, suggesting the existence of highly-ordered human beings is paid for by inevitable human-created chaos. How can two actors communicate? 1. Agree on a set of symbols (=API) to use for information representation. 2. Encode and decode the message accurately (e.g. JSON/protobuf). 3. Ensure any distortion*, noise or errors in the message are corrected, or detected, Project Comparison Dimensions: Can we find common “dimensions” and “promises” of projects for easier comparison and evaluation? This could help users and be part of graduation level evaluation.