Application programming interfaces (APIs), microservices, web services, and objects have all been "invented" to eliminate complexity, unreadability, tremendous testing requirements, and massive release risk associated with applications containing thousands, hundreds of thousands, or more lines of code. Even "package" applications can require multiple objects (packages) to be modified for a single functional change. Each touch point increases risk.
Dissecting large code segments into services, for example, decreases the time needed to find the code to be modified, which reduces testing time. With DevOps, the duration is decreased further by using automated testing and minimizes the potential release impact on the production environment.
Compiling, packaging, and deploying large applications at once into production are some of the major reasons for disgruntlement between development and operations. The release causes huge problems for the business and customers, with operations under the gun to find and rectify the failure — often with no development assistance. That division ends with DevOps.
Now that development and operations work together during the coding, testing, release, and production support phases, true partnerships develop that provide significant business value and team harmony.
Services mimic real-life situations, increasing focus. Here's a bank analogy: when you step up to the teller to make a deposit, you expect a quick and problem-free transaction to occur. Really, you care about little else. The teller does not need to know how you got the money, where you came from, or how you got to the bank (whether you drove or had someone drive you). This information doesn't matter for the transaction to be completed.
For you, knowing how the bank checks to make sure you are a customer with an active account, how the money flows from the teller to the safe, how the transaction is audited internally, or which bank industry best practice for deposit transactions are being applied means little. You simply want to hand the teller your cash and/or checks and a deposit slip, and receive a receipt verifying the deposit into your account. Managing code as services or APIs, for example, supports real-life conditions by reducing code to the smallest number of lines or functions needed to carry out its purpose.
Code that expects and accepts only a few "requests," which then performs one or two discrete actions and finally returns the "response," makes it possible to accept the "fail fast, fail forward" model.
Being able to deploy distinct code elements quickly, matched with the ability to deploy the next release version or the previous version, facilitates moving forward, even on failure. The small program unit minimizes the production impact upon failure — maybe only a few people experience the problem instead of a large set of application users when large code deployments go wrong.
Instead of backing out a massive change because it would take too long to find the root cause for the failure, the small footprint can be overlaid quickly, rectifying the problem while potentially advancing the code. This model makes sense, although years of "backing out" have incorrectly indoctrinated our perception. Think about it; have you even fallen backward when you trip while walking or running? No, most likely you recover without falling, or momentum keeps you moving forward even if you do fall.
DevOps leverages momentum to maintain forward progression. Remember, though, failing forward cuts across the grain for DBAs who are used to protecting operational stability at all costs, making not rolling back failures a seemingly unnatural act. Experiencing only frequent successful fail forwards brings DBAs fully onboard.
This blog is an excerpt from Mike Cuppet's book: DevOps, DBAs, and DBaaS
Read Fail Forward, Fail Fast - Part 2
