Over the past few years, DevOps has rapidly gained in popularity. We hear news near-constantly about how organizations worldwide are being transformed with the help of DevOps, and how engineers are mastering the new profession of DevOps. But what actually is the definition of DevOps? Is it a methodology, a profession, or both at once? What’s the difference between CI and CD, or between IaaS, PaaS, and SaaS? How do DevOps and SRE relate to each other? And what other terms and concepts do you need to know to understand the language and meaning of DevOps?
A DevOps Definition and Overview
Our DevOps glossary cuts through the clutter, defining and explaining only the terms you really need to know, including:
- Defining DevOps
- CI/CD: The Backbone of DevOps
- TDD and Microservices: The Development Side of DevOps
- DevOps: Virtual Machines and Cloud Computing
- DevOps Cloud Models: IaaS, PaaS, and SaaS
- DevOps Infrastructure: Containers and Kubernetes
- Infrastructure as Code: The Confluence of “Dev” and “Ops”
In short, DevOps refers to software development practices that help shorten the development cycle while retaining enterprise-grade quality control.
As we explore below, DevOps can refer to both a methodology and a profession.
DevOps: As a Methodology
DevOps can be defined as a two-pronged methodology that includes a combination of philosophies, tools, and practices related to both software development (“Dev”) and IT operations (“Ops”). It is intended to accelerate the delivery of software products. With increased velocity, organizations are able to reduce their products’ time to market and thus better satisfy the needs of their customers. The DevOps methodology relies on a culture of collaboration between people who have historically operated in separate organizational silos — the development and operations departments. Now, all together, they are the “DevOps” team.
DevOps: As a Profession
DevOps can also be defined as a profession. A DevOps engineer is a person responsible for both the reliability of the software product (the “Ops” part) and the high pace of the product’s development (the “Dev” part). DevOps is a multidisciplinary role that includes a wide range of duties previously performed by distinct individuals: system administrators, release engineers, and software developers. DevOps engineers implement continuous integration (CI) and continuous delivery (CD) processes, automate software build and deployment routines, and manage either on-premise or cloud infrastructure.
SRE (Site Reliability Engineering)
class SRE implements DevOps
According to Ben Treynor Sloss, Google’s VP of engineering and the founder of the Site Reliability Engineering term, “SRE is what you get when you treat operations as if it’s a software problem.” SRE can be defined as a more opinionated and prescriptive way of doing DevOps — a way pioneered by Google. (For a more detailed description of the relationship between DevOps and SRE, please refer to The Site Reliability Workbook.) Thinking in terms of programming languages, an SRE is a concrete class that implements a DevOps interface. (See also this video with Seth Vargo and Liz Fong-Jones: “What’s the Difference Between DevOps and SRE?”)
CI/CD: The Backbone of DevOps
Continuous Integration (CI)
Continuous integration, or CI, is a software development practice in which developers integrate source code changes into the shared repository as early and often as possible, ideally several times a day. Each source code integration invokes an automated process of building, testing, and verification of the code change. Continuous integration allows developers to locate and eliminate software defects at an early stage of software development, thus dramatically accelerating development speed.
Continuous Delivery (CD)
Continuous delivery, or CD, is a further extension of continuous integration in which software is ready to be released to production at any time. Apart from the automated build and test steps of the continuous integration, continuous delivery also includes fully automated release deployment, thus speeding up the development process even more.
Continuous Deployment (CD)
Continuous deployment, also known as CD, is the superlative form of software development practice. It extends the principles of continuous integration and continuous delivery to the extreme. The software isn’t just ready to be released to production at any time, as in continuous delivery. It’s actually being released as soon as any change is produced by the developer, usually multiple times per day.
TDD and Microservices: The Development Side of DevOps
Test-Driven Development (TDD)
Test-driven development, or TDD, is a software development practice that requires software engineers to write automated tests before they even write the actual code that will be validated by the tests. With TDD, software engineers follow a short development cycle:
- Write an initially failing automated test case that serves as a specification
- Ensure the test fails
- Write the minimum amount of code required to pass the test
- Refactor the code
- Repeat the cycle
TDD dramatically reduces the risks of software bugs associated with each individual release, making it possible to confidently release product quickly and often.
Microservices are an architectural approach in software development. They structure complex applications as a collection of small, loosely coupled services. Unlike the more traditional monolithic architectural approach, microservices allow for the development of large, complex applications by small, autonomous teams following the two-pizza rule. Microservices and DevOps perfectly complement each other, because it is much easier to build the continuous delivery pipelines for independently developed, tested, and deployed microservices than to configure a continuous delivery pipeline for a large monolith with one stroke. Moreover, small, independent teams can deliver faster and be more Agile than their larger counterparts.
DevOps: Virtual Machines and Cloud Computing
Virtual machines are emulations of the physical computer machine. The widespread proliferation of virtual machines was preceded by a long history of research and development that began with the work on the IBM CP-40 operating system in 1964. In the 2000s, virtualization products such as VMware and VirtualBox revolutionized software development, significantly accelerating computer machines’ provisioning time and thus greatly simplifying the job of IT operations. Virtual machines reduced the typical time required to provision a computing resource from several days (the minimum required to approve a purchase and buy, mount, and configure new hardware) to several seconds.
Cloud computing is the on-demand provisioning of computing resources available to a customer as a service with a pay-as-you-go subscription. DevOps is strongly associated with cloud computing due to the flexibility, ease of use, and high scalability of cloud resources available as a service. The service model advocates for delivery of everything “as a service”: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) are the three main cloud computing service models. But there are also plenty of other cloud services, such as Backend as a Service (BaaS), Database as a Service (DaaS), Function as a Service (FaaS), and so on. In this way, you can imagine cloud computing as a successor of virtual computing.
DevOps Cloud Models: IaaS, PaaS, and SaaS
Infrastructure as a Service (IaaS)
Infrastructure as a Service, or IaaS, is the delivery of computing resources such as data storage, networks, and virtual and physical computers to end users via a service model. Examples of IaaS include Amazon EC2, Google Compute Engine, Azure Virtual Machines).
Platform as a Service (PaaS)
Platform as a Service, or PaaS, takes IaaS one step further. Instead of provisioning and managing low-level blocks of the underlying infrastructure, PaaS allows consumers to deploy and run applications on the managed platform. PaaS completely eliminates system administration tasks such as configuration management, capacity planning, software updating, and security hardening, allowing users to focus solely on software development. Examples of PaaS include AWS Lambda, Google App Engine, Azure App Service, and Google Cloud Functions, which can either be considered as examples of PaaS or of a somewhat specialized kind of PaaS, Function as a Service (FaaS). AWS Lambda and GCP Functions are also known as serverless runtimes.
Software as a Service (SaaS)
Software as a Service, or SaaS, is a method of software product delivery to end users over the internet and via pay-as-you-go pricing in which the software is centrally hosted and managed by the service provider. Unlike IaaS and PaaS, SaaS is a complete software product available to end users. Examples of SaaS include Gmail, Slack, Jira, and Salesforce.
DevOps Infrastructure: Containers and Kubernetes
A Docker container is a software package that bundles the application source code and all required software dependencies into one unit, ready to be immediately deployed in any environment. Docker technology relies on OS-level virtualization, in which containers share the same operating system kernel. Docker containers are similar to traditional virtual machines. Unlike virtual machines, containers induce much smaller performance overhead, thus offering greater efficiency.
Kubernetes (from Greek κυβερνήτης, meaning “captain” or “helmsman”) is an open-source system for automating the management of containerized applications. The Kubernetes project was announced in mid-2014 by Google’s programmers. It is heavily based on Google’s internal project, a cluster management system called Borg.
Infrastructure as Code: The Confluence of “Dev” and “Ops”
Infrastructure as Code (IaC)
Infrastructure as code, or IaC, is the infrastructure management approach in which infrastructure resources like networks and servers are provisioned and managed using machine-readable definition files. The idea of treating infrastructure as code is very close to an above-mentioned definition of SRE by Ben Treynor Sloss, in which “SRE is what you get when you treat operations as if it’s a software problem.”