In our industry, many buzzwords cover insane promises and fantasy. “Serverless” is such a buzzword that's highly misunderstood. In this blog post, I’ll try to offer a reasonable definition and explain why we use the “serverless Jenkins” name in Jenkins X.
If you want to have an established definition, you better ask the expert group. The Cloud Native Computing Foundation hosts a Serverless working group, which published a whitepaper to offer both a definition and concrete usage scenarios. In their own words,
Serverless computing refers to the concept of building and running applications that do not require server management.
--- CNCF Serverless working group
Platforms as a Service was designed to run and scale applications, providing the required runtime and auto-scaling. Some do include building application from source code (git push deployment style: Heroku), some do offer binary package deployment, letting you implement your favorite build and continuous delivery workflow (Google App Engine).
“Container as a Service” has been a popular term for microservice deployment, driven by Docker and Kubernetes expansion, whenever those are not much more than a high density PaaS. In both cases, the general idea is that the Platform API hides all infrastructure details, and developers don’t have to worry about server and backend management. From a developer perspective, they eliminate the overhead involved in the maintenance of server resources.
The CNCF Serverless working group’s whitepaper has a strong focus on “Function as a Service”, as fine-grained development and deployment model for developers. They don't have to worry or even know about the underlying infrastructure to build, run and scale their code.
Function-as-a-Service Serverless platforms go one step further splitting the monoliths by letting developer deploy functions, i.e. single event endpoints, either connected by HTTP routing or event bus. The development model here is for a developer to not worry about the http stack being required to host and run the function, but to actually only implement an event handler.
But that’s not the sole difference. As a standard by the CNCF working group, another major aspect of a serverless platform is “No Compute Cost When Idle. ”
While auto-scaling on a PaaS allows it to allocate more resources on high load, there’s still a minimum of 1 active instance, running 24x7 whenever no actual traffic is providing business value to compensate for costs. A serverless platform is expected to only generate compute cost when a function is actually running. Implementations may differ in the way they handle “scaling to 0” without degrading function execution performance. Especially, consider the cost of a cold-start per request: you don’t want to bootstrap a whole JVM for each and every of your HTTP API invocations! Keep this in mind while you compare providers :)
Let’s now have a look a Jenkins X
(Never heard about Jenkins X, really? Watch this introduction )
The “static” deployment of Jenkins X let you define development Teams, and each of them get a managed Jenkins controller to handle builds and environments (see my article on GitOps ). Jenkins X in this context uses Kubernetes as a CaaS to run Jenkins controllers per team. As a result, you get a permanent load on your cluster just to support those controllers running, in addition to some Jenkins-specific pitfalls (disk usage, GitHub API rate limit scanning for branches, etc.).
But you also have an option to deploy Jenkins X as serverless Jenkins. “Serverless, ” really? Yet another marketing guru surfing the buzzwords wave?
In this specific flavor, Jenkins controller job management is fully replaced by Prow , a component created and intensively used by Kubernetes community to manage Kubernetes contributions. Prow is an event based job orchestrator, reacting to GitHub events. It can trigger some actions on push, pull-requests, comments, labels, etc. This allows to create a whole code review and validation workflow based only on events, created by Git(Hub) actions. Prow is a low overhead service installed once and will serve all hosted Teams on your Jenkins X cluster.
In Jenkins X serverless , the CI/CD equivalent for serverless “functions” are the Jenkinsfile hosted in Git repositories you want to execute to react to Git events. Let’s say you created a pull-request for awesome feature you just designed. This generates an event (GitHub pull-request created) Prow will trap, and according to configuration (set automatically by Jenkins X) will trigger a Jenkins Pipeline Build. This is a full replacement for the build queue managed by classic Jenkins controllers, fully event-driven and relying on Kubernetes to offer scalable build capabilities.
The actual Pipeline execution take place within a temporary Jenkins controller, customized to trigger a build immediately after boot based on a local Jenkinsfile, and shut down after completion. Read more on Jenkinsfile Runner here .
A major benefit of this approach, is that your CI/CD service will easily scale with development activity of your teams. You don’t consume unnecessary resources hosting Jenkins controllers for inactive teams, getting more resources available for your Builds and services.
►► “No Compute Cost When Idle ” - checked
Also, Jenkinsfile Runner being only running for a duration of a build, you don’t have to manage Jenkins controllers anymore, with plugin upgrades, security fixes, disk cleanup and all that sort of fun.
►► “Do not require server management ” - checked
The serverless definition by the CNCF Working Group focuses on application hosting, but I think Jenkins X serverless is a perfect demonstration of the same principle that can apply to CI/CD.
Additional resources
Dive into more about Jenkins X
Learn how to install Jenkins X
Listen to the podcast from the brains behind Jenkins X