Growing Kubernetes at Scale with Open Source Project Gardener
SAP sponsored this post.
Did you know that among companies contributing to Kubernetes, SAP ranked among the top 10 committers in 2019?
Although SAP may be one of the world’s largest proprietary software companies, we also have a well-established history of contributing to a diverse range of open source projects. In part, our goal has been to support the open development of enterprise-scale tools, and enable free discussion and collaboration. At SAP, we believe it is important to be involved as de facto standards are decided, to ensure the interoperability of different tools and services.
Our commitment to Kubernetes stems from pragmatism. SAP needs to deliver wherever our customers are, which means offering a multicloud strategy and a uniform deployment stack. Kubernetes fits the bill; it supports the enterprise-scale adoption of the tools and services needed by SAP’s customers as they transition to public, private and hybrid cloud environments.
What Is Gardener?
Gardener is an SAP-driven open source project that tackles real-world demands for hyperscale Kubernetes services, regardless of infrastructure. It provides a layer across any cloud provider and the means to use a range of mixed Kubernetes clusters in parallel.
The result is flexibility for cloud native developers, who can use the tools they want, within the environment they want. Gardener provides a neutral toolbox for the technology stack of today, and we designed it to be sufficiently extensible so that — with relatively low effort — it can additionally adapt for the tools and infrastructures that come next. No one can say which direction the Kubernetes ecosystem will take, but Gardener is designed to keep things open and flexible.
A key principle of Gardener is to adhere to Kubernetes concepts for all of its tasks, and to offer a common, open platform that eliminates lock-in. Many cloud services offer a Kubernetes-based platform, and many vendors also provide their own branded Kubernetes distributions. However, we found them to be highly restrictive, occasionally low in terms of technology readiness, and also limited by their business model (typically locked into a single vendor).
With Gardener, SAP customers can automate the management of thousands of heterogeneous conformant Kubernetes clusters across multiple infrastructures — for example, Alicloud, AWS, Azure, GCP, OpenStack, Packet, MetalStack, and vSphere — in a homogeneous way and at minimal cost.
Within SAP, workloads on Kubernetes range from databases (SAP HANA), big data (SAP Data Hub), IoT, AI and Machine Learning, to diverse business workloads (SAP Commerce Cloud). Recent success stories that also include Gardener on top of Kubernetes are the SAP Business Application Studio, SAP HANA Cloud and the SAP Cloud Platform Extension Factory, Kyma Runtime.
Why Have We Open-Sourced Gardener?
Within SAP, we have been running a managed service based on Gardener for some years now. We decided to open source Gardener when it became clear that it has the potential to fill a gap as companies develop their multicloud strategies. Although we do not provide Gardener as a public managed service, the public project benefits from the ongoing improvements that we make as we run our own managed Kubernetes services for our customers.
We are determined to be transparent with Gardener, by developing everything in the public space and then adopting it with minor SAP specific integrations in-house. It’s always been imperative to keep it vendor-neutral and to stick to upstream Kubernetes practices, design and processes.
Who Else is Involved in Gardener?
Much of the involvement in Gardener comes from within the SAP ecosystem. One recent example, which I described on an SAP Community blog, is the Kyma runtime. Officially known as the “SAP Cloud Platform Extension Factory, Kyma runtime”, it is a fully-managed Gardener-based runtime for another open source SAP project called Kyma.
Under the hood, Kyma runtime uses Gardener for cluster and container management, to allow it to be available across all cloud providers — although the initial offering in June 2020 is based on Microsoft Azure, with the plan to add more hyperscalers over the next couple of months.
We also get adoption from companies unrelated to SAP, with a couple of examples being PingCAP and Finanz Informatik Technologie Services GmbH.
PingCAP has chosen Gardener to deliver a managed service for its products: TiDB (a cloud native distributed SQL database with MySQL compatibility) and its sister project TiKV (a Cloud Native Interactive Landscape project).
As a recent blog post describes, PingCAP had previously used other public managed Kubernetes cluster services, but they encountered some technical issues. They considered themselves to be hostage to the cloud provider’s specific Kubernetes system upgrades, and were frustrated by limited support and a lack of control in the timescale by which issues were fixed.
Another drawback had been the extent of cloud-specific integration work needed to follow a multicloud strategy. For a managed Kubernetes service, it’s necessary to integrate the instance API. The PingCAP team was impressed by Gardener, which provides a unified abstraction API layer for all clouds and eliminates the need for cloud specific-integration work altogether. PingCAP considered the alternative — building a managed Kubernetes service for themselves — but swiftly realized that it would be a complex and expensive option. So they opted to use Gardener to build their TiDB Cloud.
Finanz Informatik Technologie Services GmbH
Finanz Informatik Technologie Services GmbH uses Gardener to offer Kubernetes as a managed service for customers in the financial industry in Germany. Their service is built on top of a “metal as a service” infrastructure, implemented from scratch with Kubernetes workloads in mind.
The team had advanced requirements when they set out to find an infrastructure platform to run their Kubernetes services. The requirements included fast provisioning, tight integration with Kubernetes and its services, a high level of separation for sensitive environments, modern network design, and the ability to deliver a cloud native experience from their own data centers.
As a member of the team explained in a recent blog post, “SAP Gardener is a cloud-agnostic Kubernetes cluster-manager that provides an API for Kubernetes installation and management. And it is implemented with an Inception design, adhering to the same Kubernetes idiomatic principles that we set as our goal. As we didn’t want to manage all our Kubernetes clusters manually, this became an important piece of our architecture.”
The Benefits of Open Source
As of today, a significant proportion of contributions to Gardener come from SAP, but popularity is growing and there is a steady flow of non-SAP contributions too. We believe we can foster trust through transparency and building an ecosystem of good neighbors.
Within SAP, Gardener is influencing and catalyzing change. We already have great inner sourcing examples, with internal stakeholders contributing directly to the open source software project and doing almost everything in the public. One such example was the new gVisor container runtime that was required by our colleagues producing the SAP Business Application Studio. The core team dealing with Gardener in SAP encouraged them to step up with this endeavor directly in the community. And it was a great experience for everyone.
What the Future Holds
Within SAP, we developed Gardener to provide our customers with a single, consistent Kubernetes feature set that abstracts resources and underlying infrastructure, and can be used by SAP solutions anywhere. We are seeing an uptake by those developing applications and deploying them across multiple clouds, and look forward to working with the community to extend Gardener and deliver hyperscale Kubernetes services for the tools and infrastructures of the future.
Visit the SAP Developer Center to find out more about Gardener and other SAP-driven open source projects.
Feature image via Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: firstname.lastname@example.org.