DevOps has become a crucial factor in IT’s success. It’s been a long journey but we are finally here.
Over 10 years ago, about every IT department—small or large—was chaotic and lacked a balance of collaboration, processes, automation, and monitoring on both sides of development and operations. Application development followed waterfall models, while applications tended to be monolithic and deployments were labor intensive but not frequent. What resulted was missed business opportunities and horrible experiences for engineers (i.e., developers, operations, QA, support, and security), partners, business colleagues and, sadly, end users.
The engineers, in particular, were hard-pressed to meet deadlines and, as a result, created lots of quick shortcuts. These shortcuts produced a combination of low-quality, unstable and unreliable systems with poorly documented deployment and rollback procedures. The application being created would often then be passed over to operations with the last line of the change request signed, “Good luck!”
At that point, operations would perform heroic feats to keep the application running. When operations ran out of magic tricks, the “escalation” handle would be pulled, initiating an SOS signal to all those the application touched. They would either gather in a physical conference room designated as the “war room” or jump on a conference call. Once all parties were represented, the standard finger-pointing would commence. These calls could last for hours and even days.
Sadly, 80 percent of these application outages are due to misconfigurations. The good news is these misconfigurations are avoidable through a balance of collaboration, processes, automation, and monitoring—aka DevOps.
DevOps done right
When DevOps is done right, the world gets to experience more happiness. For one, developers get to have more control and build confidence throughout the various environments from having solid automation. They also become more aware of what it takes to operationalize their software (i.e., security, patching, configuration management, performance testing, monitoring, change management, etc.). Additionally, operations gets to experience less stress and interrupted sleep (i.e., pager duty) due to higher-quality code, faster fixes, higher stability and reliability. The business as a whole gets to experience improved end-user satisfaction and less missed opportunities, all due to DevOps.
It’s also worth noting that one of the major side benefits of DevOps done right is it nicely supports Agile development efforts, which break down the project into smaller pieces (or, sprints) with the goal of being able to shorten the development feedback loop. Each of those feedback loops requires a quick, reliable and stable end-to-end deployment cycle, which methods of yesterday just cannot deliver.
Leveraging an API strategy
But DevOps by itself isn’t enough to meet the increasing demands of the business, given its ultimate focus is on artifact production and deployment. One way organizations can gain more value from DevOps is by attaching APIs to the produced artifacts, so each can be broadly consumed and reused for more leverage.
These APIs should be treated as products, in and of themselves, with the expectation that they will be reused in other projects, thereby freeing up future resources, enabling consistency and ultimately enabling innovation. In fact, according to an industry study, 94 percent of IT leaders said they can deliver products and services to market faster with APIs. In order for APIs to deliver on their promise, they have to be well thought out, well designed, discoverable and consumable by anyone or thing internally within the enterprise and externally with third parties.
If done properly, the APIs themselves will capture the enterprise’s business in a vendor-agnostic form, which in turns becomes the enterprise’s platform. A further outcome is that the APIs will form an application network. When an API is created and placed on the network, it adds value to other nodes. The underlying technology used to implement the APIs may change but the node (API) doesn’t. Therefore, the application network bends…it doesn’t break.
Practical considerations for implementing a DevOps model
DevOps can be leveraged by organizations of any size and in any industry, whether a large bank, insurtech startup or global retailer. Many companies, including Amazon, Facebook, and Netflix, do millions of deployments a year using DevOps practices—Amazon specifically has been said to do 136,000 software deployments per day. They will often include continuous deployments, which are the practice of extending the automation so that once a release candidate has been established it’s automatically deployed into production. This works for many companies and projects but not all…enter continuous delivery (CD).
CD achieves the same fundamental outcome of continuous deployment; however, it’s gated by a change management approval process. The approval process itself can be automated so that when the change management system obtains the approvals from various groups or people, the change management system can notify the CD system to proceed with the deployment to production. Otherwise, the process goes into a “no operation” state and waits for the next release candidate to process.
Rethinking IT culture
DevOps is a shift in most IT cultures and processes. Twenty plus years ago, businesses saw large amounts of money dumped into IT and realized little value. Ten to 20 years ago, the perception shifted to center around the need for IT to align with the business and focus on services they need or want.
More recently, due to the enormous acceleration of disruption combined with the realization that all companies are now software companies, the perception has shifted to encompass a collective “WE” are the business. This has forced the traditional organizations of development and operations to strengthen their collaboration, leading to the realization that they need to improve skill sets, streamline processes, enable automation, and leverage existing and new tools. Critical to the initial launch and the momentum of the effort is a close alignment with the company’s vision and priorities. Many teams slow the organization down when they get off track and fail to support the company’s overall needs to reach its vision.
It’s going to take a complete effort across people, process, and technology. It takes at least two of the three to be highly successful. Take technology as an example. We’ve all seen superior technology fail. Why? Failures in the people and processes. We’ve all seen inferior technology be highly successful. Why? Because great people and processes were compensating for its inferiority. DevOps is no different.
At the end of the day, continuous delivery and DevOps are the way to go to meet the operational demands of the software stack. If your project or organization can handle it, push it further with continuous deployments. Organize around APIs, make them awesome, make them reusable, and see your enterprise platform blossom into an application network that allows others to leverage all of the great work that you’ve put into DevOps.
This article first appeared in the SD Times.
