Overview

The following are brief descriptions of KubeFox concepts.

Event

KubeFox operates on an event-driven architecture, where all requests and responses, including synchronous calls, are conceptualized as Events and communicated as messages among Components via Brokers. The KubeFox Event model offers a straightforward and versatile interface to encapsulate distinct - and optionally typed - state changes.

To illustrate, an HTTP request undergoes conversion by the HTTP Adapter into a KubeFox Event, which is subsequently transmitted to a Broker for routing to a specific Component. The Component can then utilize the Event in a generic manner and, optionally, inspect its type and access type-specific attributes as needed.

Genesis Event

A Genesis Event is an originating Event for a request. It is often generated in response to an external request, such as an HTTP request. However, an internal process, like a CRON trigger, could also yield a Genesis Event. KubeFox dynamically determines the routing of a Genesis Event by matching it to a registered Component Route associated with a Release. Alternatively, the App Deployment and Virtual Environment can be explicitly specified within the Genesis Event, allowing for testing of App Deployments before an official Release is created. Once a match is established, the request context - including the App Deployment and Virtual Environment - is attached to to the Genesis Event all subsequent child Events generated by the Components processing the request.

Component

A Component is a user-written microservice or function that leverages the KubeFox Kit SDK. These Components offer capabilities to meet the requirements of an App. Component source code is stored in a Git Repository that follows KubeFox conventions. KubeFox handles building, packaging, testing, and deployment of Components.

App

An App is an application; a collection of Components which together to provide useful capabilities to end users of the software. Apps serve as the deployable unit in the context of KubeFox. That means all Components of an App are deployed (and optionally versioned) together.

Repository

A Repository is a Git repository housing one or more Apps. KubeFox tracks modifications to Components by monitoring Git commits, and versions Components when Apps are deployed.

Route

A Route matches Events to a handler implemented by a Component. Routes are written in a straightforward predicate-based language that supports boolean logic. A Route can optionally contain logic to extract Event attributes into named parameters, which are then passed to the handler.

Broker

Brokers serve as Event routers, and are responsible for matching and transporting Events between components. Brokers determine the context of an Event and evaluate the corresponding App Deployment to ensure that the Event is authorized to be passed to the matching Component. Brokers also inject Virtual Environment variables and Adapter configurations into Events as necessary.

External Component

An External Component refers to a third-party service. Examples of External Components include PostgreSQL, Amazon S3, and Kafka. Adapters provide communication between KubeFox Components and External Components.

Adapter

An Adapter is a service which converts KubeFox Events to an External Component's API and vice versa. Adapters facilitate the interaction of Components with services that are not native to KubeFox. For instance, the HTTP Adapter translates both incoming HTTP requests and outgoing HTTP calls to and from KubeFox Events.

App Deployment

An App Deployment comprises the definitions of both the App and its Components. This includes the Component's Routes, OCI image name, and any associated Virtual Environment variables or Adapters on which it depends. Initiating the creation of an App Deployment prompts the KubeFox operator to verify a Kubernetes Pod exists for each specified Component.

An App Deployment can optionally be assigned a version, e.g., a semantic version. Once versioned, an App Deployment becomes immutable, guaranteeing a stable, point-in-time App definition. Versioning the App facilitates Release and preserves a consistent and unchanging configuration for the specified version, enabling a return to the version at any point in the future.

Virtual Environment

A Virtual Environment is a collection of variables and Adapter configurations. Virtual Environments enable capabilities like dynamic (at runtime) traffic shaping, and the modification of App behavior without requiring new deployments.

A Component can specify dependencies on Virtual Environment variables and Adapters. At runtime, the Broker extracts required variables from the Virtual Environment, attaches them to Events destined for the Component, and routes the Event. Similarly, the Broker attaches required configuration for Events directed to Adapters.

Because Components can explicitly define their dependencies, Virtual Environments can be validated when Releases are created. Validation guarantees that the required elements are present, thereby ensuring proper functioning of the App Components within the context of that Virtual Environment.

Release

A Release binds a versioned App Deployment and Virtual Environment together, and defaults Genesis Events to the Routes specified in the App Deployment.