• Aug 8, 2018
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.
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.
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.
|Efficient Multi-Project Operations - you can easily start as many fully isolated clusters as you need.|
|Empowered Development Teams - each team can get their own clusters with their preferred config and tooling.|
|Enhanced Security - due to the hard isolation of each tenant cluster.|
|Faster Update Cycles - teams can upgrade independently of each other, instead of becoming a blocker for each other.|
|Increased Flexibility - you can easily provision and test clusters with different Kubernetes versions on different infrastructures.|
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.
|Staying Always Ahead - Giant Swarm ships improvements every day and guarantees to provide updates of the many open source components within 30 days of the latest release.|
|Increased Reliability - Giant Swarm keeps your cluster always up-to-date and prevents you from running into many possible issues, suffering from bugs that have already been fixed or even worse any interlocking between components.|
|Enhanced Security - Giant Swarm fixes any security issue and rolls out the update immediately via our CI/CD pipeline into your installation.|
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”.
|Faster Development - development teams can focus on their applications instead of spending time and energy taking care of the complex underlying infrastructure.|
|Increased Reliability - Giant Swarm manages hundreds of Kubernetes clusters meaning problems are often found and fixed for another customer before they can affect your clusters.|
|Enhanced Security - Giant Swarm takes care of keeping all your tenant clusters secure and running well at all times.|
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.
|Faster Development - Giant Swarm allows your development teams to use the right tool for the job - instead of requiring to use some pre-configured opinionated tools.|
|Increased Scalability + Flexibility - Giant Swarm provides pure vanilla Kubernetes on any infrastructure and prevents lock-in as you can easily move your workloads to another infrastructure provider.|
|Staying Always Ahead - Giant Swarm always provides you with the latest Kubernetes version - supporting you to even run Kubernetes alpha features in production.|
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.
|Cost Savings - as Giant Swarm has lower total costs of ownership and passes these savings on to our customers.|
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:
|Business Agility - Giant Swarm’s customers can efficiently run multiple Cloud Native projects on-demand, at scale, reliably. Giant Swarm takes the complexity away from our customers, taking care that their Cloud Native infrastructure is up-to-date and operational at all times, as well as providing excellent hands-on support. This further accelerates our customer’s Cloud Native journey, so they can thrive in the digital era.|
|Developer Productivity - Giant Swarm provides development teams with freedom of choice instead of making them use pre-configured tools. Developers can easily get their own clusters with their preferred config and tooling, upgrade when they are ready without blocking others, and the freedom to break clusters while Giant Swarm fixes it.|
|Resiliency - Giant Swarm keeps the Cloud Native platform and all tenant clusters up-to-date and their customer's workloads operational at all times. Giant Swarm proactively prevents more than 80% of all potential issues thanks to the positive network effect of managing clusters for many enterprises and daily zero-touch updates via our CI/CD pipeline into every installation. This is just getting better the more companies join Giant Swarm.|
|Security - Giant Swarm provides a higher security standard thanks to the hard isolation of every cluster, updating all the open source components at all times, and the immediate rollouts of hot-fixes for potential security issues via the CI/CD pipeline into every installation.|
|Scalability - Giant Swarm provides and manages plain vanilla Kubernetes in your data-centers and preferred cloud providers. Customers can efficiently start and scale 100+ clusters across private and public clouds around the globe.|
|Cost Savings - Customers have stated the total cost of ownership of Giant Swarm’s solution is clearly lower than doing it yourself, managing a traditional packaged PaaS such as OpenShift, or hiring a third-party service provider.|
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.
Giant Swarm’s managed microservices infrastructure enables enterprises to run agile, resilient, distributed systems at scale, while removing the tasks related to managing the complex underlying infrastructure.
GET IN TOUCH
CERTIFIED SERVICE PROVIDER