The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Thanks for visiting this category page on Serverless in GitLab.
This vision is a work in progress and everyone can contribute. Sharing your feedback directly on issues and our public epic at GitLab.com is the best way to contribute to our vision.
If you’re a GitLab user and have direct knowledge of your need for serverless, we’d especially love to hear from you.
Serverless computing is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Currently, serverless computing doesn't yet have standardization, this means that developers have to choose between functionality, capability, and the overall ecosystem between cloud vendors. With Kubernetes, increasingly, also adopted increasingly as the de facto platform for many cloud native practitioners, operators have the challenge of making serverless play well with clusters, in a multi-cloud environment.
The mission of the GitLab Serverless category is to make GitLab the preferred tool for developers and operators taking advantage of serverless computing, making integrated continuous delivery and monitoring easy - no matter if those serverless applications are run inside a Kubernetes cluster or with a public serverless services provider.
Our initial hypothesis was that leveraging Knative and Kubernetes (See Knative epic and associated UX Research), users will be able to define and manage functions in GitLab. This includes managing the security, logging, scaling, and costs of their serverless implementation for a particular project/group.
While there are many options for serverless on the market, we envision several use cases that where using GitLab Serverless would be advantageous.
GitLab as a platform can enable your ops team to provide a Functions-as-a-service (FaaS) to your dev teams. In many orgs an ops team owns the Kubernetes clusters and provides deployment environments as a server to dev teams. With GitLab Serverless these ops teams can offer the ability to deploy functions as well as containers. Here the Ops FaaS serves in a similar way to Lamba, Azure Functions, etc. The developer simply writes the function and the Ops FaaS takes care of deployment, scaling, and operations. The main advantage here is that developers can keep the same dev flow for functions as they do for all their other code, while it's easy for ops teams as well as they can focus their efforts to managing the cluster, not the deployment of serverless functions.
GitLab Serverless can make it easy to deploy a bot that triages GitLab Issues. This is a natural use case for folks that already use GitLab for issue tracking and SCM and want to explore Kubernetes they can begin by using GitLab Serverless. This would eliminate the need to learn how to set up and manage a bot on cloud provider FaaS.
While Knative is the most popular installable serverless platforms in use, Serverless is still largely about hosted services that is dominated by AWS Lambda. As a result, we don't have any plans around improving the cluster based GitLab Serverless offering.
Looking forward, we would like to strengthen our integration with existing hosted serverless provider offerings, especially around deploying and monitoring serverless deployments.
To get a great overview of the serverless world, we recommend having a look at the CNCF Serverless Landscape. We are working hard to be great partners with the most widely used tools and fulfill the gap in every other area.
Users should be able to easily spin a new Kubernetes cluster under various providers using GitLab to start using the GitLab serverless offering.
AWS Lambda is a serverless compute service created by Amazon in 2015. It runs a function triggered by an event and manages the compute resources automatically so you don’t have to worry about what is happening under the hood.
Azure Functions is Microsoft’s response to Amazon’s Lambda. It offers a very similar product for the same cost. It uses Azure Web Jobs; the delay between hot cold invocations is less visible.
It’s a fully managed Node.js environment that will run your code handling scaling, security, and performance. It’s event-driven and will trigger a function returning an event, very much in the same way AWS Lambda works. It’s intended to be used for small units of code that are placed under heavy load.
The Serverless Framework is an open-source tool for managing and deploying serverless functions. It supports multiple programming languages and cloud providers. Its two main components are
Serverless Framework applications are written as YAML files (known as serverless.yml) which describe the functions, triggers, permissions, resources, and various plugins of the serverless application.
The Serverless category is currently coupled with IaaS reports.
Gartner's Magic Quadrant for Cloud Infrastructure as a Service places AWS, Azure, and Google Cloud as leaders.
Forrester places Serverless Computing in their Emerging Technology Spotlight category, with the big three as leaders (AWS, Azure, Google Cloud)
n.a.
Automatic domain for a serverless function SSL for Knative services
We collect GitLab related issues under our dogfooding epic.