In the last post, DevOps – how not to do it!, we considered the different anti-patterns for DevOps; the short cuts that result in a swamp of poor practice, failure and frustration.
This post looks at the positive patterns that, executed with care and diligence, unlock the power of DevOps and deliver the benefits companies are seeking.
There is no magic topology which will suit every organisation but adopting one of the positive patterns outlined below will significantly increase the likelihood of success.
Patterns for success
Dev and Ops collaboration – the ‘promised land’ of DevOps: smooth collaboration between Development and Operations teams, each specialising where needed, but also sharing where required. There are likely many separate Development teams/squads, each working on a separate or semi-separate product stack.
This pattern relies on quite substantial organisational change to establish it, and a high degree of competence in the senior technical management team. Development and Operations must have a clearly expressed and committed to a shared goal (for example ‘Delivering Reliable, Frequent Changes’). The Operations team must be comfortable pairing with Development and embrace the fundamentals (e.g. test-driven coding, Git etc.) Development, for their part must take operational features seriously and seek out Operations for input into logging implementations, and so on, all of which needs quite a culture change from the recent past.
Fully shared Ops responsibilities – where Operations people have been integrated in product development teams. There is so little separation between Development and Operations that all people are highly focused on a shared purpose – this is arguably a form of Dev and Ops Collaboration pattern, but it has some special features. Organisations such as Netflix and Facebook who effectively have a single web-based product have achieved this topology, but it is not hugely applicable outside a narrow product focus, because the budgetary constraints and context-switching present in an organisation with multiple product streams are likely to force Development and Operations further apart. This topology is also called ‘NoOps‘, as there is no distinct or visible Operations team.
Ops as IaaS – organisations with a fairly traditional IT Operations department which cannot or will not change rapidly (enough), and for organisations who run all their applications in the public cloud (Azure, AWS, Verizon, etc.), it helps to treat Operations as a team who simply provides the elastic infrastructure on which applications are deployed and run. The Operations team is then directly equivalent to Azure or AWS, or Infrastructure-as-a-Service (IaaS).
A team (perhaps a virtual team) within Development then acts as a source of expertise about operational features, metrics, monitoring, provisioning, etc., and probably does most of the communication with the IaaS team. This team is still a Development team, however, following standard practices like TDD, CI, iterative development, coaching, etc. The IaaS topology trades some potential effectiveness for easier implementation, possibly deriving value more quickly than “Dev and Ops collaboration” which could be attempted at a later date. In general, this is a good half way house as part of the journey toward enhanced DevOps maturity.
DevOps as an external service – the Development team reach out to a service provider to help them build test environments and automate their infrastructure and monitoring, advising them on the kinds of operational features to implement during the software development cycles. What might be called DevOps-as-a-Service could be a useful and pragmatic way for a small organisation or team to learn about automation, monitoring, and configuration management, and then perhaps move towards a “Ops as IaaS” or even “Dev and Ops collaboration” pattern as they grow and take on more staff with operational focus.
DevOps team with an expiry date – looks substantially like “DevOps team silos”, but its intent and longevity are quite different. This temporary team has a mission to bring Development and Operations together, ideally towards a “Dev and Ops collaboration” or “Fully shared Ops responsibilities” pattern, and eventually make itself obsolete. The members of the temporary team will ‘translate’ between Dev-speak and Ops-speak, introducing crazy ideas like stand-ups and Kanban for Operations teams, and thinking about dirty details like load-balancers, management NICs, and SSL offloading for Development teams. If enough people start to see the value of bringing Development and Operations together, then the temporary team has a real chance of achieving its aim. Crucially, long-term responsibility for deployments and production diagnostics should not be given to the temporary team, otherwise it is likely to become a “DevOps team silo”.
DevOps evangelists team – Within organisations that have a large gap between Development and Operations, it can be effective to have ‘facilitating’ DevOps evangelists (individuals or teams) that keeps the two sides talking by spreading awareness of DevOps best practices. This is a version of “DevOps team with an expiry date” but where the DevOps team exists on an ongoing basis with the specific remit of facilitating collaboration and cooperation between the teams.
SRE team (Google pattern) – DevOps often recommends that Development teams join the Operations on-call rotation, but it’s not essential. In fact, some organisations (including Google) run a different pattern, with an explicit ‘hand-off’ from Development to the team that runs the software, the Site Reliability Engineering (SRE) team. In this pattern, the Development teams need to provide test evidence (logs, metrics, etc.) to the SRE team showing that their software is of a good enough standard to be supported. Crucially, the SRE team can reject software that is operationally substandard, asking the Developers to improve the code before it is put into Production. Collaboration between Development and SRE happens around operational criteria but once the SRE team is happy with the code, they (and not the Development team) support it in Production.
Container-driven collaboration – Containers remove the need for some kinds of collaboration between Development and Operations by encapsulating the deployment and runtime requirements of an application into a container. In this way, the container acts as a boundary on the responsibilities of both Development and Operations. With a sound engineering culture, the “Container-driven collaboration” pattern works well, but if Development starts to ignore operational considerations this pattern can revert towards to an adversarial ‘us and them’.
Dev and DBA collaboration – this pattern brings together database capability from the DBA to complemented the database capability (or specialism) from the Development team. This helps translate between the Dev-centric view of databases (as essentially dumb persistence stores for applications) and the DBA-centric view of databases (smart, rich sources of business value).
So What
There is no fixed, one-size-fits-all pattern. Organisational size, capability, maturity and need all figure largely in the patterns required.
Whilst enabling technology is important (obviously), it’s the patterns you adopt that increases the likelihood of success and the associated benefits. Ultimately successful DevOps centres on the organisation and the people – get that right and you’re a long way down the path to unlocking real business value.
