Why we don't need Devops

I am a strong believer in the fact that we don’t need Devops. We’ll at least I believe we shouldn’t need Devops. And I’ll tell you why.

Devops is a set of methods and procedures that is geared towards integrating the Operations specialist into the development team. This is done to the ends of developing an integrated software product consisting of the end-users application and related infrastructure components like middleware and operating systems.
Let’s take a closer look.

We are clearly talking about infrastructure components. But what is infrastructure?

Wikipedia tells us the following:

Infrastructure is the basic physical and organizational structures needed for the operation of a society or enterprise, or the services and facilities necessary for an economy to function. The term typically refers to the technical structures that support a society, such as roads, water supply, sewers, power grids, telecommunications, and so forth.

So we can safely establish that infrastructure is a facilitating entity, right? Something we all share and use.
The most commonly thought of when we talk about infrastructure is a traffic system and roads in particular.
Roads are everywhere. They are generally considered important for the economic and social structure in a country. Roads serve a very straightforward purpose, to facilitate transport of people and goods across a nation.

A road also has constraints.  The vehicles used to mitigate these roads are bound by constraints. Most of these constraints are measured in dimensional boundaries like length and width but there are others less obvious like indicator lights or visibility.
These constraints are in place to create certain uniformity. This uniformity is very important, because it guarantees that anyone can use the infrastructure after taking notice of the common rules (getting a drivers license).

A manufacturer of, let’s say, cars knows upfront what the constraints and limitations are for the transport infrastructure of the country or area he intended to build a car for. No designer will design a car that won’t fit the road by making it 5 meters wide. In the transport business it’s that simple. You build your product to fit the infrastructure and you can do that because you know upfront what the constraints and limitations are.

Now let’s take a look at ICT-Infrastructure.
A company’s ICT-Infrastructure is sort of the same as a Transportation infrastructure. It facilitates applications and takes care of the data transportation throughout the company.
Just like any Infrastructure it has it’s constraints, like the techniques that can be used or the security measures that have to be taken into account.

This is where the comparison stops and trouble begins.

For some reason software development for years has been delivering applications that demand alterations to the ICT infrastructure. And operations has been forced to make those alterations, leading to massively incoherent collections of it devices marked as “ infrastructure”.  As a result maintenance cost of ICT has skyrocketed. And even more important the implementation speed of new applications has plummeted.
Who’s to blame for that??
I know for a fact that the general consensus that among operations personnel is that application developers are to blame

I know this for a fact because I’ve worked as an operations engineer for several years.
But it’s not true.
After having worked with software developers for quite a while I now strongly believe that no developer in his right mind will develop an application if he knows upfront that it is not going to work on the company’s infrastructure. Just like no car manufacturer is going to produce a car that’s not allowed on any or all parts of a countries infrastructure.

So if developers aren’t to blame, who is? Well there is only one possible guilty party left: Operations itself. And the reason is simple: For not telling the developers upfront what the constraints of the infrastructure are.

A typical operations department is an ad hoc organisation that responds instead of a proactive one that communicates. Making itself into a victim of the situation rather than a partner to development. They are used to changing the road not the vehicle.

So if we communicated a bit more, we wouldn’t be in this mess, and we would most certainly not need something like devops. But most organisations are and so we need devops.

Next to the fact that devops is a very practical method that focuses on delivering functional software on working infrastructure, it’s a method that enables hands-on practical communication between operations and software development.
For operations it’s a way to partially get back into the driver-seat. On the other hand Software development will probably get their software in production a lot faster.
And who knows what kind of innovations may derive from it ?

Comments (7)

  1. R.I.Pienaar - Reply

    February 21, 2011 at 8:01 pm

    Have you read *any* blog posts about DevOps at all?

    The recurring theme is that its cultural and about more communication, everything else comes second to those 2.

    It's *all* about making people talk more and earlier which seems to address your major point squarely.

  2. [...] This post was mentioned on Twitter by Xebia Nederland and mouton 2 0, samkiller. samkiller said: RT @Xebia: New blog post: : Why we don't need Devops http://blog.xebia.com/2011/02/21/why-we-dont-need-devops/ [...]

  3. Vincent Partington - Reply

    February 22, 2011 at 11:25 am

    Your point is muddled. You start out by saying that we don't need Devops. Then you say you believe we shouldn't need it. And in the end you say that we should communicate more and then we wouldn't need Devops. But that we do need it now. So what are you saying?

    In any case, the whole point of Devops is that development and operations should communicate more and should work towards a common goal, in an agile manner so that the business needs are served the best. One way to implement that is to make one cross-functional team, not unlike having a tester on the development team.

    As for the analogy with real-life infrastructure: you do know that the whole "architect" analogy got us into the software mess in the first place?

    Regards, Vincent.

  4. Vivek Kumar Yadav - Reply

    February 22, 2011 at 12:36 pm

    You are holding the operations responsible for the problem. The operation guys too can list out problems that they face due to the practices followed by the developers. The justification that Devops is needed because Ops is adhoc though Developers do everything right could just be a single scenario but not the whole picture.
    This is biased and should not be the motivation to Devops.

  5. Lowe - Reply

    February 23, 2011 at 9:21 am

    @Vivek No he's not, you are building a straw man and attacking it.
    The whole idea is (and I echo R.I Pienaar answer) is to communicate better and be better in sync with the rest of organisation.

  6. Andrew Phillips - Reply

    February 24, 2011 at 12:23 pm

    If I'm reading you correctly, would Why we shouldn't need Devops be a more appropriate title? Or, to avoid some of the continuing lack of clarity surrounding the term "Devops", Why we shouldn't need an operations specialist embedded in every team??

    That would indeed be a discussion worth having, and I think we all agree that more and better communication and awareness regarding the constraints and requirements of the production environment goes a long way here. But, as R.I.Pienaar's comment points out, that's very much in the spirit of - central to, indeed - the Devops idea.

  7. Leendert Brouwer - Reply

    March 10, 2011 at 7:16 pm

    [quote]
    Well there is only one possible guilty party left: Operations itself. And the reason is simple: For not telling the developers upfront what the constraints of the infrastructure are.
    [/quote]
    Hold the phone there. I can understand your reasoning, but I don't think it's possible to describe every boundary for every aspect of the "infrastructure". Operations guys (at least where I work) usually go further than the hardware your applications will run on. They manage the OS, application containers and reverse proxies, load balancers, provided libraries, and so on. They're also usually held responsible for the availability and quality of these services, including the applications created by the developers. They need to be concerned about performance, security, scalability, monitoring, etc.

    From an Operations viewpoint, developers/architects tend to be quite creative while implementing stuff. Nothing wrong with that in itself, but I'd strongly suggest keeping the Operations guys in the loop while designing/developing. They may have viewpoints that developers don't tend to think about. But all these viewpoints for every possible scenario are impossible to capture in a single document, or even a book ("Release it!" may come closest).

    I'm not sure if I like the whole "devops" movement as it is often described, but I'm very sure that Operations needs to be closely involved in change processes (they often span a wider area than development alone). Personally I have a development background, and I decided to work in Operations for a while to become a better developer. So far, I've learned a damn lot in the last 12 months.

Add a Comment