public:99_annexes:annex-b-terms-and-definitions:c:cloud_agnosticism

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
public:99_annexes:annex-b-terms-and-definitions:c:cloud_agnosticism [2026/09/12 17:42] – removed - external edit (Unknown date) 127.0.0.1public:99_annexes:annex-b-terms-and-definitions:c:cloud_agnosticism [2026/09/12 17:43] (current) – ↷ Links adapted because of a move operation nick_dido
Line 1: Line 1:
 +====== Cloud Agnosticism ======
  
 +[[public:99_annexes:annex-b-terms-and-definitions:start|Go up to Terms and Definitions]]
 +
 +===== Discussion =====
 +
 +Cloud Agnosticism is an architectural characteristic that limits dependence on the proprietary interfaces, services, data formats, software development kits, or operational mechanisms of a particular [[public:99_annexes:annex-b-terms-and-definitions:c:cloud_provider|Cloud Provider]].
 +
 +A cloud-agnostic architecture expresses common capabilities through provider-independent concepts, contracts, and interfaces. Provider-specific implementations translate those common capabilities into the mechanisms required by each Cloud Provider.
 +
 +Cloud Agnosticism does not require every Cloud Provider to offer identical capabilities. The architecture may identify optional capabilities, provider-specific constraints, or controlled extensions without allowing provider-specific logic to spread throughout the core system.
 +
 +[[public:99_annexes:annex-b-terms-and-definitions:c:cloud_agnosticism|Cloud Agnosticism]] can support [[public:99_annexes:annex-b-terms-and-definitions:p:portability|Portability]] by reducing dependence on a particular Cloud Provider. Cloud Agnosticism does not, by itself, establish Portability, because movement to another platform, runtime, deployment environment, or operational context may require adaptation, verification, requalification, or additional evidence.
 +
 +===== Definition =====
 +
 +//architectural characteristic that limits dependence on the proprietary interfaces, services, data formats, software development kits, or operational mechanisms of a particular [[public:99_annexes:annex-b-terms-and-definitions:c:cloud_provider|cloud provider]]//
 +
 +===== Source =====
 +
 +Generalized from cloud computing, software portability, platform independence, provider abstraction, and multi-cloud architecture usage and specialized for the Crucible architecture and operational model.
 +
 +===== Note =====
 +
 +Cloud Agnosticism does not mean that every deployment can move between Cloud Providers without adaptation. Provider capabilities, service availability, identity models, networking, data services, and regulatory constraints may affect portability.
 +
 +Cloud Agnosticism concerns architectural dependence. [[public:99_annexes:annex-b-terms-and-definitions:p:portability|Portability]] concerns the ability to transfer or adapt a system, artifact, or workload between environments.
 +
 +===== Example =====
 +
 +Crucible requests image upload and infrastructure deployment through a Provider Contract. Separate Provider Plugins implement those operations for Oracle Cloud Infrastructure and Amazon Web Services without placing cloud-specific logic in the Crucible core.
 +
 +----
 +
 +<WRAP centeralign>
 +© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
 +</WRAP>