For the purposes of this post, Part 1 in a series of 5, let's define a couple of terms:
- DevOps – This is a software development method that is based on the idea of collaboration, cooperation, and communication between a team of software developers and other arms of an IT organization within an enterprise.
- Asymmetry – Something that is comprised of unequal parts, having no balance, and uneven in distribution.
So what is the goal of DevOps? This is a bit of many-headed hydra but for now, we are going to cull this down to the simplest concept of why we are in business: to make money.
How does DevOps help us accomplish this simple but lofty goal? It begins by getting products to market faster with fewer issues to have to fix. In order to do this, the following has to happen:
- Deployment frequency must be improved.
- There has to be a lower failure rate in new releases.
- The time between fixes has to be reduced.
- Faster mean time to recovery when things go wrong.
This seems pretty straightforward except that DevOps teams find themselves in a constant state of flux due to the environment they work in: an asymmetric environment. Ideally, DevOps teams should work in an environment with provisioned hardware that mimics the production environment. But remember why we are in business in the first place? The cost of building out an identical environment with all its hardware and real estate can be extraordinary. It’s typically viewed as cost prohibitive to most enterprises. Businesses prefer to focus on the resources required to support production, not to test those resources. This leaves DevOps teams “cobbling” environments with what they've been handed down, or what they can find to piece together, creating their asymmetric environment.
The Asymmetric environment isn't just physical either; it’s within the dev/test/QA process as well. In order to uncover all the bugs and all the defects, full data sets are necessary. Unfortunately, the asymmetric environment leaves a DevOps team to dissect data sets into fragments to run their applications through the SDLC. To state the obvious, a fragment is not the same as the whole. These “fragments” can’t be the secure, fenced networks found in the original production environment. Automatic data refreshes can’t be included either since the entire production environment hasn’t been replicated. We've seen a customer take over 45 days to refresh their dev environments with up to date production data. What is the impact on the quality of the code from not testing daily or even weekly on current data sets?
So, what was thought to have saved money by creating the asymmetric environment has now turned into compounded, time consuming and expensive problems.
The Asymmetric environment is:
- Substandard, disparate networks leaving the high probability that defects will be found during live production.
- Having a lag time between production data needed and data actually received.
- Having a SDLC that is always a few revisions behind of what should be current.
- Money lost due to lack of attention DevOps needs in order to streamline production.
DevOps should be managed as an asset for the business - not viewed as a place to reduce to scale. Emulating DevOps environments safely and efficiently is complex, but it’s vital to successful production. Maximizing efficiency, predictability, security, and the operational processes have to be maintained. What we are looking for are continuous flows, automation, and tight feedback loops. It also helps when the DevOps team is both self-reliant and self-confidant. We will discuss all of these points in next week’s blog: How to achieve Symmetry within DevOps in Part 2 of our Blog Series: Enterprise Challenges in the Test-Dev Environment.
