# What is OpenShift? OpenShift is Red Hat's enterprise Kubernetes platform. Kubernetes is inside it, and around that Red Hat has assembled the components a production platform needs and Kubernetes deliberately leaves out: developer tooling, CI/CD pipelines, service mesh, serverless, monitoring, an integrated registry, and an operator ecosystem for running software on top. The one-line version: if Kubernetes is a kernel, OpenShift is a distribution built around it, sold with a support contract. The [Kubernetes explainer](https://www.kubernetes-experten.ch/what-is-kubernetes/) sets out why that gap exists at all. ## What Red Hat actually adds Plain Kubernetes gives you a cluster and nothing else. Everything a platform needs, you select, install, integrate, secure and upgrade yourself, each piece with its own release cycle and its own compatibility matrix. OpenShift ships those choices already made and already integrated: - **Build and deploy tooling**, so source code can become a running container without assembling a pipeline first. - **An integrated registry**, monitoring stack and logging stack, rather than three separate projects to run. - **Stricter defaults.** Containers do not run as root unless you allow it. This catches people migrating from plain Kubernetes, and it catches them because their images were doing something they should not have been. - **Operators** for installing and maintaining software on the cluster in a supported way. - **A support contract**, which for many buyers is the actual product. ## The editions, which is a real decision **OpenShift Kubernetes Engine** is the leaner, open-source-focused edition: the platform and the core, without the full developer tooling layer. **OpenShift Container Platform** is the complete feature set. The distinction matters commercially, because a team that wants supported enterprise Kubernetes and already has its own CI/CD may be buying capabilities it will not use. Establishing which edition fits belongs early in the conversation, and the pricing difference is not small. ## Make or buy Strip the branding away and this is a make-or-buy decision about the same set of components. **Making it** means choosing, installing, integrating, securing and upgrading ingress, monitoring, logging, the registry, CI and the rest yourself, on top of a cluster you also run. That is months of work before anything is in production, and then it is permanent: each of those components has its own release cycle, its own compatibility matrix and its own security advisories, forever. **Buying it** means the same set arrives assembled, tested together and supported, and the ongoing integration work is someone else's. What decides it is that the two costs scale differently. Building is mostly a fixed cost in engineering time, and it does not shrink because your cluster is small. Buying is metered: OpenShift is priced per worker vCPU, so the bill grows with the cluster. The consequence is the one people get backwards. **Below the point where you are counting cores in the tens of thousands, buying is usually the cheaper answer**, because the fixed cost of building lands on a small cluster just as heavily as on a large one. The scale at which building starts to pay is large, and most organizations asking this question are nowhere near it. Above that point, the per-core meter starts to dominate and the arithmetic can reverse. So the honest test is not "are we an enterprise". It is: how many worker cores, and what would the engineering time cost to build and keep the same thing running. ## When OpenShift is the right answer - **A support contract is a requirement.** Regulated organizations frequently cannot run critical infrastructure without a vendor behind it. This is the most common honest reason, and it is sufficient on its own. - **You want the platform decisions made for you.** Assembling ingress, monitoring, logging, registry and CI on plain Kubernetes is months of work and then a permanent maintenance obligation. Buying that assembled is a legitimate trade. - **Security posture out of the box.** The stricter defaults are the sort of thing that is easy to configure on plain Kubernetes and easy to forget. - **A large organization with many teams**, where the multi-tenancy and governance features earn their place. ## When plain Kubernetes is enough **A capable platform team that has already made these choices** may find OpenShift's opinions constrain more than they help. Migrating a working platform onto it to gain features you already built is expensive. **Small deployments.** OpenShift has a resource floor. A cluster running a handful of services pays a meaningful overhead for the platform components themselves. **Cost-sensitive workloads where support is not required.** The license is the point of the product; if you would not use the support, you are paying for it anyway. If you are weighing exactly this, our [OpenShift versus Kubernetes comparison](/openshift-vs-kubernetes/) goes through it in detail, including the editions and the pricing shape. ## What running it involves Everything on the [Kubernetes](https://www.kubernetes-experten.ch/what-is-kubernetes/) list still applies. OpenShift changes who does some of it, not whether it happens. - **Upgrades are supported, and still yours to run.** Red Hat provides the path and the tooling. Someone still has to schedule it, test it and be there. - **Node and operating system lifecycle.** The nodes underneath remain infrastructure with a lifecycle. - **Capacity and quota.** The platform components consume real resources, and sizing for them is part of the design rather than an afterthought. - **The support contract is not an operations team.** It answers questions about the product. It does not watch your cluster at three in the morning. That last point is the one most often misunderstood at purchase, and it is the gap a managed service fills. ## Where VSHN fits VSHN is a Red Hat Premier CCSP partner in Switzerland and has operated OpenShift since 2016, on Cloudscale, Exoscale, private cloud and on-premises infrastructure, from CHF 44 per vCPU with up to 99.99% SLA. The first useful conversation is usually which edition fits, and whether OpenShift is the right shape at all, because for some teams the honest answer is plain Kubernetes and a smaller bill. [Get a cost comparison](#contact)