In the short term we plan to develop following the model of the CNGI prototype benchmarks: modifying containers from open source application deployments (provided via helm charts) to add our own runtime dependencies. This approach should be fine to prove concepts but I expect it will not satisfy the requirements of production-grade operations, as we will want to build our own deployment, including new containers.
In the short term we plan to develop following the model of the CNGI prototype benchmarks: modifying containers from open source application deployments (provided via helm charts) to add our own runtime dependencies. This approach should be fine to prove concepts but I expect it will not satisfy the requirements of production-grade operations, as we will want to build our own deployment, including new containers.
Ultimately if we want our applications to scale using the Kubernetes API then it’s probably better to build and deploy our own images. We should be composing workloads out of our domain specific functions (e.g., front-end, back-end, coordination; whether stateful or stateless, following commonly expressed design patterns) assembled into pods running OCI-compliant containers, connected by service definitions to expose them to users at the application layer.