DevOps can be seen as a culture, movement, practice, methodology, set of tools, etc. But at its core, it’s a better way to build and deploy software.
Software and the Internet have transformed the world’s industries across the board.
The result? Software no longer merely supports a business, it’s become an integral component.
Just as physical goods companies transformed the way they design, build, and deliver products through industrial automation throughout the 19th and 20th centuries, companies in the 21st century must transform the way the build and deliver software.
One such transformation taking the software world by storm is DevOps.
But even as DevOps continues to achieve mass adoption across the software development landscape, confusion remains as to what exactly DevOps “is” (in part due to its history as a grassroots idea).
Is it a movement, a philosophy, a culture, a practice, a methodology, or something in between? Does the meaning of DevOps change according to your role in an organization?
However you define DevOps, reaping the benefits of this new approach to the SDLC requires a transformation and realignment of existing cultures, roles, and processes. And to help you along that journey, we’ve created this post to help introduce you to some of the fundamentals.
At its core, DevOps is a culture, movement, and philosophy.
The word itself was coined in 2009 by Patrick Debois through his DevOps Days events, the goal of which was to bring together “development” and “operations” practitioners who wanted to solve the clear challenges they faced in the traditional siloing of their departments.
Today, DevOps has grown far beyond those initial (and ongoing) events, inspiring companies worldwide to create multidisciplinary teams that work together through shared, efficient processes and tools.
But DevOps is more than a set of processes and tools.
It’s a shift in mindset, a culture, a movement that organizations and practitioners adopt to guide them towards better software.
DevOps practices, guided by the core culture and philosophy, automate processes between software development and IT administration teams to build, test, and release software faster and more reliably, as well as increase collaboration, communication, and trust within an organization.
We have a lot more to say about DevOps, but find this definition of DevOps from Gartner a great starting place:
“DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”
Even before the initial DevOps days events, the DevOps movement began to take shape around 2007 when IT operations and software development communities began to speak about what they felt were fatal levels of dysfunction in their industry.
Developers and IT Ops professionals had separate, conflicting objectives and key performance indicators and siloed teams and leadership that resulted in long hours, faulty releases, and unhappy customers.
So they began to rally against the traditional software development model that isolated those who write code from those who deploy and support it.
In search of a better way, people like Patrick Dubois, Gene Kim, and John Willis began driving the conversation towards merging these two disciplines for everyone’s benefit.
But despite these grassroots origins, DevOps found precursors in two much more traditional IT disciplines:
These precursors are especially important for enterprises, in which committing to the transformation of culture and process requires a high level of diligence.
Rather than being a flash in the pan trend with a few “IT Geeks,” DevOps unites established IT operations disciplines with proven development methodologies so development and operations become a unified entity with common goals – high-quality software, high-speed releases, and high customer satisfaction.
Developers and IT admins often don’t see eye to eye. But both tend to agree that business leadership often pulls them in competing directions.
To remain competitive and growing, business users demand new features, services, and revenue streams as fast as possible.
At the same time, they want stable systems, free from outages and interruptions.
This creates friction points where technology teams have to choose between delivering rapid changes then deal with unstable production environments, or maintain a stable but stale product environment.
Of course, neither is acceptable to executives, and neither allows businesses to provide the best solutions.
DevOps was created to resolve this dilemma by integrating all teams associated with software development and deployment, from business users to developers, test engineers, system administrators, and security engineers into a consolidated, automated workflow.
Their shared focus: rapid delivery of high-quality software while maintaining system integrity and stability.
This is enabled by a common set of DevOps principles adopted across traditional discipline boundaries and roles.
Examples of these principles include:
According to Puppet’s 2016 State of DevOps Report, high performing, DevOps focused IT organizations:
Stats like that are impressive enough to catch attention, but meaningful change requires deep understanding – so let’s take a further look at some key benefits of DevOps.
In the modern IT environment, speed is everything and teams that employ DevOps best practices release higher quality, stable software more frequently.
In non-DevOps organizations, lack of automated test and review cycles slow the release cycle with manual testing, poor incident response times, and because of these, a lack of team confidence. At the same time, disparate, incompatible tools and processes increase operational expenses and lead to context switching that kills momentum and velocity.
Through the classic business strategies of standardization and automation, DevOps’ Continuous Integration (CI), Continuous Delivery (CD), and Microservices practices enable teams to be more productive, release more frequently with fewer errors, thus allowing increased innovation at lower costs.
By comparison, high-performance DevOps teams deploy on demand, multiple times per day while low performance siloed teams deploy at best once per month – if not twice a year.
Rapid delivery rates are a hindrance if not paired with the reliability in production that end users expect. If critical issues aren’t prevented or, at least, resolved quickly, key issues slip through the cracks – increasing tension among teams and tanking customer satisfaction.
The DevOps practices of CI and CD incorporate testing throughout the SDLC to ensure each change is functional and safe, while full-stack monitoring and logging ensure full transparency and detailed feedback loops that accelerate time to resolution for any production errors that do arise.
All without sacrificing a third critical component to successful software – security.
Using automated compliance policies, proper configuration management, and fine-grained controls, high performing DevOps teams spend 50% less time remediating security issues.
Unplanned work is a reality every IT team faces, one that can have a huge impact on team productivity if not properly managed. Prioritizing unplanned work because of urgency and transitioning to that work across teams and systems is inherently inefficient.
DevOps teams establish efficient processes and clear prioritization while increasing visibility and engaging in proactive retrospection to better anticipate and share unplanned work – allowing them to minimize the interruptions that prevent them from working on new, planned work.
Through reductions in rework and unplanned work, as well as automation and consistency, DevOps enables organizations to manage complex, ever-changing systems to efficitently operate and manage infrastructure at scale.
Cultural change is the primary success factor in DevOps adoption – effectively deploying DevOps requires building a culture of shared responsibility, transparency, and fast, high fidelity feedback.
Teams that work in silos lose the benefits that DevOps’ “systems thinking” – the awareness of how one team’s actions affect the other teams involved in the release process – bring. Lack of inter-team visibility and shared goals leads to a lack of dependency planning, conflicting priorities, and a finger pointing “not our problem” mentality that slows velocity and generates substandard quality.
DevOps is a change in mindset that looks at the development process holistically, where developers and IT operations teams closely collaborate, share responsibilities, and combine workflows to reduce inefficiencies, save time, and create a workplace filled with satisfied, loyal employees.
A fundamental component of the DevOps model is that development and operations teams are no longer siloed.
Sometimes these two teams are merged, with engineers working across the application lifecycle from development to testing, deployment, and operations.
These DevOps teams automate slow manual processes and use technology stacks that help them operate and evolve software quickly and reliably.
Like all cultures, DevOps has many variations on its main themes. However, most observers and practitioners agree the following are common to most all DevOps practices.
In a DevOps culture, development and IT operations work together instead of at odds. However, DevOps extends beyond the IT organization as well into other business stakeholders including product management and executives, as these groups are integral to the leadership and management that leads to successful software.
DevOps heavily emphasizes automation through a mix of tools. Tools built internally, tools purchased externally, tools adapted from open source projects.
But while many DevOps tools are incredibly helpful in and of themselves, it’s important to avoid the tendency to simply collect a scattered set of tools and call your organization “DevOps.” These tools must be integrated into toolchains that effectively automate large parts of your particular end-to-end software development and deployment processes.
Because DevOps emerged from Agile culture, you’ll usually find Continuous Integration (CI) is a key component of DevOps cultures.
According to Aaron Cois, CI is a technique designed to continually merge “source code updates from all developers on a team into a shared mainline. This continual merging prevents a developer’s local copy of a software project from drifting too far afield as new code is added by others, avoiding catastrophic merge conflicts.”
The Continuous Integration principle forces developers to integrate their work frequently (at least daily) in order to expose integration issues and conflicts as early as possible.
However, to achieve the benefits in reduced rework and bug fixing time and costs, it’s essential that teams rely on DevOps’ collaboration principle to ensure effective communication.
The DevOps team at Amazon Web Services defines Continuous Delivery (CD) as a “software development practice where code changes are automatically built, tested, and prepared for a release to production.”
CD expands on Continuous Integration by deploying any code changes to either a testing or production environment after each build stage so that developers are always working towards deployment-ready artifacts that have passed through standardized quality control processes.
Release frequencies in a Continuous Delivery model can vary greatly depending on a company’s legacy and goals, with high performing DevOps organizations deploying multiple times per day.
The exact definition of a “release” varies as well, with some organizations sending code to QA first, where changes either go to users, go back to development, or are not released at all.
Other companies push changes directly from developers out to users and rely on their real-time monitoring and rapid remediation processes to minimize the impact of failures while reducing the risk of significant failures by keeping their update sizes small.
While Continuous Integration and Continuous Delivery get most of the attention in DevOps discussions, testing is a critical component of a successful DevOps practice. In a modern fast release environment, the operational cost and user experience impact of software failures can quickly spiral out of control.
In a DevOps culture, Continuous Testing (CT) isn’t just a Quality Assurance function; gone are the days when developers could simply throw their code over the wall and expect QA to deal with any problems on their own.
With DevOps, quality is everyone’s job, with developers building quality into their code and providing test data, while QA engineers configure automation test cases and the testing environments.
On the operations side, system admins ensure monitoring tools are in place and test environments are properly configured, and may even participate in a few types of software testing – providing feedback and analysis based on test results and experience running production applications.
CT is critical to a DevOps environment as it helps organizations balance quality and speed. Thorough testing ensures quality while automated tools and the practice of testing earlier in the SDLC reduces the time needed and cost of testing.
Even in a well-automated QA environment, the high release velocity in a high-performance DevOps company often demands offloading some of the rigor of pre-release testing onto operations.
To maintain speed and quality, failures must be found and fixed in real time. That’s where continuous monitoring comes in.
With continuous monitoring, DevOps teams improve a production system’s stability by measuring the performance and availability of software in real time. This helps identify the root causes of breakages quickly, as well as proactive prevention of outages to minimize problems in end-user experience.
Two key types of monitoring are employed in DevOps: server monitoring and application performance monitoring.
Like testing, monitoring actually starts in development in a DevOps environment – the same tools that monitor production systems are employed during development to identify performance problems before deployment.
Microservices Architecture is a design approach where a single application is built as a set of smaller sub-services.
Each service runs its own internal processes and communicates with other services via a well-defined, lightweight interface – typically an HTTP-based Application Programming Interface (API), and each microservice is scoped around a single business capability.
Infrastructure as Code is a DevOps practice in which infrastructure is both provisioned and managed using code and development techniques like version control and continuous integration. Cloud-based infrastructure is almost always integral to this process.
Cloud’s API-driven model enables both developers and system administrators to programmatically interact with infrastructure at scale, replacing the need to manually set up and configure resources.
Because infrastructure and servers are defined by code in this model, resources can be quickly deployed and released using standardized patterns and updated with the latest releases in real time.
What began in online forums and local meetups has now become a major trend in the software world. A decade into this DevOps experiment, the data is clear: DevOps is here to stay.
Core to this is that DevOps has succeeded in integrating business users, developers, test and security engineers, and system administrators into a single workflow that consistently and efficiently meets customer requirements.
And it’s seen wide adoption because there’s something in it for all stakeholders.
Developers and sysadmins have stopped battling and started supporting each other.
Business managers get high-quality software products and services that sell.
Executives see customer satisfaction and revenue steadily rising as their IT organizations align to deliver the best customer experiences possible.
Results like these, however, don’t come easily. Transitioning to DevOps requires a fundamental change in company culture and employee mindset.
Taking the first steps into a DevOps transformation rely on a thorough examination of your current culture and practices to identify barriers to cross-team coordination and take the necessary steps to bridge the gap between development and operations teams.
DevOps is about removing the barriers between the traditionally siloed development and operations arms of a software organization. In DevOps, they work together to optimize the productivity of developers and the reliability of operations.
Together, both strive to communicate frequently and take full ownership of their services beyond stated roles and titles.
While culture is key to DevOps transformation, identifying the right tools based on the needs of your process is also important. Source control, continuous integration, automation, deployment, testing, infrastructure, and monitoring must all be considered when building the right DevOps toolchain for your company.
Achieving such deep, widespread change is a challenge, DevOps transformations don’t happen overnight and executives need to be convinced. That’s the bad news.
The good news is you don’t have to change overnight or wait for upper management to sign off on an organization-wide initiative. By working to help your teams and leaders understand the value of DevOps while making small, incremental changes, you can begin to reap the benefits of a DevOps culture right away.
And you don’t have to do that alone.
ATC specializes in DevOps consulting to help teams and companies like yours manage the cutural and process transformations involved. We can help you:
If you’re ready to begin your DevOps journey, reach out today to discover how to DevOps can improve software quality and release speed for your business.
In today's challenging job market, marked by layoffs, budget cuts, and recession fears, workers under…
The introduction of the Hybrid Cloud in 2011 revolutionized global businesses that solely depended on…
SaaS companies typically operate on a subscription model, which makes their sales cycle more intricate…
For years, companies across industries have been adopting Agile approaches for greater adaptability and speed.…
The race to become future-ready is critical as organizations stand to gain 1.7x higher efficiency…
Having a worldwide adoption of 87 percent, Scrum has unlocked a powerful way for companies…
This website uses cookies.