If you’re working in technology, you’ve likely heard the term DevOps, and may even have benefited from the assistance of a DevOps team.
Even so, it’s common for many members of development teams to only have a vague idea of exactly what DevOps is, where those team members' responsibilities begin and end, and what ultimate purpose their efforts serve in-app delivery and deployment.
This is our complete guide to DevOps for anyone who wants a clearer idea of what it is, why it’s needed, and how exactly it works.
Continue reading to learn more about DevOps!
On this page:
-
DevOps Defined (Briefly)
-
Why Is DevOps Needed?
-
What Is DevOps?
-
How Does DevOps Work?
-
Popular DevOps Structures
-
DevOps Consulting Services
-
How Much Does DevOps Cost?
-
How Bitovi Can Help
DevOps Defined (Briefly)
DevOps, a blend of Development and Operations, is a software methodology that encourages Developers and Operations Engineers to collaborate on Automated Software Delivery.
When DevOps is implemented well, teams can iterate quickly to ensure new features and bug fixes are released swiftly, application and infrastructure code and runtimes are managed securely, and running systems are continually stable.
This is the short version of what DevOps is, but you’ll find the definition varies widely depending on who you ask. It can be more helpful to understand why it’s needed. The purpose of DevOps is pretty constant; the variations in definition come from differing opinions about what tasks fulfill that purpose.
Why is DevOps Needed?
DevOps is needed to facilitate ease between Development and Operations teams. Here’s what that looks like in practice.
Before DevOps
Before DevOps, teams were broken up into separate Development and Operations silos.
Developers would build applications without much consideration for where or how the application would be hosted or maintained. Developed applications would often have environment-specific configurations that led to challenges when hosting the applications in different environments. Building, testing, and publishing application artifacts would often be a manual process run by developers on their local computers.
Operators, on the other hand, would often create and manage infrastructure manually by using ClickOps, a term used to describe when an environment is created by using an admin interface in a cloud provider or data center management tool, which led to difficulty managing infrastructure as hosting needs scaled.
Worse still, the approach to resolving challenges in application delivery was rarely collaborative. Developers would often fall into the “it works on my machine” mindset, and operators would usually push back with something like, “The host is stable, so it must be the application.” As described in Google’s SRE book (Chapter 3 - Embracing Risk), a large contributor to the tension between development and operations teams is the fact that they’re driven or evaluated by different metrics. Development teams want to iterate and make changes quickly whereas operations teams want to ensure that the running systems remain stable, and a solid way to keep system stability is through minimizing changes.
Additionally, both developers' and operators' workflows were riddled with toil—manual, repetitive, automatable, tactical work with no enduring value and a level of effort that scales linearly with the size of the application. People working on teams without DevOps would often experience the toxic effects of toil: Career stagnation, low morale, confusing roles, slow progress, and attrition.
After DevOps
With DevOps, developers and operators collaborate on the problem to find the root of an issue and share the responsibility to resolve it through Infrastructure as Code (IaC), application changes, and automations. Operators provide infrastructure tools, automations, and observability tools to developers to ensure they are able to debug, fix, and deploy hosted applications quickly.
DevOps works to alleviate toil for both developers and operators, and both groups learn from each other. Developers who collaborate with operators tend to gain an understanding of infrastructure management concepts so they can build their apps to exist and scale in a dynamically changing and scalable environment. Operators who collaborate with developers can learn and subsequently apply software development patterns, processes, and techniques against the operational problem space and can provide more resilient and powerful tools to developers.
Collaboration helps bridge the gap between development teams' desire to iterate quickly and operations teams' desire to maintain stability through embracing change and promoting practices and automations that bring stability into the entire software development and deployment lifecycle.
What is DevOps?
Now that you understand why it’s needed, it’s probably easier to understand why defining it is so difficult. If you ask 10 people what DevOps is, you’ll likely get more than 10 answers.
We don’t even always agree on calling it DevOps - it’s sometimes referred to as Cloud Engineering, Automation Engineering, Pipeline Engineering, Site Reliability Engineering (SRE), Release Management, Platform Engineering, Operations, and Continuous Delivery, to name a few.
What most people agree on, however, is a summary of what needs DevOps meets. We gave you the full scope of those needs above, but we like to summarize them as:
-
Collaboration & Communication
-
The Delivery Cycle
Collaboration and Communication
Ideally, DevOps experts help development teams and operations teams work together through shared responsibility for an application’s delivery lifecycle. DevOps helps both sets of teams learn from each other to enhance the delivery cycle.
These efforts make implementations more consistent and reliable, but the feeling of ownership for members of both teams will be greater because everyone’s needs will be worked into the automated delivery cycle.
DevOps prioritizes collaboration. The implementation is important and will follow naturally, but the strongest DevOps environments foster heavy collaboration across all stakeholders of the delivery process.
Delivery Cycle
While the landscape of DevOps and available tools is vast, the “pattern” of the DevOps Delivery Cycle is fairly consistent, and it’s generally comprised of eight high-level concepts or Pillars:
|
Variations and increased complexity will inevitably exist in nearly every DevOps Delivery Cycle implementation, but keeping these eight DevOps Pillars in mind will help you reason about your automation architecture and maintain separation of concerns as complexity increases.
What are Site Reliability Engineers?
Site reliability engineers (SRE) are, in some sense, a subset of DevOps. According to harness:
DevOps Engineers are ops-focused engineers who solve development pipeline problems. Site Reliability Engineers are development-focused engineers who solve operational/scale/reliability problems.
The responsibility boundaries between SRE, DevOps, and Operations will likely vary somewhat from company to company. For our purposes, we’ll generalize and say that SRE and Operations both fit under the “Ops” part of “DevOps”.
How does DevOps Work?
DevOps works best when everyone works together through shared vision, collaboration, culture, feedback loops, technology, and automation. We’re all DevOps, after all.
Shared Big Picture Goals
One of the most valuable aspects of working together involves a shared understanding of the high-level goals of any project.
When developers and operations can see the “big picture”, it’s easier for individuals to understand what role they play in the delivery process and take ownership of activities that need to be done to achieve the project’s goals.
Solid product and project management practices will help to establish the big-picture vision and keep efforts prioritized.
Collaboration
Your team(s) will need tooling that facilitates communication and collaboration across various mediums, and the tools should provide access controls to allow as many people as possible to consume content while maintaining security. Collaboration is greatly enhanced with common tooling such as:
-
Source code repositories
-
Chat clients like Slack, Microsoft Teams, Discord, or Rocket Chat
-
Strategic meetings with agendas and outcomes
-
Ticket management with tools like Jira or GitHub Projects
-
Documentation and wikis like Confluence
Culture
Your team members should feel confident in their work and their ability to share solutions. To ensure a strong DevOps culture, you should establish:
-
Good communication between teams to understand and resolve issues that slow down the software delivery process
-
Shadow and pair programming to promote teaching, learning, and sharing
-
A practice of giving praise for good work across disciplines
-
A no-blame environment so that everyone can learn from mistakes to solidify the overall process
-
Consistent training and learning patterns across disciplines
Continuous Feedback
The value of the automated delivery cycle increases over time. That means your mechanisms for feedback, both technical and cultural, should be embedded at every stage of the process to promote continual improvements.
For example, our developers should have access to build logs at the Continuous Integration phase to enhance their services' build processes, and operators should be provided with feedback on any errors or bottlenecks the developers encounter.
Development teams should also have access to the observability layer systems to receive alerts for and review any slowdowns or errors detected with their applications to solve performance issues.
Finally, your teams should hold consistent, periodic retrospectives, both within and across disciplines, to collectively alleviate pain points and share praise.
Technology
While collaboration and communication are arguably the most important part of strong DevOps, the technology is critical, too, and it can be complex—especially at a large scale. Development and Operations teams must find a balance between:
-
Delivering software more swiftly
-
Maintaining security, quality, and stability
Tools introduced to enhance delivery speed usually increase the challenge to maintain security, quality, or stability, and the management of those tools can often be non-trivial.
Regardless of the tools or complexity of your delivery process, you should have at least 2 people, preferably more, who are familiar with and responsible for things like:
-
Automation Pipelines
-
Infrastructure-as-Code (IaC)
-
and scalable architecture.
Popular DevOps Structures
When considering the structure of your DevOps efforts, you’ll need to take into account your current technological and team capabilities as well as your future plans for application and team scale.
Some approaches are better for teams that are and will remain small-to-mid sized, while others will work better for larger teams or sets of teams. Often, your current team size will warrant one DevOps structure, but growth will eventually necessitate a different structure. You should consider your scale roadmap to determine how to transition from one DevOps structure to another.
Here are some common patterns for a DevOps structure in order of increasing complexity and maturity:
1. No DevOps or Operations Team
For smaller teams or simple projects, there is often no DevOps or operations team, and developers will need to take on responsibilities for setting up infrastructure and automations.
Not having a dedicated individual or team to take on operations responsibilities is often a necessity rather than a decision, and a lack of operations expertise will likely lead to refactoring as you scale. If your project will remain small, it might be sufficient to continue without an operations focus. If you are planning to scale, it’s probably worth thinking about dedicated operations expertise sooner rather than later.
If you’re not confident in your ability to allow for later implementation of a DevOps structure, Bitovi DevOps Consulting can help you bootstrap your DevOps culture and processes.
2. Developer Team(s) and Operations Team(s)
Distinct teams for developers and operators add a separation of concerns so that developers can focus on writing software and operators can focus on infrastructure, automations, and tooling.
With distinct developer and operations teams who share responsibility for the full software delivery process, you can really start to feel the benefits of DevOps through specialization while maintaining a collaborative culture.
3. DevOps or Automation Team
With a DevOps or Automation team, your developers focus on writing software, and your operators focus on infrastructure and Cloud Engineering. The DevOps team then brings additional value by maintaining the DevOps culture and practices by ensuring collaboration is smooth across development and operations teams as well as other teams, such as security, audit, and compliance, and provides automations and tooling for all.
4. Platform Engineering
The final structure in DevOps maturity is a DevOps and Automation Platform, or DevOps as a Service, which is also commonly referred to as Platform Engineering. With DevOps as a Service, common tools, patterns, and operations are provided to developers and operators by a central team which often has its own cost center.
Operators are often a subset of the DevOps as a Service platform, and developers opt-in to the features provided which include all aspects of the delivery lifecycle such as:
-
Central pipelines and patterns for CI
-
Common deployment pipelines
-
Infrastructure definitions
-
Observability tools and patterns
-
Security and audit standards
In contrast to a DevOps team which relies on DevOps specialists to maintain a culture of collaboration and shared tooling through direct interaction with developers and operators, DevOps as a Service provides the tooling that allows developers and operators to collaborate. The engineering effort for DevOps as a Service is abstracted from the developers and operators through tooling, though DevOps as a Service might include both developers and operators, too.
DevOps Consulting Services
Regardless of where you are on your DevOps maturity journey, you should consider leveraging the expertise of 3rd parties or vendors, like Bitovi DevOps Consulting. You can easily bring in DevOps and operations expertise to your projects to bootstrap your infrastructure, automations, DevOps culture, and maturity plan.
How much does DevOps Cost?
There are many, many technologies and concepts involved with DevOps, and due to the broad nature of the DevOps landscape and the complexities and nuances involved with every delivery ecosystem, it is difficult to provide a number, or even a range, for the cost of DevOps.
Some things you’ll need to consider when assessing the cost of DevOps are:
-
Tooling cost and implementation effort
-
Infrastructure cost and implementation
-
Management and leadership effort to establish and maintain a strong DevOps culture
-
Architecture planning
-
Availability tolerance
-
Team size and complexity
To help with understanding the wide range of DevOps costs, consider two scenarios:
If you have only a single, small website or documentation project with a maximum of a few developers, your DevOps costs will be quite low—free, even. Most source control systems have free automation pipeline runners up to a certain number of runtime minutes, and you can easily host built pages on something like GitHub Pages for free.
On the other end of the spectrum, if you have many teams with various repositories and technologies, lots of activity in pipeline runners, private networks, and custom DevOps tooling efforts, you can easily spend hundreds of thousands of dollars. This cost is usually well worth the investment, as at this scale, skipping DevOps would mean you’d be spending a lot more on things like toil, security risks, service downtime, and even employee rotation.
How Bitovi Can Help
Your road to implementing DevOps will be challenging, but it is certainly a challenge worth taking. DevOps has been called out specifically by our clients as one of the most essential investments they made in their projects—even by those clients who initially didn’t place much value on it.
Not sure where to start or how to move forward? Bitovi DevOps Consulting can help! Contact us today to book a free consultation.
Previous Post
