What is DevOps?
The Business Value of DevOps
Who's using DevOps?
The course is part of these learning paths
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 why cultural change is a key tenant of the DevOps philosophy, and what exactly people mean when they talk about DevOps culture. The reason we're going to talk about culture first before we get into things like automation and measurement, is that DevOps goes from philosophy to buzz word without a company culture to support it.
So, what do I mean when I say culture? Generally speaking, culture are the beliefs, values, or behaviors of a group of people, and a company's culture is the same. It's the vision, values, beliefs and habits of the company. And the company culture is woven into the fabric of the company, and it doesn't change easily. So you now know what culture is, but what kind of cultural changes might be required to support DevOps?
We talked about the DevOps tenants in the previous lecture. We talked about culture, automation, and measurement. In order for a company to support the DevOps philosophy, they need to be able to support things like automation and measurement. These two tenants are essential. By not using automation where it makes sense to, you're creating a constraint on your development, deployment and operations pipeline, and you're probably making a lot more work for your engineers than you need to. And by not measuring everything, you won't have the data you need to make the right choices.
So, a DevOps culture understands the value in automation and measurement. Now, these two things are great cultural values, but they're not the only two. A common way to see software companies structured is that there are separate teams. There's often a development team, a QA team, hopefully some form of security team, and an operations team. Each one of these departments has traditionally had their own goals and incentives, and oftentimes, these goals may contradict the goals of other teams, either implicitly or explicitly. These isolated teams are what we refer to as silos.
Here's a crude example. Your development team has a goal of deploying four new features per month. However, QA has a goal to block all major and critical bugs from being released. Now, both of these sound like great goals. However, let's imagine the development team finishes their one month sprint and they've implemented five features, and then they hand off their work to the QA team. QA run through their tests and reject four of the five new features. So, QA send back the report for the developers so that they can start fixing bugs. This goes back and forth for a couple of weeks until someone makes the executive decision to send it over to the ops team for deployment. After all, sitting on new features is expensive and while developers are performing bug fixes, they're not working on new features. At this point, neither team had met their goal.
So, culture requires the removal of silos in favor of high collaboration. It's important that everyone is working towards a common set of goals. This kind of cultural change may make some engineers uncomfortable, because their roles may not be as clearly defined as they used to be. A high level of collaboration outside of the silo can take some time to get used to. The result of breaking down the silos should be a culture of shared responsibility. At a minimum, teams need to collaborate continuously.
One method that works for some companies is that of cross-functional teams, teams that are responsible for the complete life cycle of a product. These teams consist of developers, QA, security, and operations engineers. When an autonomous cross-functional team works on a single project, the result should be a product with increased stability, security, and quality.
We mentioned in a previous lecture that some companies try adopting DevOps by introducing a DevOps team, which may sound like a good idea. However, what they usually end up with is just another silo. And worse, a silo of engineers that, assuming they know what DevOps is, will spend most of their time frustrated, because the company culture prohibits them from really doing their job.
The silo model can also become a bit of a blame culture. What that means is that when bugs are found in production, people start pointing fingers and saying things like, "QA approved this." This sort of environment creates friction between teams, teams that, on the most important level, should all be working towards the same goal.
So, DevOps culture should be a blameless culture, one that understands that failure is going to happen, especially where humans are involved. This doesn't mean that people get a pass to do whatever they want. Rather, it means that everyone needs to own up to their own part and mistakes, so there's enough data to learn from it. A culture of blame reduces empathy and makes for an overall lousy work environment.
Instead of blame, focus on learning what went wrong and how to prevent a similar failure from happening in the future. Every mistake that is made can serve as one fewer potential future mistakes. DevOps culture should promote collaboration and transparency, and insist on tearing down silos. Silos prevent the type of collaboration and empathy required for working towards a common goal.
If you don't take away anything else from this lecture, remember this: cultural change may not be easy, but a company culture that doesn't support its employees to do their best work is setting them up to fail. Without a culture to support it, DevOps is just another buzz word and a lot of frustrated engineers.
So, now that we've covered what kind of cultural changes might be required and the reason that cultural change is important, we should discuss automation. Automation is another key tenant of the DevOps philosophy and it also tends to be a lot of fun. All right. Let's get started.
About the Author
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.