Serverless: Buzzword or Reality?

Serverless: Buzzword or Reality?

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 an application from source code (git push deployment style: Heroku), and 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 were 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 24×7 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. 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 of Jenkins X? Watch this introduction.)

The “static” deployment of Jenkins X let you define development teams, and each of them gets a managed Jenkins master to handle builds and environments (see my article on GitOps). Jenkins X in this context uses Kubernetes as a CaaS to run Jenkins masters per team. As a result, you get a permanent load on your cluster just to support those masters 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. 

In this specific flavor of the tool, Jenkin’s master 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 and pull requests, comments, labels, etc. This it to create a whole code review and validation workflow based only on events, created by Git(Hub) actions. Prow is a low overhead service that is 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 an awesome feature you just designed. This generates an event (GitHub pull-request created) Prow will trap, and according to a 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 masters, fully event-driven and relying on Kubernetes to offer scalable build capabilities.

The actual pipeline execution takes place within a temporary Jenkins master, 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 the development activity of your teams. You don’t consume unnecessary resources hosting Jenkins masters for inactive teams, getting more resources available for your Builds and services.

“No compute cost when idle”? Check.

Also, Jenkinsfile Runner being only running for a duration of a build, you don’t have to manage Jenkins masters anymore, with plugin upgrades, security fixes, disk cleanup and all that sort of fun.

“Does not require server management”? Check.

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.

from DZone Cloud Zone

Sharing is caring!

Comments are closed.