Provider Abstraction

Go up to Terms and Definitions

A Provider Abstraction defines a provider-independent representation of the capabilities, operations, inputs, outputs, errors, and lifecycle behaviors required from one or more Providers.

The abstraction separates the requesting software from provider-specific interfaces, software development kits, data formats, authentication mechanisms, and operational details.

A Provider Abstraction allows core functions to request capabilities through a stable architectural boundary while specialized implementations translate those requests into provider-specific operations.

Within the Crucible architecture, the Provider Abstraction supports cloud agnosticism by preventing provider-specific logic from spreading into core modules. A Provider Contract formalizes the obligations of the abstraction, while a Provider Plugin realizes those obligations for a particular Provider.

provider-independent representation of the capabilities, operations, inputs, outputs, errors, and lifecycle behaviors required from one or more providers

Generalized from software architecture, abstraction-layer, portability, plugin, and service-integration usage and specialized for the Crucible architecture and operational model.

A Provider Abstraction does not guarantee that every Provider offers identical capabilities. The abstraction may expose optional capabilities, capability discovery, compatibility rules, or provider-specific constraints through controlled mechanisms.

A Provider Abstraction differs from a Provider Plugin. The abstraction defines the provider-independent model, while the plugin implements that model for a specific Provider.

The Crucible core requests image upload and infrastructure deployment through a Provider Abstraction. Separate Provider Plugins translate those requests into Oracle Cloud Infrastructure or Amazon Web Services operations.