GitLab has supported vanilla Kubernetes for years, but the Red Hat integration enables it to run on OpenShift, to provide additional value for both customers and partners.
Operator robot
DevOps platform provider GitLab has announced the general availability of GitLab Operator, Gitlab’s version of the Red Hat Operator tool. It provides the ability to run production instances of GitLab on Red Hat OpenShift, and improves its ability to run on Kubernetes platforms. It will also deepen the collaboration between Red Hat and GitLab, and expand opportunities for channel partners who work with both vendors.
GitLab Operator was released into beta earlier this year as part of the GitLab 13.11 release.
“GitLab Operator allows someone to deploy and run GitLab in any Kubernetes based environment,” said Joshua Lambert, Director of Product Management – Enablement, at GitLab. “What’s new here is that before this, we did not have support for OpenShift to meet the needs of the OpenShift platform. Now GitLab Operator allows support for OpenShift for the GitLab server and an improved way to deploy Gitlab on all Kubernetes platforms.”
“We are very much invested in supporting the growth of Kubernetes as the new lingua franca of the industry,” said Nima Badiev, VP Alliances at GitLabs, whose responsibilities include the strategic platform providers like Red Hat. “There are competing packaging formats – Helm and Operator, with Operator being tied to the Red Hat architecture.”
CoreOS, an independent company acquired by Red Hat in 2018 and Red Hat originally developed the Operator framework, which has been adopted by Red Hat as its de factor deployment framework. Previous to this, however, GitLabs used the Helm tool.
“Helm lets you change a configuration setting if it changes,” Lambert said. “Operator runs in the background and takes action automatically. If it sees any drift from the original configuration, it changes back. This is part of our Operator as well. GitLab Operator improves security, and can also co-ordinate the zero downtime upgrade process, during which users can continue to use Gitlab. Those are the two new improvements that it brings. It is also a prerequisite in order to support OpenShift.”
GitLab Operator and the extension of the Red Hat partnership continues GitLab’s strategy of deepening their integrations with all of the major Kubernetes players.
“Red Hat is not our first partnership,” Badiev said. “We have been working with all the large Kubernetes vendors out there, with VMware around Tanzu, with SUSE around Rancher and HPE around Ezmeral and GreenLake. They all use Helm and Operator in some combination. We work with all of them and have completed integrations with Google, Amazon and IBM. Red Hat was the next natural evolution of our overall strategy, as we are definitely going to invest a lot in our Kubernetes strategy. Red Hat is also a very good partner for us, given our alliance with IBM.”
Badiev said that GitLab’s ability to support all aspects of the DevOps process with their platform simplifies customers’ lives, and makes them an attractive integration partner for these platform vendors.
“There’s a big patchwork of legacy DevOps tools that customers have, and it’s extremely expensive to maintain all those integration points going forward,” he said. “They don’t have to spend all that money on plumbing when they use us, and they don’t have to contact switch between different components. That’s the primary thread with a lot of our alliance partnerships.
“A lot of our customers are also digital natives, and that’s driving changes a lot of companies are not ready for,” Badiev added. “They have to update their DevOps flows and culture, and assess whether they need to modernize apps into their next generation platform. This can mean migrating to Google Cloud or Microsoft. Sometimes it’s a ‘lift and shift’, but sometimes it involves rearchitecting legacy applications. DevOps modernization thread adds a layer of security. Application modernization, or migration, brings demand for us to modernize in place, and we provide these services in partnerships with strategic partners.”
Badiev said this expanded partnership with Red Hat is good news for the partners of both companies.
“Our partners are also Red Hat partners,” he noted. “The customer relies on the partner to be a trusted advisor around digital transformation. By making sure we can deploy on OpenShift, the customer is no longer burdened to have to do this manually. This makes it easier for the channel. They can now build solutions based on GitLab and Red Hat working together. Since they don’t have to stitch things together, this makes them more competitive. It makes it easier for them to do business with Red Hat and GitLab together – and makes them more likely to recommend GitLab on a Red Hat engagement and vice versa, because they know the tools work well together.”
