App Publishing
(Document status: mostly complete)
Much of the architecture of Obscyra revolves around two key pieces, the "Publisher Client" and the "Provider Client". A publisher is a buyer in the Obscyra network seeking to provision their pod/container on the network. A provider is a seller seeking to offer their hardware for rent.
The planned version of Obscyra takes care of matching the two and provisioning the pod on a specific target provider. While it offers a way to manually pick a provider, it defaults to automatically picking one for the user. However, it does not take care of operational issues that might subsequently arise; specifically, it does not take care of rescheduling pods when a provider becomes unavailable nor does it make any guarantees about uptime or availability of data—those will be handled in later versions. Such concerns are kept track of in the backlog.
Bird's-eye view
On-chain
TEE
Publisher machine
List Providers
Create
Monitor
App Container
Encrypted App Container
Execution request
App Container
Configuration
Execute
Metrics
Execute
Requests
Requests
Registry Contract
Payment Contract
Provider Client
K8s Control Plane
K8s Registry
HTTP Facade
Application Pod
K8s Registry
Publisher Client
External Clients
libp2p/IPFS
As a sequence of steps:
The user starts the Publisher Client to deploy a container
The Publisher Client collects the Pod Manifest
The Publisher Client gets the list of providers from the Registry Contract
The Publisher Client selects a provider, using the configured strategy (automatic or by asking the user to manually make a choice)
The Publisher Client creates a Payment Contract and transfers the initial payment amount (possibly in parallel with steps 5-6)
The Publisher Client bundles up the Pod Manifest, any related resources, and the Payment Contract's address and sends them to the Provider Client over the Deployment sub-protocol, encrypted
The Provider Client creates the relevant configurations for the Pod using the Kubernetes API, including an HTTP Scaler, an Application Pod, and Monitoring
The Provider Client confirms receiving the manifest and resources
When HTTP requests come in, the HTTP Scaler contacts the Kubernetes API in order to scale the Application Pod up
The Application Pod is started using the configuration from earlier
The Application Pod handles the incoming requests
After a period of no requests the Scaler uses the Kubernetes API to scale the Application Pod down
The Monitoring component keeps track of how many e.g. CPU-seconds the Application Pod has run for, and forwards these metrics to the Provider Client
The Provider Client submits the metrics to the Payment Contract and is then able to claim the payment due
Whenever the Payment Contract runs out of funds, the Provider Client removes the related configurations from Kubernetes
3 articles