Datum Compute for instant, secure workloads

[zsmithnyc]

High-Level Summary

Launch a container runtime service using Unikraft's microVM technology, as detailed here.

Core Experience

• Enable a "CLI-first" user experience that is supported by appropriate cloud portal elements
• Allow users to build and deploy images via an intuitive workflow
• Help users setup and manage workloads and instances, including basic workload placement
• Implement Galactic VPC (Virtual private cloud networks for Datum Compute using Galactic VPC #594) for public and private connectivity

Business and Observability

• Observability integration for metrics, logs, key audit events, etc
• Determine and implement competitive pricing for vCPU / RAM / data transfer
• Enable metering for compute instance time with Billing and Metering for Datum Cloud using Integration of 3rd Party Metering Service #681

Motivation

We want to help users add intelligence or run workloads at the edge of the network, and capture compute use cases that benefit from edge locations, interconnection to data and clouds, and low latency access.

Non-Goals

We will not aim to compete with pure play compute, hyperscale cloud or alt-cloud hosting companies.

[privateip]

Craft a plan to bring this enhancement back on track with the following key tasks:

• Forward movement on the registry capabilities
• Coupling with the work business metrics (pricing, billing, invoicing, etc) @jacobsmith928 @bmertens-datum need your assistance here
• Short and long term plan for how compute resources attach to gVPC with initial focus on launching single instance compute resources

[scotwells]

Something mentioned in the description of the issue that we don't have any tracking for is our lack of an observability platform to use for exposing logs from the VM to consumers.

We also need to consider what this means in the context of our platform. For container-based workloads, it's fairly straight forward since you can grab stdout / stderr of the container and collect that as the logs for the instance. With Unikraft being more traditional VM based workloads, the user would need an agent running on the unikraft instance responsible for collecting logs they care about and forward them to a collection endpoint that can get the logs to an observability platform we operate.