Outsourcing DevOps ... Should you?
Is it a good idea to Outsource DevOps ? What do organiations get out of outsourcing DevOps ? Lets discuss some experience based inferences.
DevOps has gained momentum within all industry sectors since at least last 5 years. As per Statistics from Forrester, as of the end of 2017, 50% of organizations were actively implementing and expanding their DevOps services and seemed to be reaching “Escape Velocity”. While few sectors are leading the charge – almost all industry sectors are leveraging DevOps to support their business transformation leading to agility and cost efficiencies. All Areas viz. culture, automation, monitoring, & management are all the key parameters of DevOps.
In reality, though most companies aspire to implement DevOps, not many are actually successful, or more importantly, they have been unable to keep momentum to drive this culture into each and every project being delivered.
Could outsourcing DevOps be the trick? And what about DevOps as a Service? Let’s take a brief look.
What’s the deal with DevOps?
Firstly, the promise by DevOps is to increase Agility by enabling quicker, and in many cases - easier, business change - allowing Businesses to respond to rapidly changing market needs. On top of this, DevOps also claims to reduce cost - more like a double benefit.
DevOps gets a lot of its punch from its emphasis on cultural change, which in reality appears difficult to achieve within an organization, at least without a serious commitment from the management. Even startups starting from a clean slate, struggle to set a culture that people bring with them from their prior work experience.
DevOps culture + Lean principles + Agile methodology are mostly bundled together as a single package - which in theory - achieves the benefits of improved agility due to increased automation in every phase of software development, along with Cost reduction - which is primarily driven by reduced resourcing demand due to increased responsibility on existing development resources.
NOTE: This Article assumes going forward that these three will be implemented together all the time and not in isolation
We would summarize DevOps - as a combination of these two concepts - Cultural Manifestation of the Agile principles + Development lifecycle Automation, with each organization embracing these to varying levels.
Who does DevOps sit with in the Org? How does this change ways of working?
This is quite an interesting question. Though the mandate for Cost saving (in IT) and increased agility (primary drivers for DevOps) sit with the Head of IT / Engineering, the actual implementation of the Automation sits with the Platform Team (and hence the success or failure of the initiative).
Complexities exist in these relationships - esp. within bigger enterprises, for e.g. one could be reporting to the other (or) may be not (or) may be one of them is outsourced / or 3rd party led or 3rd Party augumented etc.
Here, both these organizational roles/ teams need to work in tandem to achieve the common goal (establishment of which should be one of the first changes introduced by DevOps).
Teams such as “Cloud platform team” (or) the “Infra team” - will, typically, take up the deployment automation responsibility which eventually, post-DevOps Implementation, leads to the same teams being enforced with “BAU Release” responsibilities - completely new to the Platform teams while trimming down Release/ Project teams (potentially).
The “Release managers” may still exist, but will no longer have to be a part of this same team and their roles and responsibilities will also evolve, to more of a sanity auditor (or) more business focussed coordination roles.
What’s typically on offer from Service Providers?
There are a few different ways how DevOps services are packaged by Service Providers. The hands-on ones are typically technical (for the Platform team). Couple of them are -
DevOps Services - these are typically - “resourcing based offering”, where DevOps skilled resources are placed along with existing platform team members to augment, explore and identify the best DevOps practice which fits the organization. Having said that, Vendors offer other “Value-based services” which could be packaged/fixed cost / or fixed time implementation solutions.
DevOps as a Service - these are Productized versions of DevOps, where the offering pre-defines the technology stack + Security model + Solution Design covering both (multiple) Non-Prod & Prod Environments. These are faster to Demo and deploy, typically followed by fully supported support and Platform model.
Do note that both these offerings typically do not focus on the core DevOps punch - the cultural change, but only on Deployment Automation.
The DevOps End to End - Offering will include a lot more, and is mostly focussed on bringing the organization under DevOps. This includes the following “layers” to be executed -
Consulting Engagement (Cultural) - Working with Current teams to understand the current Development Process, educating on target Processes, identifying team redundancies, and advising on the complete process from end-to-end.
Consulting engagement (Technical) - focussing on the identification of current state & route mapping to get to a target DevOps state - including each of its phases - CI-CD / Development / Testing/ Deployment / Prod and Non-Prod setup / Build Automation / Containerization / Security / Monitoring and logging
Delivering DevOps Automation / Establishing Continuum - Implementing output of Consultancy as DevOps Automation for the solutions in Scope + training platform staff to extend and maintain the solution deck.
Training - Establishing and delivering an ongoing training program that will ensure the DevOps ethos & tooling are embedded within all of the Development Staff Programmers, Business Analysts, Testers, Release managers, Project/ program managers, etc also carried forward to future implementations.
Agile Programme Board - establishing an agile program board, to establish management practices, tools (Kanban boards, documentation strategy, etc)
DevOps Outsourcing - Good, Bad & Ugly
The Good — let’s start with some benefits of outsourcing for the organization.
The Price Advantage - You cannot state this benefit as the second point, the price advantage of outsourcing for a packaged proven tech solution will stand out of the crowd. A qualified engineer hired in-house will cost twice or more for similar DevOps superstars offshore. A typical advantage of outsourcing is true even in 2022+, given the complexity in developing and maintaining the toolkit.
Quick launch of DevOps Journey, a foot in the door. “Its the inertia one needs to get over with …”. With a large number of potential tooling options available with DevOps implementations, an Outsourced partner will beat the complexity and choice problem to setup and launch a proven secure template in a short time kicking the tires of the DevOps journey.
Reduced cost of ramp-up for in-house platform engineers, esp. after the DevOps automation is set up and ongoing for supporting BAU. This sets up the ways of working for the team, setting up launching
Access to a better resource pool - with the emergence of so many new techs, it’s hard to keep training in-house resources with all these new techs. An outsourcing partner will typically make these resources available in a shorter time.
The bad - some Pitfalls, that organizations should be aware of. Embedding DevOps culture requires a more holistic approach, with participation from Organizations as well.
DevOps is a culture, and that goes without saying that this is not just for in-house team members - but has to be embraced by the Outsourced vendor teams as well. DevOps requires good teamwork, and Enterprises will need to ensure closer working ties and integration with outsourced partner team members / augmented team members (contractors/temps) - to ensure the flow of information and motivation
Tooling / Software can be really complex, and hence require focusing on Standardization of implementation, without cutting corners and avoiding Solution specific implementations / technical debts.
Training resources/team members to forget and re-learn new processes, and ways of working (and not just software/tools) could be quite complicated and may challenge retention rates.
The Ugly - Undercurrents to be aware of for Management post implementation of DevOps.
These are effects of DevOps, rather than OutSourcing.
DevOps implementation introduces changes in the culture leading to resources undertaking multiple activities viz. Development, Unit Test (pluggable to regression testeing), Releases, Post-implementation testing and finally taking responsibility for BAU code support - activities which in a pre-DevOps world would be covered by multiple teams.
Multiple responsibilities could be considered as too much responsibility on Developers, who would in a normal world mostly enjoy only Programming - and may result in - slowing down of releases, poor performance etc.
Release prioritization and release planning will be far more - Developer-led, rather than BA or Programme-led, leading to potentially wrong prioritization of workload.
In Summary, there are lots of benefits of Outsourcing DevOps Implementation leading to Business Agility - and a quick turnaround time for Business Changes. However, unlike other typical Outsourced projects, DevOps rollout - being an initiative for Cultural change - involves active participation from both the Outsourcers and the Outsourced leading to reaping great benefits.
Author: Dilish Kuruppath / BridgeApps Ltd, London, UK