GitLab Serverless augments developers' multi-cloud toolbox

GitLab's entry into serverless computing hinges on developers' desire for a combined code repository and execution environment in a single UI.

The new serverless capability, GitLab Serverless, was created in partnership with TriggerMesh, which has developed a multi-cloud serverless management platform built on Knative and Kubernetes. It is available for early testing with the release of GitLab 11.6 on Dec. 22.

Knative is a set of middleware components to handle container traffic management and autoscale workloads, among other tasks. Originally developed by Google, it is also supported by Pivotal, IBM, Red Hat and other cloud computing vendors. With Knative, customers can run serverless workloads on multiple clouds, rather than be locked into a single vendor's offering, GitLab said in a blog post.

This messaging is not new; many other companies have previously raised the specter of "Lambda lock-in," in reference to the popular AWS serverless platform. But GitLab bets its bona fides among developers will be a differentiator.

GitLab got a boost earlier this year after Microsoft's purchase of its larger competitor GitHub, when many users -- apparently concerned over how Microsoft would handle GitHub -- moved to GitLab and crashed its servers. GitLab said it now has millions of users who work for more than 100,000 organizations. While serverless has gained prominence as a deployment model, developers tend to avoid a workflow if it lives outside their entrenched habits, the company said in its blog post.

How well GitLab and TriggerMesh's partnership works out remains to be seen. Not only is the new GitLab serverless service in its initial trial phase, TriggerMesh itself only emerged from stealth mode last month. It's also not exclusive to GitLab -- TriggerMesh's website notes that its SaaS-based platform also integrates with competing source control systems, such as GitHub and Bitbucket.

With a blank sheet of paper, a multi-cloud serverless approach would not make sense at all.

While GitLab's move into serverless is of some interest, it doesn't complete the full picture of what IT shops want in a serverless platform, said Larry Carvalho, an analyst at IDC.

"The question is, who is able to deliver the platform along with the associated services that are required?" Carvalho said.

GitLab must package its serverless capabilities with assets, such as an API gateway, databases and an event integration layer, whether they do so themselves or in conjunction with partners, he added.

And with multi-cloud serverless, there's little advantage to put on-premises compute resources in the mix, Carvalho said. "It may give you a good feeling to say, 'I'm managing it myself and avoiding vendor lock-in,' but greater complexity is the tradeoff."

Multi-cloud serverless deployments today make sense only for very large companies with a diverse array of applications and other IT assets spread across multiple locations and cloud services, he said. "With a blank sheet of paper, a multi-cloud serverless approach would not make sense at all."

Moreover, the vendor lock-in objection has receded in the case of AWS, given its recent release of Firecracker, an open source micro-virtualization platform that powers Lambda on the back end, Carvalho said.