Yes, Avassa is going to KubeCon! Now lower those eyebrows and hear us out

At Avassa, we believe in thinking about the world in abstractions. Specifically, abstractions defined as “a mechanism which permits the expression of relevant details and the suppression of irrelevant details” to quote the venerable Barbara Liskov.

Avassa’s Approach to Abstractions at the Edge

We are interested in thinking about edge computing as a combination of carefully designed abstractions that cover the concepts of edge sites, applications, and deployments. Our experience this far is that they, taken together, form an excellent foundation for a full-featured platform to manage edge infrastructure and applications easily, securely and at scale.

We even built a product around the idea. We avoid the operational and resource overhead of Kubernetes and associated components in our platform to provide a lightweight, scalable, secure and easy to use edge container management platform.

Kubernetes’s Approach to Abstractions in the Cloud

But we also know that there are other ways of exposing (and consuming) modelled abstractions. After all, the same Barbara Liskov told us that “implementations of the same abstraction can be substituted freely”, which is a pretty neat summary of what became known as the Liskov Substitution Principle.

When Google open sourced Kubernetes in 2014, its API design rapidly became a very popular way of thinking about cloud systems. It’s declarative and state-based, built on a uniform and predictable format of metadata, a spec, and a status, and the APIs cleanly separate intent from implementation which makes it relatively straightforward to extend.

Keep reading: Avassa vs Kubernetes at the Edge

The impact of the design of the Kubernetes API on the industry has been profound. None of the concepts that it sits on were new at the time, but they were combined in a very particular way which introduced a generation of developers and DevOps teams to treating infrastructure as a set of continuously reconciled facts about the world, expressed through a small number of stable concepts. And once people internalized that model, they started looking to apply the same pattern everywhere.

And by everywhere, I mean beyond the narrow scope of Kubernetes clusters, including less obvious things like bare-metal provisioning, databases, and even channel management in Slack. There are even companies that provide tools to extend the Kubernetes APIs “to manage any resource anywhere” including the ability to generate the extensions from existing resources like Terraform providers.

What We’re Bringing to KubeCon

That gave us the idea to explore what edge computing abstractions (the way we like them) would look like through Kubernetes API extensions. Since the foundations of our system is built on the same principles as the Kubernetes APIs including clear separation of configuration and state, schema-driven data validation and declarative semantics. This match allowed us to explore integrating our APIs with the Kubernetes API server, which would allow users with heavy investments in Kubernetes tooling to extend their scope to include on-premises edge computing at scale.

We decided to use Crossplane to integrate our edge-centric APIs as a Kubernetes API extension. And to make it even easier, we use Upjet to generate a Crossplane provider based on our existing Terraform provider. By taking this approach, all we need to configure to make the API extension work is a base URL for a Control Tower instance and a user token to authenticate through the REST API (used by the Terraform provider). And after that, all resources are available through the Kubernetes API for reading and writing using any Kubernetes API-savvy tool (including kubectl).

The result is an interesting exercise in the substitution principle, i.e. how to switch out the backend implementation of specific abstractions, in this case the “frontend” Kubernetes API, while retaining the features of platform to manage and monitor edge systems and containerized edge applications in a declarative way (the Avassa way).

It opens up for a number of interesting approaches to manage applications in cloud environments (running in Kubernetes) lock-step with applications running in the distributed, edge domain through the same API and with the same semantics. A single API across domains, and with well known and understood semantics opens up for a whole new way of designing and building applications across the cloud and the edge.

This approach avoids the problems associated with trying to apply Kubernetes as-is to the edge domain and builds on the strength of a platform that was built from first principles for the edge. The value of targeted deployments, robust offline capabilities, a security posture built for exposed physical environments, but consumed through the tools you already have in place.

Come see it in action at Kubernetes on Edge Day, March 23 in Amsterdam.