Tag Archives: Operations

What does the future of IT Operations look like (in a #DevOps world)?

What does the future of IT Operations look like? As more businesses rely on virtualisation, containers, cloud, Infrastructure as a Service and Microservices is there still a role for IT Operations? How do these teams change to continue to deliver value when supporting Agile Operations techniques?

Is there still a role for IT Operations? Absolutely 100% (we believe that so much we started a company to offer application-centric cloud operations!).

We blogged about this back in 2013 when we said that “Devops Does Not Equal “Developers Managing Production”. We said then:

“Operations is a discipline, with its own patterns & practices, methodologies, models, tools, technology etc. Just because modern cloud hosting makes it easier to deploy servers without having to know one end of a SCSI cable from another doesn’t mean you “know” how to do Operations (just like my knowledge of SQL is enough to find out the information I need to know monitor and manage the environment but a long way from what’s required to develop a complex, high-performing website).” – @TheOpsMgr

This still holds true today.

That said, the role of Operations is changing – Ops has to become more “Application-Centric” and understand the applications that are running on the platforms they provide. It’s not enough anymore to take a narrow view that says “my servers are OK, it’s not my fault the application doesn’t work”. Well, it might not be your “fault” but you share the responsibility for making sure the application is available for your customers. Stop passing the buck!

Operations people almost certainly need to learn to code, since we are heading towards a code-driven, API enabled world.  If you can’t code (or at least have solid scripting skills) you risk being left behind will be left behind.

More importantly, the Operations Engineer/Developer of the future will be filling a role more akin to that of a “process engineer” in a physical factory or logistical supply chain.

A process engineer designs a process and production line that transforms raw materials into a finished product.

The Operations Engineer/Developer of the future will be building Digital Supply Chains and Digital Production Lines.

These Digital Supply Chains will transform raw materials (source code) via continuous integration, test automation, packaging, release automation, infrastructure-as-code etc into applications running in cloud-hosted environments.

The rate of changes flowing along the Digital Supply Chain will far exceed “old school” Change and Release methodologies – you can’t have a weekly CAB (Change Advisory Board) meeting if you’re doing multiple deployments per day (or every 11.6 seconds à la Amazon).

So, just like a physical production line includes statistical sampling, automated testing etc., so will the Digital Supply Chain of the future. We already do this with TDD/BDD, automated testing with tools like Selenium etc but it will become the Operations Engineer/Developer job to ensure that the digital production line delivers release packages of sufficient quality to ensure the stability of the application (and the organisation’s revenue that depends on it!).

Modern supply chains are complex and have many interdependencies on 3rd parties, particularly if you’re operating a “Just-In-Time” (JIT) model. Modern software applications have the ultimate in JIT dependencies due to their integrations with 3rd party SaaS API’s like payment gateways, recommendation engines, authentication gateways, cloud providers etc. Modern Operations Engineers will need to ensure that they design the digital supply chain that can cope with failures in these interdependencies, or at least ensure that they select the right 3rd party partners who can offer the right levels of performance and availability needed for their applications.

In summary, will the Operations Engineer/Developer of the future be “just managing (virtual) servers”? No, almost certainly not.

What they will be doing is designing and building complex digital supply chains with complex interdependencies both internally and externally to the organisation, digital supply chains designed to meet the needs of applications that are designed to meet the needs of their customers, safely, securely and cost-effectively.

The Q&A above is part of material prepared as our contribution to an CA ebook on “Agile Operations”. We wrote our thoughts on 6 questions, of which 4 will be used in the ebook, scheduled to come out in August 2015. You can read the earlier Q&A here – http://blog.devopsguys.com/2015/06/23/what-is-important-for-an-it-ops-to-team-more-effectively-with-preproduction-teams-devops/  

DevOps, Adam Smith and the legend of the Generalist

Is DevOps at risk of being misinterpreted as “everyone should be able to do everything”? 

That somehow DevOps means you should be able to switch seamlessly between Development and Operations tasks, writing some Java application code in the morning, re-configuring the SAN in the afternoon and finishing off with a bit of light firewall maintenance in the evening ?

Take this great quote;

I’ll tell you EXACTLY what DevOps means.

DevOps means giving a shit about your job enough to not pass the buck. DevOps means giving a s**t about your job enough to want to learn all the parts and not just your little world.

Developers need to understand infrastructure. Operations people need to understand code. People need to f***ing work with each other and not just occupy space next to each other. –  John E. Vincent (@Lusis)

Whilst we whole heartedly agree with the sentiments in the quote I think that there is a risk that the phrase “need to know” about Development or Operations will be misinterpreted by some as “we need generalist staff who can do it all”.

Sadly, this would be a tragic mistake for several reasons but first and foremost because division of labour exists for a reason.

There is literally hundreds of years of economic theory, dating back to Adam Smith’s “Wealth of Nations” in 1776 and beyond, that shows how & why division of labour increases overall productivity.

Whether it’s making pins, cars or software applications the correctly co-ordinated activity between a sequence of specialists will massively increase overall productivity. In the context of making pins Smith quoted an increase in productivity of 24,000% (in comparison to one person performing all of the tasks required to make a pin).

Note that there is a critical caveat in the paragraph above – “correctly coordinated”.

Poorly coordinated activities between specialists impedes productivity and creates bottlenecks, mistakes and re-work. Reinert’s ideas of “flow” in product development, Goldratt’s Theory of Constraints (TOC) and the whole Lean movement are about ensuring that activities in the “value chain” are correctly aligned and smoothly flow from one stage (or specialism) to another to ensure that maximal productivity and value are achieved.

So what does this mean in terms of DevOps and the quote above?

Coordination requires effective communication so I think that the quote above could be re-stated to say “need to know enough about Infrastructure/software development in order to be able to communicate effectively with other specialists”.

For example, Developer’s need to know enough about infrastructure and web operations to understand why a scalable user session state management solution is critical when running a distributed system because “just running it all on one box like we do in my dev environment” isn’t a good solution. Conversely Operations need to know enough about the language stack they support to be able to read a stack trace as part of their troubleshooting workflows to help identify the root cause of a problem.

So whilst hopefully agreeing that DevOps doesn’t mean the end of specialists performing specialized skills and ergo the creation of hybrid generalists it’s worth mentioning that Adam Smith did have some warnings on the downsides of over-specialization that have some resonance for DevOps:

“The man whose whole life is spent in performing a few simple operations, of which the effects are perhaps always the same, or very nearly the same, has no occasion to exert his understanding or to exercise his invention in finding out expedients for removing difficulties which never occur. He naturally loses, therefore, the habit of such exertion, and generally becomes as stupid and ignorant as it is possible for a human creature to become. The torpor of his mind renders him not only incapable of relishing or bearing a part in any rational conversation, but of conceiving any generous, noble, or tender sentiment, and consequently of forming any just judgment concerning many even of the ordinary duties of private life” – Adam Smith (Wealth of Nations)

Alexis de Tocqueville agreed with Smith:

“Nothing tends to materialize man, and to deprive his work of the faintest trace of mind, more than extreme division of labour.” Alexis de Tocqueville

Smith warned that workers “become ignorant and insular as their working lives are confined to a single repetitive task” which is the silo-oriented mental state that @Lusis rails against in the opening quote when he says DevOps “means giving a shit about your job enough to not pass the buck”.

DevOps “First Way” emphasises “Systems Thinking” – looking at the larger system as a whole not just your narrow silo view – so the risks raised by Smith and De Tocqueville are valid concerns for DevOps.

So there is a tension here… we need the productivity of specialisation but we don’t want the insular worldview of “extreme division of labour”.

Scrum in Agile software development addresses similar concerns by emphasising cross-functional teams, “Individuals and interactions over processes and tools” and generally focussing on high-bandwidth communication as a way to tear down silos.

DevOps can (and should) emphasise the same solutions to resolve this tension.