BKE vs OpenShift · Cost of ownership
A bank, three clusters, 320 worker cores.
A worked example of what a regulated bank in Saudi Arabia pays each year to run production, staging and performance testing on OpenShift, set against three ways of running the same estate on BKE. The bank is illustrative; the arithmetic is not, and every figure below can be recalculated with the rate from your own quote.
The estate
One environment is one cluster.
The bank keeps its environments in separate clusters, so that a load test in pre-production cannot affect production and an upgrade can be proven on staging before it reaches either. Each cluster has its own control plane. Only the worker cores are counted below: OpenShift does not charge for control-plane nodes or for infrastructure nodes that carry no application workload, and BKE does not count nodes at all.
| Cluster | Workers | Cores per worker | Worker cores |
|---|---|---|---|
| Production | 4 | 32 | 128 |
| Staging | 4 | 16 | 64 |
| Pre-production and performance testing | 4 | 32 | 128 |
| Total, 3 clusters | 12 | 320 |
The four arrangements
What each costs, per year and over 3 years.
OpenShift
US $592,000
a year
320 worker cores at an assumed US $1,850 per core per year, including Red Hat's support subscription.
A · BKE
US $36,000
a year
3 clusters at US $12,000 each. Every BKE component is included.
B · BKE and the charts
US $96,000
a year
A, plus the Mamluk Enterprise Helm Charts at US $60,000 a year for the organisation, whatever the number of clusters.
C · with support
US $156,000
a year
B, plus support with a four-hour response time and consulting, at US $5,000 a month.
| Arrangement | Per year | Over 3 years | Per worker core | Less than OpenShift, per year | OpenShift costs |
|---|---|---|---|---|---|
| OpenShift | US $592,000 | US $1,776,000 | US $1,850.00 | — | — |
| A · BKE | US $36,000 | US $108,000 | US $112.50 | US $556,000 | 16.4× |
| B · BKE and the charts | US $96,000 | US $288,000 | US $300.00 | US $496,000 | 6.2× |
| C · BKE, the charts and support | US $156,000 | US $468,000 | US $487.50 | US $436,000 | 3.8× |
The OpenShift rate is an assumption: a heavily discounted figure, used here because OpenShift is negotiated per customer and no list price applies to any particular bank. Substitute the per-core rate from your own quote and multiply it by 320; the BKE figures do not depend on it. All figures exclude VAT.
Like for like
Which comparison is the fair one.
Arrangement A is not equivalent to OpenShift, and is not presented as such. It is a production-grade Kubernetes cluster with storage, ingress, certificates, logging, monitoring and a service mesh available to enable. It does not include the managed databases and caches that applications depend on, and its support is 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, production-ready, with replication, backups and upgrade paths decided — and a support contract with a four-hour response time and consulting time for the bank's own engineers. On the assumed rate, OpenShift costs 3.8 times as much as C, a difference of US $436,000 a year.
Both sides carry costs this page does not count: the hardware, the data-centre space, and the engineers who operate the estate. Those are broadly the same under either product, and are left out so that the licence cost can be read on its own. One difference does favour BKE: it runs on Debian, which carries no operating-system subscription.
Over 3 years
US $1,308,000
less than OpenShift, with the charts and four-hour support included.
- OpenShift: US $1,776,000
- BKE, charts and support: US $468,000
Growth
What the next change to the estate costs.
A per-core licence is priced on the estate as it is today. The bank's estate will not stay as it is: production will need capacity, and a disaster-recovery site is a common requirement for a regulated bank.
| Change | OpenShift, per year | BKE, per year |
|---|---|---|
| One more 32-core worker in production | US $59,200 | US $0 |
| Doubling every worker's cores in production | US $236,800 | US $0 |
| A disaster-recovery cluster the size of production | US $236,800 | US $12,000 |
The Helm Charts licence is per organisation, so a fourth cluster does not change it. Red Hat's subscription terms treat some disaster-recovery configurations differently; where the bank's quote reflects that, use its figure instead.
Scope of the platform
Enable what you need. Nothing else is installed.
OpenShift is itself run by operators. A new cluster carries roughly thirty cluster operators under the Cluster Version Operator — authentication, the console, the image registry, monitoring, the router, machine configuration, Operator Lifecycle Manager, the marketplace and others — and each one 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 owns the nodes, the router owns 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.
Each of those components is software the bank's engineers must understand, its security team must review, and its change process must carry through every upgrade. A component that is installed but not used still has a version, still receives patches and still appears in an audit.
BKE makes two decisions: the network fabric, which is Calico, and the Kubernetes version, each pinned to the exact patch. Calico installs its own upstream resource definitions; beyond those, a new BKE cluster carries the resource definitions of upstream Kubernetes and nothing else. Every further component is enabled by one line in the cluster's configuration, and is not installed until it is:
- Longhorn for replicated block storage, with backups to an object store the bank names.
- Kong for ingress and API gateway functions, with rate limiting, caching and access control as declared plugins.
- cert-manager to obtain and renew TLS certificates from the bank's own issuer.
- Kuma as a service mesh, which changes nothing until a namespace opts in.
- Fluent Bit to ship logs to the bank's existing log destination.
- Netdata for per-node monitoring at per-second resolution.
- metrics-server for resource figures and horizontal autoscaling.
A bank that already operates an enterprise load balancer, a central log platform and its own certificate authority enables none of the corresponding components, and they are not present on its clusters. The Mamluk Enterprise Helm Charts follow the same rule: 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, so leaving a component out does not change the price, and enabling one later does not require a new contract.
The exit
The bank can stop paying us and keep running.
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 determines what leaving costs.
BKE. A BKE cluster is upstream Kubernetes, installed with kubeadm, 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; the licence governs installation and upgrade only. A bank that leaves BKE keeps its clusters as they are and takes over their upgrades, using the same upstream tools BKE uses. Its workloads are standard Kubernetes manifests and need no rewriting.
The Helm Charts. The applications the charts deploy are the upstream releases — MySQL, Valkey, Memcached and the others — and the data they hold is in each application's own format. What the charts add is the operation around those applications: 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.
OpenShift. An estate that has run on OpenShift for several years has usually adopted its 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 of those must be found and replaced before the workloads will run on another distribution. That work is a real cost of leaving, and it grows with every year the estate remains.
The practical consequence is that the bank's contract with us has to be renewed on its merits each year. That is the arrangement we intend: the cost of leaving is kept low so that the decision to stay is the bank's own.
Caveats
Where OpenShift remains the better choice.
A bank with an existing Red Hat enterprise agreement, an estate standardised on Red Hat Enterprise Linux, or a mandate that one vendor own every layer including the operating system may reasonably prefer OpenShift. So may a bank that wants OpenShift's developer console and build tooling as the product. BKE deliberately leaves the operating system with the customer, and does not attempt to occupy that position.
Run the arithmetic on your own estate.
Take the per-core rate from your OpenShift quote, multiply it by your worker cores, and compare it with the flat fee per cluster. A 14-day trial licence is self-service.