Cloud Foundry CTO on the key to DevOps transformation
This is a guest post for the Computer Weekly Open Source Inside blog written by Chip Childers, CTO of the Cloud Foundry Foundation.
Cloud Foundry is an open source project with an open contribution and open governance model that claims to give users ‘maximum flexibility’ to avoid vendor lock-in.
Explaining that adopting a ‘DevOps approach to digitisation’ can be disruptive, Childers argues that more and more organisations are doing it because it’s practical and delivers measurable benefits.
Childers writes as follows…
By its nature, DevOps improves collaboration among teams (business, dev and ops) by increasing transparency and revealing working practices –- and this is essential for effective decision making.
Essentially, it applies Agile principles throughout the development cycle, leading to faster development of software, at higher quality, to ensure faster and more frequent delivery.
DevOps and Agile are both fundamentally about achieving a more responsive approach to technology changes.
Agile is about the development process of getting ideas manufactured into software, and DevOps is about being nimble with both deployment and changes to IT environments.
Specifically for software, DevOps essentially extends Agile software development methodologies into the realms of operations and infrastructure, leading to a more holistic development cycle.
Legacy lethargy
There are of course many challenges here.
In transitioning to a more modern, DevOps-driven approach, companies with a legacy infrastructure may encounter issues involving resistance to change that are both technological and cultural. There are risks in both inertia and impatience – attempting to modernise too quickly can lead to technical disruption or even outages… and can also create cultural friction within an organisation.
However, failing to modernise at a steady rate can lead to an organisation being left behind if they continue with the same outdated approach, as their competitors choose DevOps and digitise more rapidly.
Ultimately, you can’t buy DevOps.
It’s not a tool or a product, even though there are plenty of companies determined to try to sell it to you.
Adopting a DevOps approach is about a cultural shift… and it requires implementing the technologies, tools and products that are actually a fit, in the context of that culture, between new processes and existing systems. The best way to do it will be different for every organisation, and identifying the details of that approach is crucial to a successful implementation.
With automation for example, DevOps is fundamentally about the culture, process and tools working together to achieve a better ‘flow’ through the business.
Getting changes deployed quickly, with high quality and with as little effort as possible, naturally leads to automation. That said, there are risks in automating too much too quickly, or attempting to automate more nuanced tasks.
Certain tasks require more adaptable approaches or are more error-prone, so attempting to automate those can end up creating challenges rather than generating benefits.
Changing the culture
In making the move to DevOps, don’t begin with tools and technology – start with people and culture. It’s vital for a smooth transformation to get everyone talking and understanding each other.
Ensure that everyone involved really knows what the business is about and how they fit into it. Establishing shared understanding and trust among traditionally siloed roles is the hardest and most important step to take – and it may take a little time.
Once that’s underway, the approach for each organisation will be different depending on which the stage of their digitisation journey.
For example, a small start-up with brand new applications and infrastructure can be a lot more ambitious in its approach to DevOps than an enterprise with an existing, older infrastructure, which will be much more difficult to turn around.
One thing that’s important for all companies to understand about DevOps is that no matter where they fall on that spectrum, they must have a realistic approach based on their own resources, teams and technology stack.