Ditch Chef, Puppet, Splunk and snyk for GitLab? That’s the pitch from your new wannabe one-stop DevOps shop

Source:- theregister.co.uk

We want GitLab monitoring to be a complete replacement for DataDog,” GitLab’s director of product, Eric Brinkman, said yesterday. And he didn’t stop there, referring to a whole swathe of “tools that GitLab can replace” at the firm’s Commit event in London.

Around 300 or so developers attended the day at an 18th-century brewery in the City to hear GitLab’s far-reaching plans for DevOps.

The table of DevOps tools the firm has targeted is listed here on the company’s site. “GitLab does not claim to contain all the functionality of the tools listed here” is the disclaimer, but even so, it is an aggressive and far-reaching strategy.

All 900 employees in 59 countries are remote working. “We will continue being a remote company. We will be the first public remote company as far as I know.”

If GitLab has its way, developers will relinquish tools like Chef, Puppet, Ansible, Jira, Collabnet, Jenkins, Spinnaker, Splunk, and even security tools like snyk, in favour of just using GitLab. “Toolchain complexity slows down delivery,” claimed a slide displayed at Commit.

This is why, when The Reg asked founder and CEO Sid Sijbrandij what he most wanted to communicate, he said: “The hardest thing to get across is that GitLab is more than just version control and CI [Continuous Integration]. What we’re doing is a DevOps platform delivered as a single application.”

That is not a great way to make friends in the industry, but it does have some appeal. The company also got a boost when Microsoft announced its acquisition of GitHub, GitLab’s most obvious rival, in June 2018. “In that press cycle we got 23 per cent share voice. The next competitor got 3 per cent,” said Sijbrandij, referring to its measurement of media attention.

While GitHub also continued to grow, there was nevertheless some migration to a company perceived as independent.

IPO ambitions

It is that independence that has motivated GitLab’s intention to become a public company by 2020. “In 2015 we participated in a program called Y Combinator. If you want to go really fast, it’s needed to raise external money. The problem is, you need to pay it back and there’s only two options: either you get acquired, or you become a public company. We have unique values, and if we get acquired those are more at risk than if we become a public company.”

Is he confident it will happen next year? “We hope it will happen. We are ahead of revenue expectations. So we have a good shot at it.”

GitLab, currently with around 900 employees in 59 countries, is based on remote working. Will that change? “We will continue being a remote company. We will be the first public remote company as far as I know.”

Sijbrandij said that remote working “is great for the team members. They have more time. There’s more flexibility. It’s also great for employers because we get to hire people all over the world. We also save in not having to shell out for office space.”

Collaboration tools in use internally include Slack, Zoom conferencing, and Google Docs, as well as homegrown tools like GitLab Issues.

Cloud forecast

There is something of a Google flavour to the company, which moved its cloud infrastructure from Azure to Google Cloud Platform, planned, said Sijbrandij, before the Microsoft GitHub announcement. “We had a partnership with Google, but also we were enamoured with the technical performance of the Google cloud.”

That said, one of the few bits of news at Commit London was integration with the AWS Elastic Kubernetes Service (EKS). “What we’re going towards is something in GitLab where you can say: ‘Just spin up a new Kubernetes cluster on AWS’.”

This integration already exists for GCP, and Sijbrandij said: “It’s our intention to bring it to Azure Kubernetes Service as well.”

GitLab can be purchased either as a cloud service, for on-premises or self-managed deployment. “The majority of our customers are self-managed,” said Sijbrandij. “It’s more than 80 per cent of our revenue.” That said, adoption of the cloud service is growing.

Sijbrandij is a fan of the progressive delivery concept, where new features are rolled out initially to a subset of users. “We think that progressive delivery is very important. We’ve got support for progressive rollouts with canaries, using Kubernetes. It reduces the impact of any errors.”

How will GitLab compete with public cloud vendors that are pushing their own DevOps tools? This is the heart of the matter. “We see that our customers want workflow portability,” said Sijbrandij, “so they’re less likely to use DevOps tools supplied by a cloud vendor. They want an independent company to provide them.”

Redmonk analyst James Governor described GitLab as “hyper-aggressive. It plans to provide literally everything you need for application development, from source code management, to CI/CD, to monitoring and observability, to security ops, to docs.”

Governor speculated that in future “it’s going to provide PaaS-like features, and look more like a set of runtimes, pushing into spaces that map to, for example, Google Cloud Run.”

That chimes with what Sijbrandij tells us. “Our customers want workflow portability, no matter what cloud that application is deployed on.”

Multi-cloud, from his perspective, is not about avoiding lock-in by making applications portable. “It is not so much that applications get moved, because that’s super costly. But you could say all new applications will be on a different cloud from now.” Workflow portability would make that a smooth transition.

Toolchain crisis slows down DevOps? The claim at the heart of GitLab’s pitch (slide from GitLab Commit London)

GitLab is disarmingly open about its plans. The roadmap is extensive and does indeed cover a wide range of DevOps and SecOps topics. If you buy into the idea of one multifaceted tool in place of many specialist tools, it looks attractive. There are challenges, though. When you compete with everyone, it is hard to find partners – and it is through successful partnerships that most companies prosper in this industry.

There is also GitHub to worry about, which may not be as extensive in terms of features, but is well-established, addressing many of the same needs, and supplemented by Microsoft and its Azure cloud services.

Sibrandij is right in saying that people come to GitLab expecting version control, but “what they saw with GitLab is this complete DevOps platform”.

Is the company correct, though, that using a diversity of DevOps tools impedes agility, and can its own tooling offer sufficient depth and quality compared to best-of-breed alternatives? Those are the questions that will determine its long-term success.