Why DevOps is Idealism

In my earlier post “Why DevOps is an Illusion”, I sum it up as:

DevOps is a euphemism for cost-cutting. It is mind conditioning at the expense of a poor soul who does what two persons are supposed to do.

The TL;DR version: DevOps expect so much from people when the bulk of functionality must be built into software.

Now, before this blog post gets misunderstood out of context, let me set the record straight: I support building apps which are ops-friendly and building software which are dev-friendly. But it doesn’t mean you have to juggle development and operations as the IT industry would have you believe.

Companies especially startups want to maximize their hiring strategy. Who doesn’t want two roles rolled into one?

Now, if you don’t believe me that Dev and Ops are really two roles, this is a quote from Consul documentation:

CONSUL

This is the line of demarcation between devs and ops.

Devs are concerned with the application development, not software development. There is a difference between apps and software.

Application is to devs what software is to ops.

Now, I certainly don’t mean to demean developers but this is one distinction that needs to be made so anyone can manage their expectations accordingly.

Second, application is to auto driver what software is to auto mechanic.

If you’re an app developer, you need not learn how the auto works and certainly you need not learn how to fix it when something fails (unless you want to).

As usual, I certainly don’t mean to equate ops with mechanics. This is the second distinction.

Third, even if assuming you found a unicorn (one with exceptional developer and ops abilities which is like saying Superman is real), I’d like to quote one observation Adrian Colyer quoted himself in his post “How Complex Systems Fail”

The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable. Outsiders rarely acknowledge the duality of this role. In non-accident filled times, the production role is emphasized. After accidents, the defense against failure role is emphasized. At either time, the outsider’s view misapprehends the operator’s constant, simultaneous engagement with both roles.

Even if you found a DevOps, you cannot expect them to step up to the plate. There is clearly a distinction for dev and ops roles.

So why is the IT industry perpetuating this DevOps myth?

First, it is purely economic. The notion goes that if you can find a developer and an ops in one, you save salary overhead in the process.

Second, it is idealism. Maybe the industry is too infatuated with hopeless romantics.

And third, DevOps is a marketing term for companies big and small to sell you tools, tickets and bullshit methodology to drive their revenue. It’s the continuation of the class-based OOP hype.

What can we do to address this DevOps dilemma?

Development is hard. And so is operations.

  • We need the software companies to rise up to the occasion and reduce software complexity to an engine with minimal interface. This is the target of functionality.
  • Once functionality is stabilized, we need to emphasize usability. And please, no YAML (didn’t you receive the Hashicorp memo?). If not, let me quote it for you:

With YAML, we found that beginners had a really hard time determining what the actual structure was, and ended up guessing more often than not whether to use a hyphen, colon, etc. in order to represent some configuration key.

  • We cannot belittle usability here. A majority of software companies are guilty of Curse of Knowledge. In their quest to solve complexity, they forgot how it’s like to be a newbie. They are lost in the game of usability. Go language is an exception. For the first time in history, we are seeing a programming language emerging as the gold standard for application development. The breadth and depth of the Go language tools and ecosystem speak volumes for its deep understanding of this real concern called usability. It is no coincidence that the speed and quality of development within the Go ecosystem is faster and more reliable than any other.
  • All of this DevOps dilemma redounds to software still being young. That is, the software that is supposed to make application development and operations relatively simple are not there yet. Until we can address usability from design to implementation, complexity simply overruns us day in, day out.
  • DevOps means developing apps to be ops-friendly. Operations means software is developer-friendly. Apps and software are different. To be precise, apps are microservices. Software like NSQ, NATS and others are the macroservices that run conceptually below the microservices.
  • Even if we have developed the most sophisticated software, you cannot eliminate human intervention in operations.

But I’m a DevOps, you may protest.

No, you are not. You are either a developer or operations. Surely, developers give feedback to produce ops-friendly apps and operations give feedback to produce developer-friendly software.

In theory, a DevOps may be a superset of developer or operations in one.

In practice, they are separate.

Advertisements

Subjectivity aside, leave a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s