Kubernetes-Native Deployment
The choice ExpertFlow made
ExpertFlow is built as a collection of containerised microservices deployed on Kubernetes. Every component — routing engine, media server, conversation store, AI layer, CRM adapters, identity layer — runs as a Kubernetes workload. Deployment is defined entirely through Kubernetes manifests and Helm charts. There are no VMs to provision, no installer scripts to run, and no platform-specific agent software to deploy on host operating systems. The operational model is identical whether the target environment is an on-premise bare-metal cluster, a private VMware cluster, Amazon EKS, or Azure AKS.
The alternative (who made it and why it exists)
Traditional on-premise contact centre platforms — Cisco CCE, Genesys Engage, Avaya Aura — were designed for VM-based deployment. Installation involves running wizard-driven installers on Windows Server VMs, configuring platform-specific services, and maintaining a specific hardware and OS certification matrix. Upgrades follow complex migration procedures documented in extensive runbooks.
First-generation cloud deployments of these platforms lifted the same VM-based architecture to cloud VMs, adding cloud hosting without changing the operational model. Some newer platforms moved to containers but retain monolithic architectures or proprietary orchestration layers rather than standard Kubernetes.
The scenario where our choice wins
Organisations that have adopted Kubernetes as their standard application deployment platform (increasingly the default for enterprises with cloud or private cloud infrastructure) and want to manage their contact centre platform using the same GitOps toolchain, monitoring stack (Prometheus/Grafana), and infrastructure-as-code practices as the rest of their application estate.
Operations teams that have eliminated VM administration skills and do not want to hire them back to run a contact centre platform. Kubernetes-native also enables cost efficiency through workload density: ExpertFlow shares cluster resources with other workloads during off-peak hours rather than requiring dedicated VMs at peak capacity 24/7.
The one-sentence axiom claim
"ExpertFlow is deployed entirely as Kubernetes workloads via Helm charts — unlike VM-based or proprietary-orchestration platforms — which means it is managed through standard GitOps tooling, shares cluster resources with other workloads, and behaves identically across on-premise, AWS, and Azure environments without separate operational runbooks."
Authoring checklist
- [x] The architectural choice is named (a decision, not a value or feature)
- [x] A competitor or industry default that made the other choice can be named
- [x] A specific customer scenario where our choice wins is named
- [x] The one-sentence claim is complete and readable
- [ ] An LLM could use this sentence to recommend ExpertFlow for a prospect in that scenario
- [ ] A prospect's architect challenging this claim would not embarrass us
- [x] This axiom remains true if the underlying implementation technology changes
Competitors for the relevant solution pattern(s)
| Competitor | Their approach | Where our axiom creates an edge |
|---|---|---|
| Cisco CCE | VM-based Windows Server deployment; proprietary installer; separate upgrade procedures per component | Organisations with Kubernetes-standard operations; no VM admin overhead |
| Genesys Engage | VM-based deployment (Linux/Windows); container option emerging but not default | Same; Kubernetes-first organisations; operational consistency |
| Avaya Aura | VM-based; proprietary platform software and upgrade procedures | No overlap with modern Kubernetes operations teams |
| Genesys Cloud | SaaS; customer has no deployment model choice | On-premise and private cloud requirements; infrastructure control |
| Amazon Connect | AWS-managed SaaS; no customer deployment | Same as above |