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.
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.