GitLab is jumping cloud providers, announcing plans to migrate its operations from Microsoft Azure to Google Cloud Platform (GCP). The move will include transitioning all data and files into various GCP products, and it will allow for greater use of Kubernetes. This follows just a couple of weeks after Microsoft announced it was buying GitHub, a rival open source code repository.
Andrew Newdigate, GCP project manager at GitLab, said the move was tied to the company’s desire to further exploit the Kubernetes container orchestration platform. That platform initially grew out of Google’s Borg project before being donated to the open source community.
“Google invented Kubernetes, and [Google Kubernetes Engine] GKE has the most robust and mature Kubernetes support,” Newdigate wrote in a blog post. “Migrating to GCP is the next step in our plan to make GitLab.com ready for your mission-critical workloads.”
The migration process will use GitLab’s Geo product that allows for read-only mirrors of GitLab instances. This will allow for the cloning and fetching of projects hosted in GitLab and for distributed teams to collaborate more efficiently.
The migration is scheduled for July 28.
“Our absolute top priority for the failover is to ensure that we protect the integrity of our users’ data,” Newdigate noted. “We will only conduct the failover once we are completely satisfied that all serious issues have been ironed out, that there is no risk of data loss, and that our new environment on Google Cloud Platform is ready for production workloads.”
The move away from Microsoft comes on the heels of its planned $7.5 billion acquisition of fellow Git repository GitHub.
William Chia, senior product marketing manager at GitLab, said via email that Microsoft Azure had been an “exceptional cloud provider for GitLab for the better part of the past two years.”
“Our GCP migration is unrelated to the acquisition news,” Chia said. “We’ve been planning it for a while and announced the migration in April when we launched our native GKE integration.”
GitLab CEO and Co-Founder Sid Sijbrandij said that the deal did cause a bump in interest for GitLab as some in the open source community expressed concern over Microsoft’s deepening involvement. GitLab, which offers a similar platform to GitHub, said at that time that it had imported more than 100,000 repositories and seen a 7x increase in orders shortly after the Microsoft deal was announced. It was looking to capitalize on the deal by offering discounts on its top-tier plans.
“There are users that were concerned with the Microsoft deal and moved to GitLab,” Sijbrandij said. “But I think that will be temporary.”
Sijbrandij said that long term he thinks users might take a longer look at GitLab as their platform of choice because of what he said was a more comprehensive DevOps approach.
“Many were satisfied with GitHub, but see that they can do more with GitLab,” Sijbrandij said. “This will create more opportunities and open some doors for us. Anything that gets more awareness on how we are different is good.”
The migration builds on GitLab’s move in April to support automated container cluster deployments using Kubernetes. That move allows native GKE integration so users can connect their current managed Google container account into GitLab. That integration then allows for the automatic creation of Kubernetes-managed clusters that are fully managed by Google and run on Google Cloud Platform (GCP).
Sijbrandij said the integration eased what is a difficult process in terms of running Kubernetes in a production environment.
“We make it much easier to do development and ops on top of Kubernetes,” Sijbrandij explained. “Google is making sure you have a stable container-as-a-service platform. We bring along DevOps tools that work across that platform.”
Sijbrandij last week said the Kubernetes work has been smooth.
“It been everything we had hoped for,” Sijbrandij said. In fact, he noted that GitLab was working on ways to use Kuberenetes as the basis for an idling feature that would take non-running containers offline so they don’t consume compute or financial resources.