If you read IT blogs regularly, you would assume DevOps is already the status quo, that everyone has ‘crossed the chasm’, and are practicing continuous delivery on a daily basis. We read about all these amazing companies releasing hundreds of times a day using a mature DevOps model and release automation. Well, the reality is these exceptional companies are just that – the exceptions. Most companies are just setting out on their DevOps journey, and analysts predict they must catch up soon or succumb to digital Darwinism.
We see the business world being redefined by digital transformation via DevOps, so what is stopping you from following suit? As Tom Goodwin, an executive at the French media group Havas, pointed out, the world’s largest taxi company owns no taxis, the largest accommodations provider owns no real estate, the most popular media owner creates no content, and the largest movie house owns no cinemas.
Thus far DevOps has definitely had more of a development bias than an operations one
With this evidence it’s surprising that some companies are still scared to cross the chasm themselves. Having spent all their lives within the comfort of their established practices, they are hesitant to leave that safety. Even though they see other companies spreading their wings and reaching new heights, the unknown is always a scary prospect. This applies to cloud adoption for critical processes as well as DevOps.
An EMA survey from October last year found that just 25% of companies have a team known as DevOps, and this is an increase of just 5% compared to 2014. The study found that 97% had cross-functional teams compared to 60% in 2014. So in truth, DevOps is only just becoming accepted and established. However, these stats show that DevOps has finally crossed the chasm from hype to widespread adoption, and as with any leap of faith, it will take a while to settle and produce results.
There is no doubt that DevOps is needed to achieve a successful continuous delivery pipeline for bimodal IT: it is just a matter of time before it is adopted everywhere. The only problem is making the time for a transformation. With a constant backlog of work, changing an entire ethos can be challenging, but worthwhile. This excerpt from the 2015 State of DevOps Report says it all: “High-performing IT organizations deploy 30x more frequently with 200x shorter lead times; they have 60x fewer failures and recover 168x faster.”
Innovation is king
Thus far DevOps, has definitely had more of a development bias than an operations one. It makes sense because a key point of avoiding or causing disruption in the digital business era is innovation, and innovation implies creation which is what developers do – create apps.
Ops teams tend to avoid using open source in the production environment – less than 10% of customers surveyed said they would consider it
At the DOES Summit I attended in November, there seemed to be a 70-80% dev presence. This reflects the level of innovation expected from agile coding practices these days, but we must also not sacrifice reliability, auditability and control. The unbalanced scenario of ‘Big DEV, little ops’ can introduce unnecessary and costly risk. Perhaps agile practices suit a dev mindset more, but ops needs to be on board just as much.
As we have seen, bugs that are not caught in testing can cost companies millions when rolled out into production. A disaster such as those affecting the likes of the Wall Street Journal, United Airlines or Starbucks can cost the company more in terms of reputation and share price than successful DevOps can help them.
Perhaps this is a fear for companies hesitant to leave reliable waterfall methodologies behind – they see DevOps adoption as accelerating risk or exacerbating existing challenges. In this respect there is much that the more conservative Europeans can take from their bolder US counterparts. However, DevOps is now mature enough for people to have learned from mistakes, and there are ways of rolling out DevOps across the enterprise in a controlled, incremental manner.
An automation platform from an experienced, established vendor can be used as a safety rope for the big leap. A repeatable, predictable Continuous Deployment pipeline can be built to amalgamate the best bits of SMEs’ knowledge from across IT departments or disciplines. This is then streamlined and tweaked over time with any superfluous manual tasks added to an automated pipeline, allowing SMEs to focus on deeper, more proactive work which leads to greater innovation and lower risk. In fact, automation makes DevOps possible. C. Little famously said that “DevOps isn’t about automation, just as astronomy isn’t about telescopes.”
Never blame your DevOps tools again
Choice of tools affects productivity along the deployment pipeline via both the suitability of the tools themselves and the job satisfaction gained by working with tools of choice. For this reason, a tool-agnostic automation platform is important, and this includes open source tools.
Agile coding practices may suit a dev mindset more, but ops needs to be on board just as much
The most successful DevOps teams complement specialised tools such as Docker, Puppet, Chef and HP QC by integrating them into a heterogeneous automation platform. This allows DevOps members to continue working using the tools they are most comfortable with, while allowing IT the flexibility of tool neutrality which prevents processes from being held hostage to vendors. Additionally, an automation platform notifies team members of where along the pipeline a release or change is so everyone knows what to expect and when.
When an enterprise chooses to adopt DevOps principles in production environments for customer-facing apps, they need an automation platform that can meet the scale, rigors and compliance requirements of production seamlessly. Few are using open source tools in production. Automic surveyed 200 customers and asked, “Would you consider using open source tools for your production environment?” Less than 10% said yes. Ops teams tend to avoid using open source in the production environment.
A repeatable deployment pipeline logically gives us DevOps metrics by which to measure success, meaning the business can be reassured that their investment is increasing release velocity whilst maintaining reliability at scale. So automation brings reliability to the often daunting prospect of a DevOps transformation. Isn’t it time you crossed the chasm?
How to cross the DevOps chasm in a safe and reliable manner