Cloud and edge are architectural choices, not competing slogans. European projects should decide where computation and data belong based on latency, resilience, control, energy, cost and legal requirements.
What matters most
Edge processing can reduce latency or data movement but adds operational complexity.
Cloud portability requires architecture, data and commercial planning—not just containerisation.
Connectivity requirements should be measured for representative conditions.
Data location and control can affect procurement and compliance decisions.
Interoperability should include identity, management, observability and exit processes.
Technology-sovereignty discussions do not remove the need for practical total-cost analysis.
Questions to answer before acting
Use these questions to turn a broad topic into a defined decision, test or work package:
- Which workload belongs at device, edge or cloud?
- What happens during network loss or provider failure?
- Which data-location and control requirements apply?
- How will the organisation switch or integrate providers?
A practical sequence
- Step 1. Classify workloads by latency, data and resilience.
- Step 2. Model representative network conditions.
- Step 3. Define interoperability and exit requirements.
- Step 4. Pilot operations, monitoring and failure recovery.
- Step 5. Compare full lifecycle cost and control.
Common traps
- Using edge without an operational reason
- Assuming portability from one technical feature
- Testing only on ideal networks
Where this fits in the wider system
This topic belongs to the site’s Strategic technology infrastructure pillar. The strongest route normally connects several pillars: a research result may need a testbed, a consortium, an appropriate programme, standards work and a scale-up plan.
Use the planning tools to identify the next uncertainty, then verify the route through the official-source directory.