The Difference Between Stable and Stale: A Tale in DevOps Methodology

What’s the difference between stable and stale? It sounds like the intro to a good joke, but trust us, the slippery slope between the two can be no laughing matter. Read on as we explain why it’s important to strive for and embrace the role that agility, and a DevOps methodology can play in keeping your environment agile and moving forward in pursuit of continuous improvement.

If it ain’t broke…

Don’t fix it. It’s a familiar phrase to many of us and speaks soundly to our IT heritage. For years, IT labored with fragile systems comprised of beautiful snowflakes (or pets as some people call them). When working, these systems were left alone lest they caused unnecessary downtime and consumed endless resources in problem resolution. And with that, stability as an IT ideal was born.

From this heritage came the simple equation: stable = good. And, it should be said that stability as a goal is not inherently bad. Let’s face it, some stable things are really great, like a nuclear reactor or a low velocity maintenance-mode legacy application, e.g., your old expense reporting system that you do not need to evolve to make more revenue.

However, stable is one step away from stale, and that is not a goal we’d encourage for anything that does contribute to the competitive advantage of a company, e.g., your website. To  use an example, 52% of businesses still run Windows XP, despite the fact Microsoft hasn’t supported the OS since 2014. Now, in this example it’s easy to spot that the environment has become stale. And it’s pretty easy to see what issues this presents to the business. So, how do you avoid slowly slipping into this stale state?  

One Letter and a World Apart

To that question we propose something altogether different as there is a very fine line between stable and stale. While they are only one letter apart, they are worlds apart in their impact to the business. So, rather than asking how you can mitigate the risk of your stable systems becoming stale, we propose a new paradigm: strive to embrace and own change and pursue a continuous improvement process.

In today’s highly competitive business environment, it’s become increasingly important for organizations to deliver new products and/or features to market faster in a way that is highly secure and highly available. Companies with stable — yet traditional IT shops — are finding themselves floundering to compete with highly nimble competitors. Agility is no longer a luxury; it’s a business imperative.

DevOps Agility

DevOps is a framework that allows organizations to streamline processes for greater agility. When coupled with the appropriate IT infrastructure changes, DevOps can provide increased agility, greater security, higher availability and more. At Flux7, we have developed the Enterprise DevOps Framework (EDF), a model that marries DevOps process improvement with infrastructure changes that create digital transformation and greater agility.

For example, in this new DevOps-driven model:

• The service code and all its relevant dependencies are owned by the service team. This allows the service team to move faster as they have fewer dependencies. With systems that can be created with the push of a button, development can fail fast and start over again without concern about disrupting fragile artifacts.
• Traditional IT operations is converted into a concept that we call the landing zone, where services are automatically delivered and deployed. The landing zone is service-agnostic, further supporting a herd (vs. pet) methodology and decreasing the need to protect systems from change. That is, the focus moves from keeping systems stable to enabling the flow of new services while maintaining other constraints like security, governance, and uptime.
• That is not to say that systems shouldn’t be kept in a known, good state. The EDF enables compliance to regulatory and security policy through inspectors that automatically conduct security and audit checks on elements as they move through the pipeline, and in the landing zone. Together, these automated checks provide continuous auditing through security as code. Thus, continuously ensuring that systems are in a secure state.
• Last, the EDF encourages agility through the idea of injectors which ensure that things keep moving at full speed. Injectors do so by inserting environment specific information into their service templates on the fly as elements go through the pipeline, e.g., using AWS SSM Parameter Store and some scripts to inject database passwords securely in an application’s config file while it is being deployed. In the absence of such process, the options are either slow, let a human being type the information each time an app is deployed; or insecure, give all information to all developers; or put it in a code repository.  This level of automation helps organizations reach their full potential and protects against time consuming remediation of fat-finger errors.

The Benefits

According to the 2016 State of DevOps Report, DevOps organizations are able to issue 200 times more frequent deployments than their peers. And, high performing DevOps organizations not only recover 24 times faster from failures, but they also have three times lower change failure rates. So, with fewer failures and faster recoveries, these organizations are able to spend significantly more time making strategic contributions to the business.

Bringing it Home

While all that sounds great, let us give you two polar opposite examples. The first is of a company we recently spoke with who was reticent to change. They reached out to us as their competitors were more nimble and outpacing them in bringing new services to market. While they knew something had to change to become more competitive, they were reluctant to embrace DevOps process change. At Flux7, we emphasize teaching our customers ‘how to fish’ so that they can internalize DevOps best practices for increased agility. Unfortunately, this firm was fearful that a DevOps IT infrastructure would not be stable. And, once you aim for stable, you will start guarding your systems, which begins the slow trek to making them stale.

On the flip side of the coin, we worked recently with Rent-A-Center who actively embraced DevOps agility and pursued a cycle of continuous improvement. They created a team dedicated to rolling out DevOps processes and infrastructure to grow their agility and ability to more dynamically service their customers. They actively worked with the DevOps team at Flux7 to apply DevOps processes and learn how to effectively manage them moving forward. In working with Rent-A-Center on its DevOps initiative, we were able to design and build the first-ever Dockerized, AWS auto scaling SAP Hybris solution. In applying the knowledge transfer skills and best practices themselves, Rent-A-Center saw clear business results. Over nine million people visited the ecommerce site over Black Friday. This was a 42% increase in traffic that was serviced without missing a beat.

We’ve worked with over 150 organizations on their digital transformations and can say from experience that stability should not be your goal, but rather DevOps agility and a virtuous cycle of constant improvement. This approach will not only keep you from being at the end of the ‘what’s the difference between stable and stale?’ joke, but will help you gain and keep competitive advantage.