Originally published at www.stackery.io.
It’s been nearly a decade since Andrew Shafer and Patrick Debois introduced the term “DevOps” in their talk on “Agile Infrastructure” at the 2008 Agile conference in Toronto. In the ensuing years, DevOps has become nearly synonymous with agile development, deployment automation, and continuous delivery. DevOps has slowly but surely become the norm on software teams at companies of all industries and organizations from startups to enterprises.
As this practice has been implemented, though, the practicioners have tended toward two patterns which deviate from the goal of unifying software development and software operations. These two patterns can broadly be described as DevOps-as-a-Role and DevOps-as-a-Service
DevOps-as-a-Role
In the DevOps-as-a-Role implementation pattern, DevOps is seen as a job function for certain teams or certain team members to fulfill. You’ll recognize this pattern by job titles like “DevOps Engineer” or “Site Reliability Engineer,” or by teams designed around offering developers a “Platform” to build against.
Although the job titles may have changed, the Devops-as-a-Role pattern fails to integrate ownership of the development and the operation of an application to a single team. One team continues to own the software development function, while another team is responsible for software delivery. These two teams may be more closely alligned on release cycles and cadence, but some of the core benefits of DevOps are lost.
DevOps-as-a-Service
Alternatively, teams that implement the DevOps-as-a-Service pattern tend to view DevOps as a set of tools. In this approach, software solutions for CI/CD, performance monitoring, logging, alerting, and deployment automation are all collectively part of “DevOps.” Rather than approach DevOps as a job to do, they see DevOps as a process to automate.
While this approach may, in theory, align more closely with the goal of merging Development and Operations, in practice it tends to relegate Operations to the role of troubleshooting failures, rather than integrating operational expertise into the planning and development cycle.
Serverless as DevOps
Serverless application development offers some unique characteristics that allow it to fulfill many of the stated goals of DevOps.
At a conceptual level, serverless application code and compute infrastructure become interchangeable — as you change your code, you’re fundamentally changing the underlying architecture of your application. This means that many operational concerns (latency, resiliancy, etc) need to be addressed in the development cycle, which is a great starting point for integrating development and operations from the outset.
Further, since FaaS infrastructure is ephemeral, developers are obligated to handle instrumentation for error monitoring, performance metrics, and logging to collect data at run-time in advance of any specific troubleshooting needs. Again, this forces a tight integration of development and operations.
Finally, because serverless applications tend to involve deploying dozens (or even hundreds) of individual functions, deployment pipeline automation becomes more critical than ever before.
It may be a bit premature to say that serverless will bring about the realization of DevOps, but then again, that might just be what’s happening.
