In an era of agile development and shortened release cycles, many engineering teams have standardized on continuous integration and continuous delivery (CI/CD) pipelines to accelerate their DevOps workflows. Serverless computing fits neatly into this model — both are fundamentally event-driven — but bridging the two requires understanding where the tools align and where the gaps remain.
What Is a CI/CD Pipeline and Why Does It Matter?
Before adopting serverless for DevOps, it helps to be precise about what a CI/CD pipeline actually does.
- Continuous Integration (CI) covers the build and automated testing phases of the development cycle. Developers commit code to a shared repository, and the pipeline automatically builds and tests that code to catch integration errors early.
- Continuous Delivery (CD) extends CI by automating deployment tests and configuration steps, ensuring that every validated change is always in a deployable state.
A typical DevOps toolchain progresses through four broad stages: build automation, continuous integration, application deployment and configuration management, and infrastructure deployment. Each stage is triggered by the successful completion of the previous one, which means the pipeline is inherently an event-driven system — the same model that underlies serverless computing.
Standardizing these stages reduces the time between a code change and a deployed update, improves repeatability, and removes manual handoffs that introduce risk.
Why Serverless and DevOps Are a Conceptual Match
Serverless functions execute code in response to specific events — an HTTP request, a message on a queue, a change to a storage object, or a webhook from a source control system. This maps directly onto how a CI/CD pipeline works: a developer pushes a commit, which triggers a build, which on success triggers a test run, and so on.
Despite this conceptual alignment, there has historically been a gap between serverless and the established CI/CD tooling. Tools such as Jenkins and Travis CI predate serverless computing, and because the overhead of running a Jenkins server is relatively modest, there has been limited motivation to rebuild those tools from the ground up with a serverless-first design.
How the Serverless DevOps Ecosystem Is Evolving
That gap is beginning to close. Several notable projects and products are pushing serverless thinking into the CI/CD space.
Serverless Jenkins X
One of the more prominent examples is Serverless Jenkins, an offshoot of the Jenkins X project that runs on Kubernetes. Proposed by engineers at CloudBees, the goal of Serverless Jenkins is to ensure that Jenkins only processes pipelines when a build is actually needed, rather than running a persistent server around the clock — directly reducing cloud infrastructure costs.
Internally, the approach relies on a combination of tools including Prow, an event-driven CI/CD system built by the Kubernetes development team. Prow was originally created to address the challenge of scaling Jenkins to handle the large volume of GitHub repositories and CI/CD jobs that the Kubernetes project itself required. It automates GitHub actions — issue labelling, PR merging, test triggering — in response to events, fitting naturally into a serverless design.
The Serverless Framework
For teams building serverless applications (as opposed to serverless pipelines), the Serverless Framework simplifies and automates the packaging, deployment, and lifecycle management of serverless functions across multiple cloud providers. It is one of the most widely adopted open source tools in this space.
Cloud-Native Serverless Services for Every Pipeline Stage
For most teams, the path to a serverless DevOps workflow runs through the major cloud providers. AWS, Google Cloud, and Microsoft Azure each offer portfolios of on-demand, event-driven services that cover every stage of the CI/CD pipeline without requiring teams to provision or manage servers.
AWS
- AWS Lambda — serverless function execution triggered by events from dozens of AWS services.
- AWS CodePipeline — fully managed CI/CD orchestration service.
- AWS CodeBuild — on-demand build service; you pay only for the build minutes consumed.
- AWS CodeDeploy — automated deployment to compute services including Lambda, EC2, and ECS.
Microsoft Azure
- Azure Functions — event-driven serverless compute with broad trigger and binding support.
- Azure Logic Apps — low-code workflow automation that integrates with hundreds of connectors.
- Azure DevOps Pipelines — hosted CI/CD service with agents that scale on demand.
Google Cloud
- Google Cloud Functions — lightweight, event-driven functions triggered by Cloud events or HTTP.
- Cloud Build — serverless CI/CD platform that executes builds in managed containers.
Open Source Serverless Platforms
Open source serverless runtimes — including Apache OpenWhisk, Fission, and Fn Project — exist for teams that want to run serverless infrastructure on-premises or avoid cloud vendor lock-in. However, as of the time of writing these platforms had not reached the same level of maturity, ecosystem integration, or community adoption as their managed cloud equivalents.
Practical Tips: Building a Serverless DevOps Workflow
Shifting your pipeline to a serverless model does not have to happen all at once. Consider the following approach:
1. Audit Your Existing Pipeline First
Map your current CI/CD stages and identify which steps involve persistent infrastructure (long-running build servers, always-on test environments) versus steps that are already event-triggered and short-lived. The latter are natural serverless candidates.
2. Adopt Cloud Services Incrementally
You do not need to replace your entire toolchain on day one. Use managed cloud CI/CD services to fill specific gaps — for example, replacing a self-hosted build agent with AWS CodeBuild or Google Cloud Build — before committing to a full migration.
3. Investigate Jenkins X If You Already Use Jenkins and Kubernetes
Organizations that have invested in Jenkins and have containerized workloads running on Kubernetes should evaluate Serverless Jenkins X and Prow before committing to a full replacement. This path allows a gradual migration while reusing existing pipeline logic.
4. Consider CI/CD-as-a-Service for Greenfield Teams
Teams that are just starting to formalize their DevOps processes may find it faster to adopt a fully managed CI/CD-as-a-service product rather than assembling individual cloud services. Products such as CloudBees Codeship, CloudBees Rollout, and Harness provide opinionated, end-to-end pipelines without requiring teams to wire up individual cloud primitives.
5. Review Available Integrations
Cloud providers invest heavily in pre-built integrations between their serverless services and popular DevOps tools. Before writing custom glue code, review the integration marketplace for your cloud provider and check whether your existing source control, artifact registry, and monitoring tools already have native connectors.
Key Benefits of a Serverless DevOps Approach
- Cost efficiency — Pay only for the compute consumed during active pipeline runs, rather than maintaining always-on build infrastructure.
- Automatic scaling — Serverless platforms scale function invocations in response to demand, so a spike in commits does not queue behind a fixed pool of build agents.
- Reduced operational overhead — No servers to patch, resize, or monitor for the CI/CD infrastructure itself.
- Event-driven consistency — Aligning your pipeline with the same event-driven model used by your application functions reduces conceptual context-switching for developers.
Summary
Serverless computing and CI/CD pipelines share the same foundational model: code executes in response to events, not because a server is sitting idle waiting for work. The major cloud providers have built serverless-native services that can cover every stage of a DevOps pipeline, and projects like Jenkins X and Prow are bringing the same thinking to teams that prefer open source tooling on Kubernetes. The most pragmatic path forward is incremental adoption — identify the stages in your current pipeline where serverless provides the clearest benefit, migrate those first, and build from there.
Original source: searchitoperations.techtarget.com (2019)