Speed without risk’ is how Olivier Bonsignour describes the union standardization and agility within DevOps. On the Stack, Bonsignour explains why a fast and agile approach such as DevOps reaches its full potential when enough of a framework is applied to ensure you spot security holes and non-compliant connections.
What Bonsignour refers to as standards are not necessarily industry stand commonly called DevOps best practices. On GitHubGist, James Wade offers a concise history of best practices, extending from Andrew Shafer’s Agile Infrastructure in 2008 to today’s continuous operations. Wade emphasizes that there are no DevOps job titles or specifications. He describes DevOps as “a way of thinking, a way of doing, and a way of being… attitude, ideas, customs and behaviors… [c]ulture, paradigms and philosophy.”
Establish a Culture of Principles
There is no IT playbook for exporting an attitude or philosophy to the many collaborators in an organization’s CI/CD process. DevOps is not a team or a job title. Instead, it’s a philosophy, and as such it defies attempts to boil it down to a collection of specifications. On DevOps.com, Jayne Groll posits that the focus should be on DevOps core principles rather than on best practices:
The principles are the core of DevOps practices:
Companies don’t need rigid standards to re-imagine their procedures, eliminate siloed practices, identify current and potential vulnerabilities, and automate as much as they can. Groll points out that the impetus for rethinking the way the company operates is a pervasive sense of collaboration and a spirit of sharing.
Source: Volodymyr Dmytriiev, via Hacker Noon
DevOps touches every aspect of the company’s operation: people, procedures, and infrastructure. Attempting to apply a rigid set of best practices to such a far-reaching and dynamic concept would be stifling. Better for everyone in the organization to be in a constant state of readiness to make the exact right decision at the exact right time.
Learn from those that came before
The axiom that there is nothing new under the sun has been sorely tested in recent years. Yet the roots of new innovation can generally lead to concepts that have stood the test of time. On DZone, Denisse Morelos dispels several myths that have sprouted up around DevOps. Topping Morelos’s list of DevOps misconceptions is that the best DevOps resources are whichever came out most recently.
Plenty of helpful information about DevOps is hot off the presses, but when it comes to successful DevOps tools and methods, the latest may not always be the greatest. Many companies choose to wait for the second or third round of a tech wave so they can learn from the lessons of early adopters. The idea is to benefit from the experiences of the pioneers without having to share their growing pains.
Tapping the multi-cloud management expertise of others leads many companies to try out the Morpheus cloud orchestration platform to speed up CI/CD workflows via self-service provisioning and automation of common DevOps functions. Morpheus is fully extensible and compatible with a wide range of DevOps tools and methodologies: advanced API, CLI, Chef, Puppet, Ansible, Salt, and custom scripting.
Apply agile to your org chart
Fifty years ago, Mel Conway published an article in Datamation that explained why the design of the applications produced by a company are constrained by the firm’s communications structures. In CIO Review, Nick Caldwell describes “Conway’s Law”: Software architecture will always be “a reflection of your organizational chart.”
Caldwell writes that because companies are “always shipping the org chart,” they need to reconfirm continually that their organization meets the needs of their customers. It follows that because customer needs and other market dynamics are always in flux, your organization has to be agile enough to adapt on demand. Caldwell suggests an “Inverse Conway Maneuver” that applies DevOps principles to your organization’s structure.
Under the inverted model, a company first imagines the product it wants to make, then it assembles the teams needed to build the product, and the appropriate software architecture for the product will emerge naturally. The result is the end of a “central architecture” and the rise of a “star network of services that are organic, highly optimized, and able to rapidly evolve.”
The foundation of Mel Conway’s law is that the first version of any product is rarely the best in terms of meeting the needs of its intended users. Therefore, effective application design depends on a flexible organization structure that is able to adapt quickly to ever-changing business conditions. In this sense, DevOps’ highly-networked, flexible teams become the driving force for realizing the company’s mission, vision, and goals.
