Some enterprises rapidly build cloud apps to pursue DevOps initiatives, but experts think that's putting the cart...
before the horse. Instead, they say, start with enterprise architecture evaluation.
If an enterprise has a tightly coupled architecture, a fundamental component is missing for DevOps, according to Nicole Forsgren, CEO and lead scientist at DevOps Research And Assessment. Instead, enterprises need a loosely coupled architecture that enables DevOps teams to make rapid changes to meet emerging customer needs and competitive threats.
Cloud platforms are a natural fit for a loosely coupled architecture, since developers can weave together capabilities for different applications, functions, services or platforms via APIs. Here is some more advice from experts out of the recent DevOps Enterprise Summit in San Francisco about pursuing these kinds of architectures.
Avoid DevOps in a box
Many organizations think of DevOps as something they can buy in a SaaS app or in a box, Forsgren said. Get away from that line of thinking, as that's the monolithic way. The components of monolithic or tightly coupled systems and architectures are dependent upon each other. Change one, and others often change as well. On the other hand, loosely coupled systems and architectures contain components that can be changed independently.
For a team to deploy and release products or services on demand and independent of other services the product depends on, it needs strong, structured APIs and loosely coupled architectures. Organizations must be empowered to make large-scale changes to system design without impacting other systems. Cloud platforms and apps are a natural fit for this because they remove dependencies between components.
The four key categories of DevOps success include technology and automation, process, measurement and monitoring, and culture. "When we do technology alone, for tech's sake only, it is not really impactful," Forsgren said. "It is not strategic. We need technology, process and culture."
Know DevOps workflow constraints
A common mistake when trying to transform IT and embrace DevOps is to attempt to do everything at once.
"Be aware of death by initiatives," Forsgren said. "Some companies have 50."
Such project glut is a setup for failure. Instead, enterprises need to identify unique constraints in their DevOps workflow and pick a few to work on. Then, reevaluate the list of constraints and bottlenecks. Quite often, shifting one bottleneck also reduces the impact of other bottlenecks.
It's also a good practice to limit the number of metrics your organization tracks -- pick five at the most, Forsgren said. Too many metrics can diffuse attention, and picking the wrong ones can incentivize the wrong behavior.
Reduce the number of dev requirements
Another good practice is to limit the focus of ongoing projects, according to Gary Gruver, founder of Gruver Consulting. "Many businesses create too much inventory in terms of requirements," he said. "When there is a lot of inventory in the system, you are at risk of rework and expediting."
A long list of requirements can cause confusion. Developers become unclear on what the most important issues are and what to prioritize. Too many requirements can also delay the release of working software. In the worst case, the development team releases new features after the market has changed.
Experiment to find bottlenecks
Organizations that pursue DevOps initiatives must also analyze all the components of the software development lifecycle. This includes gathering requirements, coding, testing and securing approvals across the organization.
Run tests on simple apps to get a better sense of where bottlenecks are in the DevOps workflow, Gruver said. He worked with one large organization that did an experiment on pushing a simple Hello World app through the enterprise app development toolchain and approvals process. After 250 days without deployment, the organization cancelled the project. It pushed the same app out to the Amazon Web Services cloud and had it running in four hours.
Create flow across silos of automation
Robert StroudAnalyst, Forrester Research
To create a nimble cloud app development process in a loosely coupled architecture, identify the weakest link, according to Robert Stroud, analyst at Forrester Research. Many DevOps teams "have gotten really good at automating within silos," he said. "The data shows me that we are implementing DevOps pipelines or toolchains in lots of disjointed pieces, and there are lots of manual handoffs."
An organization might implement Git, Jenkins, Kubernetes and Jira. But apps get stuck in the gaps between these tools. Enterprises should standardize and automate routine processes, as well as reach a point where people never touch the actual production server. Then, they should lock the configuration and controls of this cloud infrastructure in a repository and version it just like application code.
"If you have any servers with a name on them, you have failed," Stroud said.
In addition, automate the software lifecycle all the way from the business layer to the deployment layer. Advanced organizations embrace BizDevOps. "What empowers BizDevOps is the ability for people sitting in the line of business to drive code using configuration settings," Stroud said.
This requires the development team to build components that are pre-certified for governance and security concerns. Developers also need to create a process to move these through automated testing and right into production on the cloud.
Ultimately, a strong, loosely coupled architecture opens the door to a strong digital business that can change rapidly without DevOps workflow breakdowns. "One of the things I encourage you to do is understand where you are today and where you want to get to," Stroud said.