Ten practices for DevOps success: Five through one

- Welcome back to the top 10 DevOps practices. - [Instructor] Let's pick up with practice number five, the cloud. The DevOps love of automation and desire for infrastructure's code has met a really powerful ally in the cloud. The most compelling reason to use cloud technologies it's not cost optimization, it's the cloud solutions give you an entirely API-driven way to create and control infrastructure. - This allows you to treat your systems infrastructure exactly as if it were any other program component. As soon as you can conceive of a new deployment strategy or disaster recovery plan or the like, you can try it out without waiting on anyone. The cloud approach to infrastructure can make your other DevOps changes move along at high velocity. - All right, let's move on to practice number four, andon cords. Frequently in a DevOps environment, you're releasing quickly. Ideally you have automated testing that catches most issues but tests aren't perfect. - [Instructor] Into the andon cord. This is an innovation originally used by Toyota on its production line. A physical cord like the stop request cord on a bus that empowers anyone on the line to pull to stop ship on the production line because they saw some problem. It forms a fundamental part of their quality control system to this day. - You can have the same thing in your software delivery pipeline. That way you can halt an upgrade or deployment to stop the bug from propagating downstream. - We recently added an andon cord wire build system, after a developer released a bug to production that he knew about, but didn't have a test to catch. Now everyone can stop ship if they know something's not right. - [Instructor] All right, let's move to practice number three, dependency injection. In a modern application, connections to its external services like databases or rest services, et cetera. They're the source of most of the runtime issues. There's a software design pattern called dependency injection or are sometimes called inversion of control. This focuses on loosely coupled dependencies. - In this pattern, the application shouldn't know anything about its external dependencies. Instead they're passed into the application at runtime. This is very important for a well-behaved application in an infrastructure as code environment. Other patterns like service discovery can be used to obtain the same goal. - All right, let's move on to practice number two, blue-green deployment. Software deployment, I mean traditionally you take down the software on a server, upgrade it, bring it back up, and then you might even do this in a rolling manner, so you can maintain the system uptime. - [Instructor] One alternate deployment pattern though is called the blue green deployment. Instead of testing a release in a staging environment and then deploying it to a production environment and hoping it works, instead you have two identical systems, blue and green, one is live and the other isn't. To perform an upgrade, you upgrade the offline system, test it, and then shift production traffic over to it. If there's a problem, you shift back. This minimizes both downtime from the change itself and risk that the change won't work when it's deployed to production. - All right, let's move to our last practice, practice number one, the chaos monkey. Old-style systems development theory stressed making each component of a system as highly available as possible. This is done in order to achieve the highest possible uptime but this doesn't work. A transaction that relies on a series of five 99% available components will only be 95% available because math. Instead, you need to focus on making the overall system highly reliable even in the face of unreliable components. - Netflix is one of the leading companies in new style technology management and to ensure they were doing reliability correctly. They invented a piece of software called the chaos monkey. Chaos monkey watches the Netflix system that runs in the Amazon cloud and occasionally reaches out and trashes a server, just kills it. This forces the developers and operators creating the systems to engineer resiliency into their services instead of being lulled into making the mistake of thinking that their infrastructure is always on. - [Instructor] Well, that's our top 10 list of individual practices from across the various DevOps practice areas. I hope you find them useful and that they get an idea of the new kinds of thinking that can be applied to the issues around how to create, deploy, and maintain your applications.