You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the CNF has strong opinions on what the infrastructure must provide (i.e. “CNF-X will only run in a 3rd-party-provided Kubernetes deployment”), then the economies of scale in both infrastructure costs and operational simplicity are reduced. For example, if an operator must run multiple types of Kubernetes for different CNFs, then the infrastructure and required orchestration software is no longer a commodity. In this scenario, each CNF suite may require more masters and instances of the etcd key-value datastore than is economical, to name one example. Additionally, the different flavors of Kubernetes will require different operational playbooks and potentially will inject more complexity into analytics, application performance monitoring, and infrastructure management. Looking at a service provider’s far edge, it is not feasible to assume that a cupboard-sized data center will be cost effective if the expectation is for that miniature data-center to host an instance of Kubernetes per application. A conforming “Plain Vanilla” flavor of Kubernetes for telcos would ideally run on all different infrastructure architecture including X86, ARM, and RISC and with different form factors due to the different infrastructure composition of centralized data centers and edge data centers.
The text was updated successfully, but these errors were encountered:
If the CNF has strong opinions on what the infrastructure must provide (i.e. “CNF-X will only run in a 3rd-party-provided Kubernetes deployment”), then the economies of scale in both infrastructure costs and operational simplicity are reduced. For example, if an operator must run multiple types of Kubernetes for different CNFs, then the infrastructure and required orchestration software is no longer a commodity. In this scenario, each CNF suite may require more masters and instances of the etcd key-value datastore than is economical, to name one example. Additionally, the different flavors of Kubernetes will require different operational playbooks and potentially will inject more complexity into analytics, application performance monitoring, and infrastructure management. Looking at a service provider’s far edge, it is not feasible to assume that a cupboard-sized data center will be cost effective if the expectation is for that miniature data-center to host an instance of Kubernetes per application. A conforming “Plain Vanilla” flavor of Kubernetes for telcos would ideally run on all different infrastructure architecture including X86, ARM, and RISC and with different form factors due to the different infrastructure composition of centralized data centers and edge data centers.
The text was updated successfully, but these errors were encountered: