Giant Swarm vs OpenShift

At Giant Swarm, we’ve often been asked to compare our infrastructure with that of Red Hat OpenShift. We’d like to shed some light on this subject and give you a rundown of the differences between Giant Swarm and OpenShift.

No doubt Red Hat OpenShift is a leading container platform, or as they put it themselves “The Kubernetes platform for big ideas”. Red Hat is one of the major contributors to the open-source Kubernetes project and announced they would use Kubernetes for container orchestration with OpenShift Enterprise 3 in summer 2015. Many enterprises decided early on to use OpenShift as a platform for their containerized applications.

As OpenShift is widely used today, this raises the question of why the world needs another offering such as Giant Swarm, and how it’s different. So, let’s take a deeper look at how Giant Swarm compares to OpenShift.

At Giant Swarm we’re driven by customer obsessions. This means we’re always starting with the “WHY”. Challenging what drives our customers, their problems, and the pains they face, again and again - to understand what they really need and want.

From working with our enterprise customers, and the talks we have with many others, we’ve learned that they want to increase their business agility and developer productivity. This is to gain a competitive edge in the digital era in the first place. They want their applications to be running resiliently and to be scalable across their own data-centers and the public clouds. Additionally, most want to stay flexible and avoid lock-in in this ever-changing world. Obviously, cost savings often play a role too.

To gain business agility and increase developer productivity they want their development teams to be empowered, have the freedom to use the right tools for the job, and easily run Cloud Native projects on-demand at scale, reliably, and without having to manage the underlying infrastructure. This is so they can focus on what they do best - working on their applications.

Key motivations to become Cloud Native

These customer motivations have strong implications on our product, our architecture, and even our business model. Next, we’ll cover the key differentiators that explain how Giant Swarm is different, how we add value during our customer’s Cloud Native journeys, and why recently more and more enterprises are choosing Giant Swarm over traditional PaaS platforms like OpenShift.

1. Multitenancy: Hard Isolation vs. Soft Isolation

Giant Swarm believes that soft in-cluster separation by namespaces doesn’t provide the high level of security often required by enterprises or the freedom that development teams need to ship features quickly. We’re not alone with this opinion as Kelsey Hightower, Staff Developer Advocate at Google Cloud Platform, recommends in his Keynote at KubeCon Austin 2017 “Run Kubernetes clusters by org-chart”.

You need to put a lot of effort into securing in-cluster environments and it gets harder the larger the company and the more tenants you want to run in a cluster. This is especially true for teams that are just getting started with Kubernetes, as they’re sometimes running wild and breaking things. It’s a lot better to provide each team with a separate cluster to start with and then re-evaluate further down the line towards consolidating some workloads onto larger clusters.

At Giant Swarm we saw this early on, and decided to build an API driven platform enabling customers to easily provision and scale fully isolated Kubernetes clusters. These tenant clusters have both network and resource isolation from all other tenant clusters. In on-premises data-centers, we run the tenant clusters on top of a host cluster which also runs Giant Swarm’s control plane. In public clouds, such as AWS and Azure, the tenant clusters are managed by the same control plane, but run independently, each in their own virtual network.

The control plane consists of many micro-services and operators. These operators are custom controllers that automate managing the tenant clusters and related components. This allows our customers to have as many fully isolated Kubernetes clusters as they require, meaning they enjoy a higher security standard due to the additional isolation. But that’s not all - it empowers development teams as they can easily create their own clusters using their preferred config and tooling. They can also decide for themselves when it’s time for an upgrade - this truly allows for multi-project operations and prevents the team from becoming blockers for others when upgrading, something that we’ve seen happening often at large organizations using OpenShift.

Furthermore, Giant Swarm’s solution allows you to easily provision a new cluster with the latest Kubernetes version, test it, and then move applications. Most of Giant Swarm’s customers are using more than 10 tenant clusters within a few weeks. As well as per team clusters they separate per environment for dev, staging, pre-prod, and especially production. We even have customers that have integrated provisioning clusters into their CI/CD pipeline so their tests are executed in a fresh cluster and cleaned up afterward.

Key benefits as a result of Giant Swarm’s Architecture with Hard Isolation

2. Continuous Updates vs. 1-2 Major Upgrades per Year

Giant Swarm believes that the fast eat the slow. That’s why Giant Swarm has a CI/CD pipeline into every installation, enabling us to upgrade all the components of the whole stack of open source products anytime, and to keep our customers always on the edge of the fast-evolving Cloud Native ecosystem. This is especially important in times where most projects such as Kubernetes have a major release every quarter. Additionally, having a CI/CD pipeline allows for daily zero-touch updates to continuously improve the container platform and customer experience as well as to rollout hot-fixes immediately to prevent customers from running into more serious issues. Of course, our system asks our customers for permission and they need to actively accept major releases with the possibility of breaking changes.

With smaller continuous updates fewer changes are made at a time, so it’s easier to identify problems. The toolchain and automation becomes more robust the more frequent teams perform upgrades. As they say: “If it hurts do it more often”. Upgrades usually do hurt and people tend to refuse to do them regularly. This is getting worse with increasing complexity - at some point you will get into trouble with interlocking between components. For example, you can’t upgrade Prometheus because it requires a newer version of Kubernetes but you want to, as in the latest version of Prometheus a bug was fixed that you’re experiencing in production.

Across the hundreds of Kubernetes clusters we’re managing in production for our customers we’re experiencing more than 80% of all issues on clusters that have not been updated for 90+ days. This clearly shows that 1 or 2 major upgrades per year are simply not enough to stay secure and run reliably.

This also brings us back to point 1. We’ve encountered large enterprises that couldn’t upgrade yet from OpenShift 3.4. This means they’re still running on Kubernetes 1.4 which is a long way behind. Whereas Giant Swarm guarantees to provide the latest version of Kubernetes within 30 days of its release. At the time being, Giant Swarm customers can already use Kubernetes 1.11 which is 18 months ahead of version 1.4.

Key benefits as a result of Continuous Updates

3. Managed Solution vs. Managing a Third-Party Platform

Giant Swarm believes in the DevOps concept: “You build it, you run it“. This approach has been shown to empower companies to build better software faster, gain business agility and developer productivity as development cycles are much shorter. You might have experienced this already from building your applications the DevOps way. The same is now true for infrastructure, as infrastructure has become code.

That’s why Giant Swarm is not only providing you with a container platform but also managing it 24/7 for you. This means we’re not just selling you a product as a traditional PaaS player will do but taking full responsibility that it is up-to-date and operational at all times - and it also allows us to make our product better every day.

Today, we’re already managing hundreds of Kubernetes clusters in production for world-class companies across on-premises data-centers and public clouds. This gives us unique insights as we are running into more issues than anyone else in the marketplace. We see issues early on and at scale and can respond to them accordingly. Whenever we discover an issue in one of the many clusters of our customers we create a postmortem and fix it with code. Every release and change is tested automatically in our CI/CD pipeline and then rolled out immediately into all installations ensuring that every other customer would not run into the same issue. This creates a positive network effect for all our customers as they simply run into fewer issues as more customers are joining Giant Swarm. It makes Giant Swarm’s container platform and all the Kubernetes clusters of our customers more secure, robust and reliable.

Additionally, our approach comes with economies of scale. It’s simply more efficient to manage hundreds - if not thousands of clusters - on a platform you control and can update anytime instead of managing a third-party platform where you have little or no influence on changes.

Hiring a third-party provider to manage another company’s platform is even worse - think how long it would take if one of your factories in China were to experience a problem with a cluster from an external service provider. They would have to report this back to your HQ, who would then forward it to the provider, who may then even need to open a support ticket with the vendor. It would take ages until you get a response - and even longer until you get a solution that resolves the problem. Now imagine this with a critical problem, where you’re experiencing downtime.

To make our customers lives better and to prevent the frustration and long response-times of a long support chain we give our customers direct access to our engineers via a private Slack channel that allows us to provide an immediate qualified response. We’re basically becoming part of our customer’s internal platform team, taking full responsibility that their container platform and all their clusters are up-to-date and operational at all times. As one of our Fortune 500 customers says: “We break it. Giant Swarm fixes it”.

Key benefits as a result of a Fully Managed Solution

4. Open Source with Freedom of Choice vs. Distribution with Limitations and Lock-In

Giant Swarm believes in providing customers with freedom of choice to allow their development teams to choose the right tool for the job. Instead of having to use some pre-configured, opinionated tools provided by the traditional PaaS platforms such as OpenShift, which can limit them.

That’s why Giant Swarm provides vanilla Kubernetes anywhere. You’re not only getting a conformant Kubernetes that you can get from many vendors but the same plain vanilla Kubernetes in your on-premises data-centers and at leading cloud providers to prevent lock-in. This allows you to move your workloads easily from a Kubernetes cluster managed by Giant Swarm to another vanilla Kubernetes cluster.

Betting on plain vanilla Kubernetes and working closely with the community has allowed Giant Swarm to use alpha features early on and some large enterprises to get into production using RBAC and Pod Security Policies while they were still in alpha.

At Giant Swarm we keep our open source code in public Github repositories where it is free to use, instead of trying to lock customers into our solution. Obviously, this has some implications on our business model as we will explain to you in the next section.

Key benefits as a result of a Pure Open Source Solution

5. Managed Service Subscription vs. Licenses + Enterprise Support

Giant Swarm believes that infrastructure software is becoming open source as the Cloud Native community is building better solutions than closed source vendors could do alone. The development and improvements of all these open source components are happening so fast that providing a platform with 1 or 2 major upgrades per year is simply not enough anymore. The added value is in providing a fully managed solution, taking responsibility that your business is operational at all times.

That’s why Giant Swarms doesn’t charge a license fee plus additional enterprise support as traditional PaaS providers do. Instead, Giant Swarm charges only a usage-based subscription fee for its Fully Managed Cloud Native Platform.

When it comes to Total Cost of Ownership (TCO) Giant Swarm’s offering will always be more cost-efficient. Compare this to building and managing a container platform yourself, or paying a license fee for a traditional PaaS and managing this yourself - or even hiring an external service provider to manage it for you. This is simply because of the closed loop that Giant Swarm owns of building and managing the platform - there are economies of scale of managing hundreds - if not thousands - of Kubernetes clusters on top of it in the near future. Several of our customers have confirmed that when considering TCO, Giant Swarm’s offering has clear cost-savings advantages, in comparison to managing another vendors platform (such as OpenShift) themselves, or hiring a third-party service provider.

Key Benefits as a result of a Managed Service Model

Conclusion: Giant Swarm Adds Extra Value to Enterprises Cloud Native Success

Giant Swarm has rethought the traditional PaaS model of vendors such as Red Hat OpenShift and has come up with a solution that is in many ways fundamentally different. These differences allow Giant Swarm to add a lot of extra value, especially for enterprises key objectives:

These huge benefits have convinced world-class companies including several Fortune 500 companies to choose Giant Swarm over OpenShift - and even some to move away from OpenShift to Giant Swarm.

While Red Hat OpenShift is an established product trusted by many, with plenty of companies having close relationships with the market leader, we are convinced that if you’re optimizing for the key objectives mentioned in this article, that Giant Swarm is the better solution. We will keep working hard to support you to win in the digital era. We will let you focus on what you do best, taking complexity away from you, allowing you to break clusters and have a coffee during the day and rest well at night while we will fix it for you.

Want to learn more? Please, get in touch via our website or schedule a discovery call with me.