Resources · Deployment architectures
Where every part runs.
Every Oasis Stack deployment runs the same modules, catalogue and governance model. What changes, offering by offering, is where the management plane and the workloads sit, what the deployment connects to, and who operates it.
FederatedSovereignEnterpriseEdge
At a glance
Who it serves, how it deploys, what it connects to.
Choose the offering first. Each one has its own ways to deploy.
Offering
For
How it deploys
Connection
Oasis Federated Cloud
Cloud operators, MSPs and hosting providers
A multi-tenant operator cloud
Connected to the core, or a private federation isolated in-country
Oasis Sovereign Cloud
Governments and public bodies
Shared national, private government or air-gapped
Isolated by default; joins the federation only by agreement. Air-gapped deployments are disconnected
Oasis Enterprise Cloud
Large enterprises and groups
On-premises or colocated
Federated to the core, or isolated, as the regulator or the business requires
Oasis Edge Cloud
Remote sites, critical-workload DR and smaller rollouts
A mini deployment with selected modules
Syncs with a main deployment on an interval, or replicates to it for DR
Where each part runs
Placement, connection and operation, side by side.
The same architecture, placed differently. The workloads always run on infrastructure you control; the management plane always runs in your deployment.
Part
Federated Cloud
Sovereign Cloud
Enterprise Cloud
Edge Cloud
Admin centre and Federation Core
CloudHost, central and redundant; in-country for a private federation
CloudHost, central and redundant. None for an air-gapped deployment
CloudHost, central and redundant
CloudHost, central and redundant
Through the Federation Core
Licences, publishing, and financial and contractual transactions
The same, by agreement. Nothing for an air-gapped deployment
Licences, and transactions when federated
As for its main deployment
Management plane: Oasis Core and the modules
In the operator’s own location
In-country, in the facilities you nominate
On-premises, or in a colocation facility you choose
At the edge site, with only the modules it needs
Workloads and customer data
On the operator’s infrastructure
On in-country infrastructure
On your own infrastructure
At the edge site, synced with a main deployment on an interval
Connection to other clouds
To the core, or within a private in-country federation
Isolated by default; federation only by agreement
Federated to the core, or isolated
To its main deployment, for sync or DR
Installed and upgraded by
The Oasis Stack team
The Oasis Stack team; on site for an air-gapped deployment, with licences and updates carried in
The Oasis Stack team
The Oasis Stack team
Operated by
Your teams, the Oasis Stack team under a support contract, or shared
Your teams, the Oasis Stack team under a support contract, or shared
Your teams, the Oasis Stack team under a support contract, or shared
Your teams, the Oasis Stack team under a support contract, or shared
How the parts connect is set out on the architecture overview and Federation.
For cloud operators
Oasis Federated Cloud
A multi-tenant operator cloud: your infrastructure, your brand, your customers.
Connected to the core
The operator cloud joins the existing Oasis federation: it publishes services to other clouds, consumes theirs and settles through the platform. Customer data never moves automatically.
Private federation, in-country
A federated cloud for one country. Clouds inside it connect to each other, and the federation as a whole stays isolated from other regions.
For governments
Oasis Sovereign Cloud
A national cloud where the boundary, the keys and the operators are yours.
Shared national cloud
Hosted for many government bodies and departments, each an isolated tenant with its own keys and identity.
Private government cloud
A cloud for one government body, with no shared control plane.
Air-gapped
Fully local, for isolated government bodies and classified environments: no federation and no connection to the admin centre. Installed and upgraded on site by the Oasis Stack team.
For enterprises
Oasis Enterprise Cloud
A private cloud for one organisation, or for a group and its subsidiaries.
On-premises or colocated
In your own data centre, or an in-country colocation facility you choose, on x86 or ARM hardware.
One organisation, or a group
A standalone organisation, or a group whose subsidiaries run as isolated tenants with internal pricing and showback.
Federated or isolated
Connected to the core, or kept isolated, depending on the regulator the business answers to or what the business needs.
A mini deployment
Oasis Edge Cloud
A mini Oasis Stack deployment, with only the modules and features a use case needs.
Remote sites and the field
Data captured at field sites and remote offices, local operations kept running on site, and a sync with the main deployment on an interval.
DR for critical workloads
An edge built only for the critical workloads, replicated so they can recover there.
Budget rollouts
A limited set of modules and features to start with, and more as the use case and the budget grow.
In every deployment
What does not change.
The boundary is a design decision. The platform underneath it is not.
One platform
The same modules, catalogue and governance model, whichever offering and whichever deployment.
Your choice of operator
Run it with your own teams, have the Oasis Stack team operate it under a support contract, or share the work.
Your choice of hardware
x86 or ARM, from the vendor you already buy from, with no lock-in to any infrastructure vendor.
Built, not developed
The platform layer already exists, so launch is decisions, deployment and configuration, not software development.
Sizing and design
Sized from your estate, not from a list.
Platform sizing, the reference architecture and the bill of materials are produced with our architects in the Design stage of an engagement, once the offering and the deployment are agreed.
Who builds what
Built in-house. Extended with alliances.
Every offering runs the same platform. What surrounds it depends on the deployment.
Built in-house
- The same modules, catalogue and governance model in all four offerings
- Federation, when a deployment chooses to connect
- The operating model: run it yourself, or have the Oasis Stack team run it under a support contract
Built with alliances
- Hardware and infrastructure from technology alliances, x86 or ARM
- Funding for federated and sovereign projects, from financial alliances
- Applications and connectors, from marketplace and integration alliances
Talk. Assess. Build.
Not sure which one you are building?
Tell us who the cloud is for and where it has to run. We will tell you which offering it is, and how it deploys.