DevOps – a term bandied about by all, understood by few, and delivered by almost no-one. Why? Partly because there are many different flavours of DevOps, and not all of them are workable or desirable.
This post considers the different anti-patterns for DevOps – we looked at positive patterns in DevOps – making it work!
The primary goal of DevOps is to enhance the delivery of business value, not to directly reduce costs or increase automation, or change the operating model. This leads to the conclusion that different organisations require different structures to enable effective collaboration between Development and Operations. There is no magic topology which will suit every organisation.
Dev and Ops silos – the classic ‘throw it over the wall’ split between Development and Operations. It means that story points can be claimed early (DONE means ‘feature-complete’, but not working in Production), and software operability suffers because Development do not have enough context for operational features, and Operations teams do not have time or the inclination to engage Development in order to fix the problems before the software goes live.
DevOps team silos – The DevOps team silo typically results from a manager deciding that they “need a bit of this DevOps” and starting a ‘DevOps team’. The members of the DevOps team quickly form another silo, keeping Development and Operations further apart than ever as they defend their corner, skills, and toolset from the ‘clueless Devs’ and ‘dinosaur Ops’ people.
Dev don’t need Ops – this topology is borne of a combination of naivety and arrogance from developers and development managers, particularly when starting on new projects or systems. Assuming that Operations is now a thing of the past (“we have the Cloud now, right?”), the developers wildly underestimate the complexity and importance of operational skills and activities, and believe that they can do without them, or just cover them in spare hours.
DevOps as tools team – in order to “become DevOps” without losing current development teams’ velocity (delivery of functional stories), a DevOps team is set up to work on the tooling required for deployment pipelines, configuration management, environment management, etc. Meanwhile Operations folks continue to work in isolation and Development teams continue to throw them applications “over the wall”. Although the outcomes of this dedicated team can be beneficial in terms of an improved tool chain, its impact is limited. The fundamental problem of lack of early Ops involvement and collaboration in the application development lifecycle remains unchanged.
Rebrand SysAdmin – this typically occurs in organisations with low engineering maturity. They want to improve their practices and reduce costs, yet they fail to see IT as a core driver of the business. Because industry successes with DevOps are now evident, they want to “do DevOps” as well. Unfortunately, instead of reflecting on the gaps in the current structure and relationships, they take the elusive path of hiring “DevOps engineers” for their Ops team(s).
Ops embedded in the Dev team – The organisation decides it does not want to keep a separate Operations team, so Development takes responsibility for infrastructure, managing environments, monitoring, etc. However, doing so in a project or product-driven way means those items are subject to resource constraints and re-prioritisations which lead to subpar approaches and half-baked solutions. The organisation shows lack of appreciation for the importance and skills required for effective IT operations, such as reliability, stability, compliance with regulation etc.
Dev and DBA silos – this form is prominent in medium-to-large companies where multiple legacy systems depend on the same core set of data. Because these databases are so vital for the business, a dedicated DBA team, often under the Operations umbrella, is responsible for their maintenance, performance tuning and disaster recovery. The problem is when this team becomes a gate keeper for any and every database change, effectively becoming an obstacle to small and frequent deployments (a core tenet of DevOps and Continuous Delivery).
I suspect anyone reading this post will recognise in their current or former organisation at least one of the above anti-patterns.
If companies are not willing to consider DevOps in terms of culture, organisation AND development lifecycle technology optimisation then it simply becomes a rebranding exercise of the SysAdmin role. Unfortunately, this is becoming more and more widespread with unscrupulous consultants and recruiters presenting candidates with automation and tooling skills as DevOps architects – they’re not!
It’s the bringing together of the human communication skills as well as the processes and technologies that makes DevOps thrive in an organisation – but its not simple or quick. Beware the DevOps snake oil salesmen.
In DevOps – making it work! we look at the patterns that actually deliver on the DevOps promise.