Its DevOps Jim, but not as we know it

Long read

The traditional IT Infrastructure/Management role has evolved over the last decade, skills once cherished and in demand have now been confined to history. The expertise required to support a multitude of services on-premise are no longer as critical.

What primarily caused this change?

The proliferation of the cloud allowed companies to no longer have to invest in on-premise infrastructure, and with that the associated skills in maintaining such systems became redundant. The software as a service model made possible by cloud computing enabled the delivery of commercial applications at affordable prices.

Traditional IT teams were a cost to the business, a cost no longer justifiable, especially when, from the outside nothing was being produced, a cost with no corresponding revenue added to the business.

What remained for IT management?

The role has morphed into a service-based outlook, managing the services/orchestration, maintaining data security, managing service/platform costs, being responsive to technical needs – i.e. adding services to the businesses’ portfolio.

This can be done with a smaller team, or in many cases completely outsourced.

There may still be a need for specialization in areas of technology, however increasingly companies are outsourcing their Infrastructure support.

Parallels with DevOps

Currently, the idea of DevOps, the ability to rapidly deploy enhancements to the value stream is seen as a major boon to businesses.

However, at its heart, does this function truly in and of itself create value, or merely facilitate value?

If we are to conclude DevOps is a facilitator in the same way IT is a facilitator for services, all variables listed in traditional IT management are equally true for DevOps roles.

If the role of a DevOps Professional is as someone who helps the developers who produce the deliverable if savings can be made, why wouldn’t they be considered next?

For the intermediate future, just as there is a need for IT management in some capacity, large companies with sprawling estates may well continue to need an inhouse DevOps function.

Is this the case for small to medium-sized enterprises?

Currently, DevOps is seen as the Holy Grail of skills, however as the proliferation of tools settles down and the knowledge becomes more closely integrated with Development teams, the demand for DevOps will be met more easily and from within by existing Development focused teams.

Many Digital Agencies take it as a given that a developer is able to set up their projects in a version control system of choice and integrate with the existing CI/CD Pipeline

What was seen as a dark art is becoming the mundane, so what remains?

The market is ripe for savvy independent service providers or vendor-neutral companies to manage a SME’s CI / CD platforms.

However, even this market is ripe for disruption.

The disruptors

The prestige afforded DevOps professionals is likely to be undermined by the following variables.

DevOps as a service

The ability for the entire development stack to exist entirely on a preferred cloud provider, all commercial tools required to deliver value working seamlessly in one integrated platform, no worries about integration, deployment, maintenance with full visibility of costs.

Such an integrated DevOps pipeline are available from major vendors, e.g. GitOps with GitLab, Azure DevOps, and a host of others.

The advantage of DevOps in delivering enhancements to production quickly means this transition can happen even sooner than compared to the slow dissolution of the IT Managers role.

Smaller companies are certainly able to be more responsive to changes in the market so are likely to be the earliest adopters, larger companies, if they are embarking on a DevOps project are likely to embrace DevOps as a service as a first option, while those enterprises who have already DevOps processes in place may well follow suit eventually and embark on migration projects.

Essentially the DevOps role becomes orchestration of tool chains maintained on a saas environment, a single platform to coordinate all functions.

Offshoring development

There is an increasing trend towards offshoring skills, the ability to leverage a cheaper workforce in the global market to perform repetitive tasks. When one considers the Labour costs for developers abroad compared to the UK this becomes an enticing proposition.

Increasingly countries with a lower cost of living are being sought to establish Development hubs. This includes many European countries, South Africa, Latin Americas as well as India.

Accommodating teams within time zones of clients, the ability to provide a follow the sun model can be easily facilitated.

Naturally, the fate of DevOps is more closely intertwined with Development, where they go any DevOps skill requirements are likely to follow, moreover if the costs of DevOps expertise in UK are high, it would make sense to locate DevOps teams in a cheaper location.

I have written in Broad strokes about a trend to offshore, there are notable exceptions to this, even a counter-culture that is on the ascendency.

A mid-sized agency that provides clients with standard build packs or a large corporate with standard enhancements could certainly benefit from outsourcing. Even more complex development can be enhanced in cheaper regions by building centers of excellence over time, however, some organisations have chosen to stall or reverse outsourcing.

Counter culture

Many organisations have come to the conclusion that outsourcing can be a false economy.

Whereas mundane functions can be outsourced, or even replaced by an AI, the value a specialist IT function can bring to a business, or the ability to respond in real-time to crises is not to be underestimated.

