Building a system to be resilient is the highest leverage step in ensuring high uptime and low MTTR.
- All right. When you start talking about operations people immediately envision the activities that happen in production. But most of your success in production is based on decisions you make way at the front of the pipeline. In this section, we'll talk about how you design your application to make it work great even in adverse conditions. First we'll address the software architecture side. Software engineering has developed a bunch of design patterns over time, like those in the popular gang of four design patterns book. The equivalent design patterns book that addresses stability is Michael Nygard, Release It. This goes way beyond three tier architecture and load balancers and the other useful tricks of previous web infrastructure. It takes an application first approach to understanding the causes of failures, the patterns they take and techniques to make applications resistant to those kinds of failures. For example, the book talks about integration points being the number one cause of issues in an architecture. And what's known as a cascading failure based on an issue with an integration point is the number one threat to stability in a layered architecture. For example, if a database layer goes down or become slow in application server tier fronting it can exhaust database connection pools and choke out the app server layer too. In modern architectures especially in microservice architectures apps end up having so many integration points that the likelihood of one of them going bad is very high. An example of a stability pattern that can prevent cascading outages is called the circuit breaker which watches for failures when calling an integration point and if it detects an unusual amount of failures it stops making those calls. Instead of continuing to bombard a failing system combined with timeouts this technique can prevent spread of an outage. Once patterns like this are identified you can make platform level fixes for them. For example, one of Netflix's best open source projects in my opinion is a library called Hystrix. Hystrix is used to wrap a call to an integration point and it automatically provides circuit breaker functionality to that call. A good manifesto for how to produce service ready software is called the 12 factor app, described @twelvefactor.net. For example the third factor config states that runtime configuration that various by deployment should be separated out from the app code stored in environment variables and be fully independent of each other and not grouped into environment groupings. This avoids fragility and improves portability. The site is definitely worth studying and there's a helpful get hub project called factorish that can help make a legacy app more 12 factor. A good way to get a bite-sized introduction to architectural terms is by following Martin Fowler, @martinfowler.com. He's a noted software developer who succinctly describes everything from page objects to server list of bimodal IT. His definitions are very clearly written and could sometimes be opinionated though in fairness his opinions are generally right. That may seem like a lot of theory to start out with but that's what design is thoughtful planning of how your application and the systems around it work. And as I sometimes say, Dev comes from school Ops comes from the street. Developers tend to come from comp side backgrounds but a lot of system administrators are self-taught. And so brushing up on theory is very important. Next let's talk about bringing some of that hard one systems experience to the table.
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