Article
What three clusters cost a bank: BKE and OpenShift compared
Most comparisons between Kubernetes distributions are written as feature matrices. A bank does not buy a feature matrix. It buys a licence for an estate it already has in mind, and it renews that licence every year for as long as the estate runs. This article sets out what that licence costs for one realistic estate, and two matters that a price list does not show: what each product installs on the bank’s clusters, and what it would cost the bank to leave.
The bank in this article is illustrative. The arithmetic is not, and the same calculation is published with the figures derived on the BKE cost-of-ownership page, where the reader can substitute the rate from their own quote.
The estate
The bank operates in Saudi Arabia and runs its container workloads in three environments, each a separate cluster with its own control plane:
| Cluster | Workers | Cores per worker | Worker cores |
|---|---|---|---|
| Production | 4 | 32 | 128 |
| Staging | 4 | 16 | 64 |
| Pre-production and performance testing | 4 | 32 | 128 |
| Total | 12 | 320 |
The environments are kept apart deliberately. A load test in pre-production must not be able to affect production, and an upgrade should be proven on staging before it reaches either. Only worker cores are counted: Red Hat does not charge for OpenShift control-plane nodes, or for infrastructure nodes that carry no application workload, and BKE does not count nodes at all.
The four figures
OpenShift is licensed per core, at rates negotiated with each customer. For this comparison we assume a heavily discounted rate of US $1,850 per worker core per year, including Red Hat’s support subscription. A bank with a lower quote should use it; the BKE figures below do not depend on it.
BKE is licensed at US $12,000 per cluster per year, whatever the cluster’s size. The Mamluk Enterprise Helm Charts, which supply the platform services applications depend on, are licensed at US $60,000 per organisation per year, irrespective of the number of clusters. Support with a four-hour response time, together with consulting time for the bank’s own engineers, is US $5,000 a month.
| Arrangement | Per year | Over three years | Per worker core |
|---|---|---|---|
| OpenShift | US $592,000 | US $1,776,000 | US $1,850.00 |
| A. BKE | US $36,000 | US $108,000 | US $112.50 |
| B. BKE and the Helm Charts | US $96,000 | US $288,000 | US $300.00 |
| C. BKE, the Helm Charts and four-hour support | US $156,000 | US $468,000 | US $487.50 |
Arrangement A is not equivalent to OpenShift, and we do not present it as such. It is a production-grade Kubernetes cluster with storage, ingress, certificates, logging, monitoring and a service mesh available to enable, but without the managed databases and caches that applications need, and with the standard support that comes with the licence.
Arrangement C is the comparison a bank should make. It adds the platform services — databases, caches, message brokers, logging and CI/CD, each production-ready with replication, backups and upgrade paths already decided — and a support contract with a four-hour response time. On the assumed rate, OpenShift costs 3.8 times as much as arrangement C: US $436,000 a year more, or US $1,308,000 over three years.
The comparison leaves out the hardware, the data-centre space and the engineers who operate the estate, because those are broadly the same under either product. One difference that does not cancel out favours BKE: it runs on Debian, which carries no operating-system subscription.
The cost of growth
A per-core licence is priced on the estate as it stands on the day of the quote. The estate will not stay that way. Adding one 32-core worker to production adds US $59,200 a year to an OpenShift subscription at the assumed rate, and nothing to BKE. A disaster-recovery cluster the size of production, which a regulated bank will usually be asked for, adds US $236,800 a year to OpenShift and US $12,000 to BKE. The Helm Charts licence is per organisation, so it does not change at all.
Per-core licensing also has a less visible effect on architecture. Because every core is charged, organisations under budget pressure consolidate development, staging and testing into a single cluster divided by namespace. That saves licence cost by giving up exactly the separation described above. A flat fee per cluster removes the incentive, so the bank can decide how many clusters it needs on engineering grounds alone.
What is installed is what is operated
OpenShift is itself run by operators. A new cluster carries roughly thirty cluster operators under the Cluster Version Operator — covering authentication, the web console, the image registry, monitoring, the router, machine configuration, the Operator Lifecycle Manager and the marketplace, among others — and each installs its own custom resource definitions. Since OpenShift 4.11 a limited set of optional capabilities can be left out at installation. The core of the platform cannot: the Machine Config Operator manages the nodes, the router handles ingress, and OpenShift’s own APIs, including Routes, SecurityContextConstraints and the cluster configuration resources, are present on every cluster whether or not the bank’s applications use them.
This matters to a bank for reasons that have nothing to do with price. Every installed component is software that the bank’s engineers must understand, that its security team must assess, and that its change process must carry through every upgrade. A component that is installed and unused still has a version, still receives patches, still adds resource definitions to the cluster’s API, and still appears in an audit.
BKE takes the opposite position. It makes two decisions: the network fabric, which is Calico, and the Kubernetes version, each pinned to the exact patch. Calico brings its own upstream resource definitions; beyond those, a new BKE cluster carries the API of upstream Kubernetes and nothing more. Storage (Longhorn), ingress and API gateway functions (Kong), certificates (cert-manager), a service mesh (Kuma), log shipping (Fluent Bit), monitoring (Netdata) and resource metrics (metrics-server) are each enabled by one line in the cluster’s configuration, and none of them is installed until it is enabled.
A bank that already operates an enterprise load balancer, a central log platform and its own certificate authority does not enable the corresponding components, and they are not present on its clusters. The Helm Charts follow the same principle: the bank installs the charts for the services its applications use, in the clusters that need them. There are no editions and no feature flags in either product, so leaving a component out does not change the price, and enabling one later does not require a new contract.
The cost of leaving
A bank should price the cost of leaving a supplier as well as the cost of staying with one. Neither BKE nor the Helm Charts runs an application of ours on the bank’s clusters, and that is what keeps the cost of leaving low.
A BKE cluster is upstream Kubernetes, installed with kubeadm and running upstream components at tested versions. There is no fork, no proprietary resource definition and no control plane of ours in the data path. If the licence lapses, the cluster continues to serve traffic; the licence governs installation and upgrade only. A bank that leaves BKE keeps its clusters as they are and takes over their upgrades with the same upstream tools BKE uses. Its workloads are standard Kubernetes manifests and need no rewriting.
The Helm Charts deploy the upstream releases of the applications they manage — MySQL, Valkey, Memcached and others — and the data those applications hold is in each application’s own format. What the charts add is the operation around them: replication and failover, backups and point-in-time restore, disruption budgets, anti-affinity and network policies. A bank that stops licensing the charts can move each service to a community chart or an operator of its choosing and keep its data. What it gives up is the automation the charts provided, which then becomes its own to maintain.
An estate that has run on OpenShift for several years is in a different position. It has usually adopted OpenShift’s own APIs: Routes in place of Ingress, SecurityContextConstraints in place of the standard admission model, DeploymentConfigs and image streams, and platform operators that own the lifecycle of its services. Each must be found and replaced before the workloads will run on another distribution, and that work grows with every year the estate remains.
The consequence for the bank is that its contract with us must be renewed on its merits every year. That is the arrangement we intend.
Support in the region
The bank’s working week, holidays and regulators are in Saudi Arabia. Every other major Kubernetes distribution is engineered and supported from Europe or the United States, which means that a ticket raised in the Gulf afternoon is commonly answered the following day. BKE and the Helm Charts are built and supported from within the GCC, and the four-hour response time in arrangement C is provided by engineers working in the same region and the same hours as the bank.
Where OpenShift remains the right choice
A bank with an existing Red Hat enterprise agreement, an estate standardised on Red Hat Enterprise Linux, or a requirement that one vendor own every layer including the operating system may reasonably choose OpenShift. So may a bank that wants OpenShift’s developer console and build tooling as the product itself. BKE deliberately leaves the operating system with the customer.
For a bank that wants Kubernetes it can name, version and keep, the figures above are the starting point. The cost-of-ownership page carries the same calculation, and a 14-day BKE trial is self-service at console.maml.uk.