DevOps for Beginners
Everything you need to know to get started with DevOps
March 12 . 07 mins read
What is DevOps, and why are organizations migrating to a "DevOps Operating Model"?
Let's start with two definitions, both from hyper-scale cloud vendors - Microsoft and Amazon:
![](https://www.manageengine.com/au/products/service-desk/images/blue-qt.png)
"DevOps is the union of people, process and technology to enable continuous delivery of value to customers." - Microsoft.com
"DevOps is the combination of cultural philosophies, practices, and tools that increases an organization's ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market." - Amazon.com
The definitions agree on several key factors that are important for the DevOps beginner to understand -
- DevOps is "more than just tools" - it combines people, culture, processes, practices, tools, and technology
- DevOps is customer-centric - it strives to deliver value and better serve its customers.
- DevOps is about improving time-to-market - delivering value at "high velocity" (or continuously) but, importantly, without compromising the stability, availability, or security of your applications/services.
Why is DevOps needed, anyway?
Before we dive deeper into these three areas, it's important to ask, "Why DevOps"?
What was wrong with existing ways of managing Development and Operations (the "Dev" + "Ops" of "DevOps") that spurred the need to change?
This is also an important question to ask yourself before starting your own DevOps transformation - what customer needs are you currently NOT meeting with your current delivery model, and can you measure (quantify) the gap between what you're currently providing and what your customers need? This will help you build the "business case for DevOps" to get the investment and resources you need to achieve your DevOps transformation goals.
The short answer to this question is that in many organizations, Dev and Ops were silos with different objectives, different management reporting lines, and different cultures. This meant that work - particularly new application releases - didn't flow quickly and easily from the developer's workstations via the release pipeline into production environments. Changes to systems were seen as high-risk, introducing bugs, and leading to instability and poor availability of the production systems.
This, in turn, leads to customer dissatisfaction and complaints. This resulted in Operations, which were incentivized around stability and availability, being constantly in conflict with Development, which was incentivized around getting new features into customers' hands as quickly as possible.
This conflict and misalignment intensified as many Development teams adopted Agile and Continuous Delivery software development methodologies, emphasizing smaller, more frequent releases. Operations didn't have the "cultural philosophies, practices, and tools" to meet this need, at least not without risking the stability of production systems. Hence, DevOps evolved to meet this need for BOTH Speed AND Stability.
What should be in your DevOps model?
So, given that DevOps is about "more than just tools," what are the key elements of a "DevOps Model"?
A popular framework in the DevOps community is the CALMS model, first discussed by Jez Humble in "The DevOps Handbook." Table 1 - The CALMS Model breaks down the five elements of the model.
The challenge in moving to a DevOps Operating Model, particularly for technologists within the IT Department, is that we are great at implementing automation and tools but have far less experience in things like curating a strong culture, doing Lean process analysis, or effectively measuring customer outcomes as opposed to just monitoring system metrics. This highlights the need for the DevOps Transformation people to reach beyond the IT department to help foster the change. For example, the HR department should have people with more experience in fostering cultural change. If your organization is involved in manufacturing, you might find deep Lean experience in other parts of the business. The shift to a DevOps model is not a change that can be undertaken by the IT department in isolation from the rest of the organization.
CALMS Model | |
Culture |
A "DevOps Culture" emphasizes embracing (not resisting) change, the need for collaboration within and between teams to achieve shared goals, the free flow of information, and "psychological safety" ("A belief that the [group/team] context is safe for interpersonal risk-taking - speaking up with ideas, questions, concerns, or mistakes will be welcomed and valued"). |
Automation |
Automation allows tasks to be done quickly and repeatably without human error. Automation gives us feedback about the success or failure of the tasks rapidly, which helps to support decision-making. Automation can improve speed and cost efficiency while reducing rework and errors. The DevOps approach to automation is often described as taking an "as-code" approach - infrastructure-as-code, configuration-as-code, and so forth using tools like Terraform and Puppet. |
Lean |
"Lean" is an approach to manufacturing that focuses on reducing waste and defects. Lean looks at the entire value stream, improving efficiency and effectiveness. Being busy is not the same as adding value; Lean can help identify unnecessary work that wastes resources. |
Measurement |
Measurement supports better decision-making based on empirical evidence, not opinion or "gut feel." Measuring the right things delivers fast feedback to teams and keeps them aligned to the goal of customer value. Be aware that applying targets can have unintended cultural consequences, i.e., "gaming the system." Four popular "DevOps Metrics," championed by Dr. Nicole Forsgren et al. in the book "Accelerate: The Science of Lean Software and DevOps," are Deployment Frequency (DF), Lead Time to Changes (LTTC), Mean Time To Recovery (MTTR) and Change Failure Rate (CFR). |
Sharing |
Shared goals create a common purpose, and shared experiences and lessons support organizational learning. Just having a "culture of sharing" isn't enough - mechanisms must be in place to empower sharing. This might include collaboration tools like Slack or Zoom, wikis, team activities like "blameless post-mortems" after major incidents, "lunch & learn" training sessions, or even everyday activities like daily Scrum stand-ups or "pair programming" that facilitates information and knowledge sharing between team members. |
Customer-centricity and aligning stakeholders
Next, we must look at what being "customer-centric" means as part of a DevOps Transformation.
For anyone in a leadership role, particularly in large, distributed Enterprise organizations, the complaint that "IT" isn't "aligned" to "The Business" is probably a familiar one.
Many [internal] customers or end-users in other departments feel that IT "isn't giving them what they want or need" to meet the needs of their real, external customers. IT is seen as a separate silo within the wider organization that is too slow, too inward-looking, and too focused on "doing nerdy IT stuff" than delivering customer value.
As unfair as this may seem to many inside the IT department, we only have to look at the structure of many IT departments to see the truth of this statement. Most traditional IT departments are organized around technological silos, e.g., DBAs in one team, networking and comms in another, server infrastructure in yet another, and so forth. To achieve an end-to-end customer outcome, e.g., the launch of a new product or service, requires coordination across all those different silos, which can be costly and time-consuming to achieve.
Is "product-alignment" part of the answer?
As part of their DevOps transformation, many organizations are moving to a "product-aligned" model, i.e., multi-disciplinary teams that slice across the traditional IT silos to focus on delivering a product/service that meets a particular customer need. These are also called "value-stream aligned teams" because they are aligned to a customer value stream and can deliver new products or product features "end-to-end," from the initial idea through the development phase to deployment and operations in production. These teams "own" their product, and their success metrics should align with real customer metrics like customer satisfaction, adoption, growth, etc.
Accelerating change
Finally, when we look at "time-to-market" and how DevOps can achieve "speed AND stability,"
Many traditional IT organizations, burnt by disastrous product rollouts marred by poor code quality, inadequate testing, and error-prone, manual release processes, are afraid of change. As a result, they release infrequently, sometimes even on annual or quarterly cycles. These "big bang releases" are, paradoxically, even harder to manage and coordinate, which increases risk. As discussed earlier, this also leads to intense frustration from "The Business" that IT is too slow and cumbersome. In turn, this leads the business users to try and bypass the IT department... the dreaded "shadow IT" - IT products and services not under the control of the IT department - and this can pose security and other risks to the business and its customers.
At the same time, users' appetite for new features and impatience around long-promised features yet to be released is ever-increasing. Organizations that can quickly meet or anticipate customer needs, with little or no disruption to existing services, at a lower cost, and with higher quality, can win market share from those that can't. DevOps research has shown that organizations that embrace DevOps, particularly those that excel in the four DevOps metrics discussed earlier, can exceed their goals in customer growth, market share, and profitability.
By fostering a culture that embraces change and leverages technical practices like automation to improve quality, reduce human error, and provide fast feedback if things go wrong, DevOps empowers organizations to release smaller changes far more frequently, with less risk. Many organizations are releasing hundreds, if not thousands, of changes to production every day, with a very low change failure rate and rapid lead-time-to-change. This delights internal and external customers alike, improves customer satisfaction, and starts a "virtuous cycle" of improved performance at every step of the value stream.
Good luck on your DevOps journey!