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.
|