Dear Zenoh Community,
I'm Emirhan from the Datasance team.
We are based in Istanbul,Turkey and provide an enterprise open source distributed edge computing platform called PoT.
PoT is built on top of the Eclipse ioFog project v3, with major architectural and operational improvements that make it enterprise-ready. In practice, you can think of PoT as the next release of ioFog, and we are working with the Eclipse community to merge our work upstream. I am reaching out in order to discuss replacing ioFog's internal messagebus with Zenoh.
For the ones who are not familiar with ioFog, I am sharing a quick overview about PoT so you can understand how the next ioFog release would be like and what integrating Zenoh to ioFog means for us.
At its core, PoT is:
- Lightweight and Universal: Runs on anything from Raspberry Pis and industrial gateways to servers and VMs. Any hardware with a CPU or GPU can become a secure, intelligent compute node, forming a unified distributed cluster that manages workloads at scale.
- Cloud-Native at the Edge: Brings cloud-native skills and practices to edge-native workloads.
User Interfaces:- "potctl" CLI tool to deploy, manage, and update all cluster resources.
- Control Plane GUI for graphical management and monitoring.
Vendor Agnostic Infrastructure:- PoT's edge device agent is designed to run on any Linux distribution, regardless of hardware brand or processor architecture.
- The control plane can also run anywhere - on any Kubernetes (PoT Operator is certified by both Kubernetes Operator Hub and Red Hat OpenShift Operator Marketplace), VMs, or bare metal servers.
- Both deployment of edge device agents and control plane components are done remotely and automatically via potctl. Within a couple of minutes, everything becomes up and running with all proper security configurations.
Security:- Cluster can easily be deployed with TLS configuration to encrypt Controller APIs.
- User IAM integrated with Keycloak (or any OpenID Connect provider) with RBAC for controller endpoints.
- Edge agent authentication to Controller APIs uses one-time JWT auth, signed/verified by Ed25519 per-agent keypair.
- Built-in X.509 certificate manager.
- All router instances initialized with mTLS authentication config and certificates by default.
- Includes EdgeGuard for physical access protection.
- Watchdog service to kill unauthorized workloads.
- (PS: Air-gap deployment for both cluster resources and microservices is on the way and will be in the next release.)
Workload Orchestration:- Supports both docker and podman as container engines
- Any container runtime (containerd-wasm-shims, crun-wasmedge, Kata, etc..) can be added.
- Allows remote development and deployment of microservices.
- Provides:
- Resource manager, health monitoring, and status reporting.
- Integration with any public or private container registry.
- Built-in certificate manager to generate TLS certificates for microservices.
- Secrets (Opaque, TLS) and ConfigMaps for configuring environment variables.
- Secrets and ConfigMaps can be distributed to Edge devices as volume files that auto-attach to microservice runtimes.
- Dynamic reconfiguration API for microservices to auto-reconfigure without restarting the service.
- Application Templates allow developers to build an internal Edge Marketplace and scale applications to new Edge devices.
- Catalog Image Items help developers handle batch image updates at scale.
- Remote debugging enables site engineers and developers to connect to Edge devices or microservice exec terminals easily.
- Developers can manage the entire lifecycle of microservices - from image to deployment, versioning, reconfiguring, and debugging.
Networking:- The platform automatically builds a Layer 7 by mTLS Skupper router network for:
- Forming a service mesh (by auto-creating and reconfiguring TCP bridges of the router instance):
- Node-to-node communication
- Node-to-external and external-to-node communication
- Internal message bus where microservices connect via the Edge Agent local API.
Our current idea is to attach Zenoh instance automatically as a system-microservice on each edge node based on the agent configuration. Using integrated cert-manager, each Zenoh instance would be provisioned with proper mTLS certificates, similar to how our current router system-microservices are deployed, this would be great to build a secure Zenoh network at scale. Also when a user will deploy a microservice container, auto generated cert for the user microservice would be attached to the container runtime which would help users to easily build and scale edge microservices and applications that are securely connected to Zenoh instances on each node.
As we are trying to re-ignite iofog with lots of improvements on the codebase, and integrating Zenoh as a default messagebus of iofog would also be a great starting point for re-establishing iofog's collaboration network within the Eclipse community.
I’d be happy to arrange a short call with project leads to discuss the technical approach and collaboration process in more detail.
Anyone with thoughts or feedback I’d love to hear from you.
Cheers,
