205 lines
6.6 KiB
Markdown
205 lines
6.6 KiB
Markdown
|
+++
|
|||
|
|
title = "Features & Benefits"
|
|||
|
|
description = "Core services, collaboration capabilities, and strategic benefits of the OpenCloud distributed cloud fabric."
|
|||
|
|
+++
|
|||
|
|
|
|||
|
|
# Features & Benefits
|
|||
|
|
|
|||
|
|
Each OpenCloud instance runs a collection of services that allow users to interact with their own deployment and with other OpenCloud participants.
|
|||
|
|
Together, these services form a **federated cloud fabric** that is both technically powerful and strategically aligned with sovereignty goals.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Core Services
|
|||
|
|
|
|||
|
|
### Resource Catalog
|
|||
|
|
|
|||
|
|
The **Resource Catalog** indexes all resources provided by an OpenCloud instance, including:
|
|||
|
|
|
|||
|
|
- **Data**
|
|||
|
|
- **Algorithms**
|
|||
|
|
- **Compute Units**
|
|||
|
|
- **Storages**
|
|||
|
|
- **Processing Workflows**
|
|||
|
|
|
|||
|
|
Every resource is described by metadata (see the `catalog_metadata` definition) and can be:
|
|||
|
|
|
|||
|
|
- **Public** – visible to all OpenCloud peers
|
|||
|
|
- **Restricted** – visible only to selected partners, projects, entities, or groups
|
|||
|
|
|
|||
|
|
Access to specific resources may require:
|
|||
|
|
|
|||
|
|
- Credentials
|
|||
|
|
- Payment
|
|||
|
|
- Contractual or policy-based agreements
|
|||
|
|
|
|||
|
|
This catalog is the foundation for **discoverability, interoperability, and monetization** of resources.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Workspace Management
|
|||
|
|
|
|||
|
|
Each OpenCloud user can create **workspaces** to organize resources of interest.
|
|||
|
|
Within a workspace, users can:
|
|||
|
|
|
|||
|
|
- Aggregate data, algorithms, and compute/storage units from their own instance and from peers
|
|||
|
|
- Prepare resources that will be used in **processing workflows** or **permanent services**
|
|||
|
|
- Structure projects by theme, partner, or business objective
|
|||
|
|
|
|||
|
|
Workspaces make complex, multi-partner projects more manageable and traceable.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Workflow Editor
|
|||
|
|
|
|||
|
|
Using resources collected in a workspace, users can build:
|
|||
|
|
|
|||
|
|
- **Distributed processing workflows**
|
|||
|
|
- **Permanent services** running on top of the OpenCloud fabric
|
|||
|
|
|
|||
|
|
The **integrated workflow editor** provides a user-friendly interface to define and manage:
|
|||
|
|
|
|||
|
|
- Processing chains spanning multiple peers
|
|||
|
|
- Data flows and storage locations
|
|||
|
|
- Execution policies aligned with sovereignty, cost, or performance objectives
|
|||
|
|
|
|||
|
|
This enables **end-to-end distributed workflows** without central orchestration dependencies.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Collaborative Areas
|
|||
|
|
|
|||
|
|
OpenCloud supports the creation of **Collaborative Areas**, where:
|
|||
|
|
|
|||
|
|
- Workspaces and workflows can be shared with selected partners
|
|||
|
|
- Rules and constraints can be defined and enforced (automatically or via manual review)
|
|||
|
|
|
|||
|
|
Examples of rules include:
|
|||
|
|
|
|||
|
|
- Only **open-source components** allowed in the workflows
|
|||
|
|
- **No personal data** allowed, or strict constraints on its use
|
|||
|
|
- Specific **result visibility** and sharing policies
|
|||
|
|
- **Legal and compliance limitations** tied to jurisdictions or contracts
|
|||
|
|
|
|||
|
|
Collaborative Areas provide a robust framework for **governed, multi-party collaboration**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Peer Management
|
|||
|
|
|
|||
|
|
OpenCloud allows you to define and manage relationships with other peers, enabling the creation of:
|
|||
|
|
|
|||
|
|
- Private communities of trusted partners
|
|||
|
|
- Thematic or project-based federations
|
|||
|
|
|
|||
|
|
Access rights and trust levels can be configured:
|
|||
|
|
|
|||
|
|
- At a **global peer scope**
|
|||
|
|
- For **specific groups** or communities within the peer network
|
|||
|
|
|
|||
|
|
This supports **fine-grained, community-aware access control** across the distributed cloud.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Strategic Benefits
|
|||
|
|
|
|||
|
|
### Complete Control Over Data Location
|
|||
|
|
|
|||
|
|
OpenCloud encourages users to **host their own data**.
|
|||
|
|
When external storage is required, OpenCloud allows you to:
|
|||
|
|
|
|||
|
|
- Carefully select **where** data is replicated
|
|||
|
|
- Choose **which peers** can host copies
|
|||
|
|
- Ensure **privacy, compliance, and performance** through data locality control
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Cooperation Framework
|
|||
|
|
|
|||
|
|
OpenCloud provides a structured **cooperation framework** that covers:
|
|||
|
|
|
|||
|
|
- **Data sharing and common workspaces**
|
|||
|
|
- **Usage and access regulations**
|
|||
|
|
- Alignment between **technical mechanisms** and **legal/contractual rules**
|
|||
|
|
|
|||
|
|
This framework is particularly suited for **cross-organization, regulated, or high-stakes projects**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Data Redundancy with Sovereignty
|
|||
|
|
|
|||
|
|
Like public clouds, OpenCloud supports **data redundancy** for availability and resilience.
|
|||
|
|
However, it does so with **finer-grained control**:
|
|||
|
|
|
|||
|
|
- You decide on which peers and in which jurisdictions your data is replicated
|
|||
|
|
- Redundancy policies can reflect **regulatory** or **strategic** constraints
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Hybrid Compatibility with Public Cloud
|
|||
|
|
|
|||
|
|
When workloads require **massive storage or computational capabilities** beyond what your peer network can provide, you can:
|
|||
|
|
|
|||
|
|
- Deploy an OpenCloud instance on a **public cloud provider**
|
|||
|
|
- Use it as an extension of your federated infrastructure
|
|||
|
|
- Offload **non-sensitive or non-strategic workloads** to public cloud capacity
|
|||
|
|
|
|||
|
|
This enables a **hybrid architecture** where sovereignty-sensitive workloads remain under your control, while others can scale on demand.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Fine-Grained Access Control
|
|||
|
|
|
|||
|
|
OpenCloud offers **fine-grained access control** mechanisms that allow you to:
|
|||
|
|
|
|||
|
|
- Define **who** can access **what**, **from where**, and **under which conditions**
|
|||
|
|
- Apply policies at the level of **resources, workspaces, collaborative areas, and peers**
|
|||
|
|
- Combine **technical controls** with **organizational rules**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Lightweight for Datacenter and Edge
|
|||
|
|
|
|||
|
|
The OpenCloud stack is developed in **Go**, generating:
|
|||
|
|
|
|||
|
|
- **Native binaries**
|
|||
|
|
- Minimal **scratch containers**
|
|||
|
|
|
|||
|
|
All selected COTS components for OpenCloud services follow the same design philosophy.
|
|||
|
|
|
|||
|
|
As a result, OpenCloud can run:
|
|||
|
|
|
|||
|
|
- In **datacenters**, to support large-scale processing workflows
|
|||
|
|
- On **ARM-based single-board computers**, to handle concurrent payloads such as:
|
|||
|
|
- Sensor preprocessing
|
|||
|
|
- Image recognition
|
|||
|
|
- Data filtering
|
|||
|
|
|
|||
|
|
Graphical interfaces are implemented in **Flutter** and rendered as **HTML/JS**, enabling lightweight deployment with standard web technologies.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Fully Distributed and Resilient
|
|||
|
|
|
|||
|
|
OpenCloud has a **fully distributed architecture**:
|
|||
|
|
|
|||
|
|
- No central administrator
|
|||
|
|
- No central registry or authority
|
|||
|
|
- No single point of failure
|
|||
|
|
|
|||
|
|
Partners can join or leave the network without disrupting the broader community, making the system inherently **resilient** and suitable for **long-lived collaborations**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Open Source and AGPL v3 Licensed
|
|||
|
|
|
|||
|
|
To foster trust and prevent opaque forks, OpenCloud is released as **open-source software** under the **AGPL v3** license.
|
|||
|
|
|
|||
|
|
This ensures that:
|
|||
|
|
|
|||
|
|
- The codebase remains **transparent and auditable**
|
|||
|
|
- Contributions and modifications remain **aligned with the community**
|
|||
|
|
- Closed, private forks cannot undermine the **trust and openness** of the ecosystem
|
|||
|
|
|
|||
|
|
The source code is publicly available for review, security audits, and community contributions.
|