What is DevOps?
The Business Value of DevOps
Who's using DevOps?
The course is part of these learning pathsSee 1 more
Modern software systems are becoming increasingly complex, to meet quality, availability, and security demands. And these systems are changing rapidly to keep up with the needs of end-users. With all of the changes, how do you ensure stability, quality, security, and innovation? In this course, we look at how the DevOps philosophy can provide a holistic way to look at software development, deployment, and operations. And provide some tenets to help improve quality, and stability.
You will gain the following skills by completing this course:
- Why automation, culture, and metrics are essential to a successful DevOps project.
- How DevOps can positively impact your business's bottom line.
- Learn which major companies are successfully utilizing DevOps in their own engineering processes.
You should take this course if you are:
- A newcomer to the DevOps or cloud world.
- Looking to upgrade your skills from a conventional software development career.
This Course Includes
- Expert-guided lectures about DevOps.
- 1 hour of high-definition video.
- Solid foundational knowledge for your explorations into DevOps.
What You'll Learn
|Video Lecture||What You'll Learn|
|What Is DevOps?||In this lecture series, you'll gain a fundamental understanding of DevOps and why it matters.|
|The Business Value of DevOps||Need to justify the business case for DevOps? This is the lecture series for you.|
|Who's Using DevOps?||Find out who's using DevOps in the enterprise - and why their success matters for your own organization.|
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
Welcome back to our Introduction to DevOps course. I'm Ben Lambert, and I'll be your instructor for this lecture.
In this lecture, we're going to talk about DevOps. We're going to talk about what it is, and why you can't escape hearing about it.
If you were to ask 100 technical people what DevOps is, chances are you'll get at least 100 different answers back. So knowing that there isn't consensus on a single definition might make you a bit leery about this whole DevOps thing, and that's completely understandable. But the lack of any standard definition doesn't detract from its value. It's really quite the opposite, and that's because DevOps is a philosophy.
I know that's probably not what you were expecting to hear, but it really is the best way to categorize DevOps in my opinion. I like to describe DevOps as the philosophy of the efficient development, deployment, and operation of the highest quality software possible. Again, since there's no one entity in charge of defining and advancing DevOps, this definition just helps to explain DevOps to those who may not know anything about it, even if it isn't an official definition. Being a philosophy, it allows each company to implement it in the way that best supports them.
There's no one right way to adopt a DevOps philosophy, though there are definitely wrong ways. What we find is that some practices and strategies help support the philosophy and some don't. For instance, creating a DevOps team tends to be an example of what not to do, since it creates a new silo for engineers to become isolated in. Whereas, having cross-functional teams made of developers, QA, security, and operations engineers could be a useful strategy since it promotes collaboration.
The community around DevOps have coalesced around a set of generally agreed upon tenets that support the philosophy. Three of the most commonly accepted tenets are culture, automation, and measurement. Without any one of these, it would be difficult to adopt a DevOps philosophy. So again, our succinct definition, or our elevator pitch, is that DevOps is a philosophy of the efficient development, deployment, and operation of the highest quality software possible.
Okay. So you have a definition of DevOps. But it really doesn't tell you much about it. DevOps as a term is the combination of the words "development" and "operations." It started as a way to break down the silos that prevented engineers from achieving the levels of collaboration needed to both move quickly and remain stable. The goal of DevOps is to remove the inefficiencies that exist throughout the development, deployment, and operations pipeline, while promoting higher quality. Some of the traditional ways of developing, deploying, and operating don't hold up to the constant change that modern software systems undergo.
Modern software systems are complex, and there are a lot of interacting components. So the more change that is introduced anywhere in the system, whether it be code changes, configuration, infrastructure, whatever, the more chances there are that something will break. The goals of developers and operations are naturally at odds to some degree. It's the developer's job to implement change, and whenever a developer writes changes or removes a line of code, they introduce the potential for any number of problems, including bugs, security holes, and system outages.
The operations team is responsible for ensuring stability, so every time they're given new code to deploy into a production environment, they risk disrupting that stability. In the past, there was a perception that your development and deployment pipeline could either remain stable or move fast, and these two choices are not mutually exclusive. For example, companies like Etsy are able to deploy new code into production dozens of times every day, while keeping their site's availability high.
DevOps helps provide a better way to look at the development, deployment, and operations pipeline. It does this by promoting a culture of collaboration, and by promoting the automation of everything that it makes sense to. It also promotes the measurement of as much useful data as possible.
Users have high expectations for the software we create. They expect it to be up and running whenever they want to use it. Imagine your site went viral, and overnight you had 10 million new users. Would your site stay running with minimal or no intervention from your engineers, or would your operations team be scrambling to provision new servers?
Users also have high standards for quality. What about this? Your customers are reporting that the new features you released are causing them data loss whenever they click Save. How long would it take for your engineers to get a fix into production? Another question, how did such an obvious and testable bug make it into your production environment? Regarding new features, how long does it take you to develop and deploy them into production, days, weeks, months?
The DevOps philosophy can help with all of this, by providing the tenets needed to look at the development, deployment, and operations pipeline holistically. This new way of looking at things will help with identifying constraints on the pipeline that are hindering efficiency, and help to identify areas where quality can be improved.
DevOps is not a product, it's not a brand, it's not a job title or a team, and it really isn't any one thing. DevOps is an ever-evolving philosophy that provides some tenets, as well as some real-world community examples of how to efficiently develop, deploy, and run high-quality, modern software systems.
We're going to dive into these tenets, culture, automation, and measurement in the following lectures. But I want you to keep in mind throughout this course that DevOps is about efficiently developing, deploying, and operating high-quality modern software systems. I know. I'm starting to sound like a broken record. But the reason is important, because keeping in mind the problem that DevOps is trying to solve will help the rest of this course stick in your mind.
Okay. So you now have a high-level overview of what DevOps is and the problem it's trying to solve. Let's dig a bit further in how DevOps bridges the gap between development and operations, and how its tenets improve the overall development, deployment, and operations pipeline.
Our first tenet is going to be culture, and why the typical culture doesn't support efficiency or quality. All right. Let's get started.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.