There are tangible benefits in having an in-house resource for Development and by extension DevOps. Interdepartmental communication is more efficient, a project manager can precisely scope a project and monitor more closely when they have open lines of communication and clear oversight. Moreover, a company that has a successful working practice, an efficient delivery pipeline cannot easily shift an operation to a completely different company or offshore team that may have a completely different way of working.

This is compounded in large complex projects, where inefficiencies can easily offset the financial benefits of outsourcing.

In-House a company will have greater incentive to deliver, as their jobs and reputation are more directly affected, in outsourcing, a third party will not have the same risk to their reputation if their name is not directly attached to a high-profile project or campaign.

A third party will be able to dictate their timeline, their requirements, will easily be able to shirk responsibility without having to worry about their prestige.

I have heard numerous horror stories whereby a company is held ransom by another companies estimates, botched reporting of delivery completion through the use of arbitrary statistics, and hiding genuine inexperience of teams leading to critical failures.

Some companies have reached a compromise and opted on complex development, development that brings in the most revenue in house and maintenance, break/fix activities offshore.

For such companies, them a distributed DevOps platform model could work.

However, regardless of whether or not development remains UK based for many companies, the factors listed earlier are likely to cause a large dent in the prestige associated with DevOps skills. There will continue to be a market for DevOps but the role will no longer be as lucrative in the future.

So what happens next?

The rise of the SRE

For the technically minded, those who like the working against the coal face, a role that will be even more critical is the service reliability engineer (SRE).

The definition may vary between organisations as well as requisite skills, but fundamentally it is the role that ensures the stability of the production platform, by monitoring, pre-empting and troubleshooting the overall service delivery.

By excluding the heavy lifting associated with CI / CD, you are free to focus your energies on what delivers most value – ensuring the stability of the overall production site/platform/service.

Up until recently, emphasis on skills centred on the individual components of a system, the DBAs, the Sys Admins, the Network/Storage specialists. The emphasis on several of the roles listed has been on the wane.

The need to optimise a DB is no longer as critical when you consider the vast strides physical architecture has made in allowing fast access to data on disk. Moreover, with the ascension of infrastructure as code and the ability to simply destroy and redeploy, servers, VMS, containers, the skills of a SysAdmin are also no longer as important, provided you have efficient reporting and alerting of your overall platform.

An SRE approaches the platform holistically, is interested in redundancy, resilience, optimisation of the overall service, and monitoring the service end to end. The roll is cross discipline while not being focused exclusively on an area associated with a sysadmin or dba. By building resilience in the overall platform, if problems are encountered on nodes in the system, the SRE builds the system to be able with automatically respond to problems, while having the means to diagnose in retrospect.

Developers, for all their talents, have a tendency to overlook the complexities associated with deploying to or managing production environments (which lead to the term throwing over the wall).

So even if an organisation embraces a DevOps as a service model, diminishing the need for DevOps personnel, an SRE’s importance is even more important. The ability to pick up on dependencies in a system when deployed, facilitating the “failing safe” model.

The skills accumulated by Sys Admins are certainly well placed to transition into such a role, so there is hope for us.

As for Development

There will always be a need for Development, whether offshore, outsourced or local.

However, even if offshoring occurs within an organisation, for companies that have a highly skilled UK Development team their skills are likely to focus on more complex engineering, AI, analytics, or leading/orchestrating technical projects.

More emphasis on Soft Skills

Skills that are not likely to be disrupted will be those that need a presence adjacent to clients, we can see a greater emphasis on soft skills, or less technically focused skills in the UK market: Product Owners, Digital PMs, Account Managers with greater digital skills.

The ability to coordinate, communicate and dare I say it, impress the pants off of clients is still needed, but these are at a level of abstraction from the technical coal face in the same way the cloud/saas model provides a level of abstraction from the underlying skills needed to maintain hundreds of servers, firewalls, switches.

To mitigate against offshoring, skilled Digital PMs with the ability to interrogate estimates given by third parties, navigate projects with wild specifications/requests will become even more valuable.

The ultimate objective

The trajectory of DevOps as a profession is likely to mimic that of IT Operations.

If there is a silver lining, while DevOps as a standalone profession or skillset will not be as sought after, the idea of integrating enhancements rapidly into the value stream will have been realised, which is ultimately the objective for a business and the DevOps movement.

The requirements for shippable code will be a given, and the skills required to facilitate this end will be made simpler or via readily accessible mechanisms.

The industry will naturally change to accommodate and free up resource for tasks that actually create value in the same way the mundane tasks in operations have been automated through Infrastructure as code, microservices or the saas model.

This will create new requirements in the workforce as we enter a new phase and as per the law of supply and demand, professionals will need to adjust or become obsolete.

Written by Abdul Rashid Hamid, Global Operations and Service Delivery Manager at Stella McCartney