In this video, learn that existing IT culture has both internal and external problems. Meanwhile, new challenges of scale and business cadence are pressing technology departments to change.
- I'm sure it doesn't come as a big surprise that in general IT departments are not the most beloved part of the business. Businesses have been using technology to deliver services for decades now, but success and satisfaction rates with IT continue to be low. - [Narrator] And inside technology organizations, there are many warring tribes, developers, sysadmins, security professionals, network admins. - [Instructor] And don't forget the DBAs. - Now we can't forget them. All of these groups are more frequently in conflict with each than not. We'd like to poke fun at these IT stereotypes and comics like Dilbert user-friendly and XKCD or shows like "The IT Crowd." - Unfortunately, it's not all that funny when you're trying to get your job done. And it seems like no one wants you to succeed. In dev. off this is referred to as the wall of confusion. The prototypical example is a developer who's writing code and then throwing it over the wall to an operations engineer, who is supposed to deploy it and then support it. This creates a division between groups that should share a common goal. - It's often assumed that these divisions are caused by the untrue stereotype that technology professionals just have poor people skills. This overlooks the institutional causes of the wall of confusion. - That's right. The real cause is that the institution is incentivizing opposing behavior. - [Instructor] In a classic shop, the development teams are charged with developing new functionality, making changes and moving as fast as possible. - [Announcer] At the same time operations team are charged with conflicting responsibilities of maintaining stability and controlling change. - This separation of duties causes a harmful conflict of interest and diminishes feedback loops. Also incentivizing groups to only optimize their own area of concern creates a less optimal overall outcome for the entire organization. First way represent. - [Announcer] The problem is worse within operations teams. While development teams are at least usually organized by a business sector or an application, infrastructure teams are often organized by technology stack. - Yeah, this creates additional walls just within the infrastructure team. So instead of just a couple of different teams with different priorities, now you might need 1/2 dozen teams to make a change. Someone from the network team, Unix team, web team, data center team and DBA team. - I'm glad you didn't leave the DBAs off. You know, business and it alignment has been a topic of contention for the whole history of IT organizations. And technology organizations have been sabotaged from within by this internal misalignment. - Frequently, it's our own IT processes and organizations they don't keep pace. Back In 2004, I led a web operations team and we worked with another infrastructure team to get new servers. It took six weeks to get a new server, would work with that team to spec it, and then it would go through the procurement process, be ordered from the supplier, delivered, racked and jacked in the data center, get OLS loaded on it, and finally hand it over to us to use. Then one day a virtualization vendor came by. They showed how you could provision a new virtual server in 15 minutes. Great, we bought it. After that, guess how long it took our team to get new servers? - What like 15 minutes? - That would have been great but no, four weeks. The only time savings was the two weeks usually spent for the hardware order to be fulfilled from the vendor. While creating the server took 15 minutes, our own processes incurred four weeks of overhead. All the name of virtuous things, standards and tickets and documentation and the like. But it brought into sharp contrast. The fact that we were turning something that really only took 15 minutes and one person to do, into a messy situation that took four weeks and a variety of participants. - And that's just not acceptable anymore. All those IT comedies we mentioned before, they tend to sit around technologists pulling the wall over the eyes of the users and pointy haired managers because they don't understand the technology. - But IT has been around for long enough now, the most business executives are very tech savvy. And when they see something that should take 15 minutes take four weeks, they start looking for answers, answers to why their time and money are being drained away on something that's not making them more competitive in the marketplace. - And really that's a fair question. As a result, many have turned to outsourcing and Shadow IT in attempt to solve this. But a lot of times these new approaches causes many problems as they solve. - The organizations and processes we've built up around IT have become a direct impediment to business success. How can we change our culture when this model and our behavior is based on its assumptions have become so ingrained over time? This is the topic we'll explore for the rest of this chapter.
In this course, well-known DevOps practitioners Ernest Mueller and James Wickett provide an overview of the DevOps movement, focusing on the core value of CAMS (culture, automation, measurement, and sharing). They cover the various methodologies and tools an organization can adopt to transition into DevOps, looking at both agile and lean project management principles and how old-school principles like ITIL, ITSM, and SDLC fit within DevOps.
The course concludes with a discussion of the three main tenants of DevOps—infrastructure automation, continuous delivery, and reliability engineering—as well as some additional resources and a brief look into what the future holds as organizations transition from the cloud to serverless architectures.
- What is DevOps?
- Understanding DevOps core values and principles
- Choosing DevOps tools
- Creating a positive DevOps culture
- Understanding agile and lean
- Building a continuous delivery pipeline
- Building reliable systems
- Looking into the future of DevOps