1. There is no such thing as fire and forget infrastructure.

2. Refining application and systems architecture through growth requires the attention of humans qualified by their experience with it and its components, and this cannot be replaced by a faceless Level III Linux Technical Support Engineer who changes every 8 hours.

If there were such fantastic, mythical gifts from the gods as fire and forget infrastructure to be had, then my phone wouldn’t be ringing every month with calls from people who have hit EC2 instance IO limits and don’t know what to do about it.

If you believe platooning systems engineers is a good idea, you have probably never talked to someone who has had a master InnoDB partition destroyed by one of them who “noticed mysql was down” and “tried to restart it for you” while an index rebuild was in progress. That’s an extreme — but very real — example. This wasn’t a tape monkey. This was a senior “consultant” on a very high profile hosting company’s engineering support staff.

And no, “admin-type” coding, isn’t going away. There will be no de facto (though plenty of du jour) “standards” in the monitoring marketplace. Do you honestly think there’s going to be an instrumentation specification implemented consistently across Java, Ruby, Python and PHP? Because that would be a requirement. Dream on — better yet, go work on making it a reality. But it’s not happening anytime soon. Provisioning? Provisioning WHAT? WHEN? HOW MUCH? And please, do not try and give us that “just in time” / “on demand” crap. Its only on time if its already online when you need it. If you’re looking at your production systems load and thinking “wow, we need more X, Y and Z let’s go deploy a bunch of additional instances!” then you’ve suffered a failure in operations already, because enough X, Y and Z would have already been there if someone qualified and possessing the requisite application-specific domain expertise were paying attention to operations. Meanwhile your cloud is being blown away by the sudden uptick, and failing in manners wholly indistinguishable from a traditional bunch of dedicated racks, as far as your management and customers are concerned.

So, OPS is going away? Sure. Sales is going away too. And HR. And Marketing. And Finance. And there are rainbows in the heavens with unicorns dancing on them. Yup.

I can see why a guy like John would get ticked off whenever some jackass cargo-cults the notion. It’s ludicrous.

The above things I list (”ops” things) are application-specific. Monitoring, troubleshooting, capacity planning, deployment…isn’t just driven by CPU, memory, disk, and network levels measured within pre-defined windows; it’s those things within the *context* of the application. If a service provider has enough in-depth knowledge about my application to perform the above list within the right context, they’re not service providers, they’re *consultants”.

“Ops” consultants.

Make no mistake – ops *will* go away, in stages, over time. Ultimately, enterprises will retain software and database and *maybe* network architects, but the rest will be handled by SP owned-and-operated cloud systems, run by SP personnel.

As someone who started life as a sysadmin, I’m always annoyed and amused by the dev-centric attitude that pervades the industry. While the worst offenders believe that they’re at the top of the food chain, the reality is that a good OPS person is worth much more than any given dev — because they understand how the real world works.

This is especially true when you’re talking about networked applications; too many developers want to live in a fantasy world where there’s one address space, binary failure modes, no latency, and concurrency is a distance (and rather new) concern. OPS folk, IME, have none of these delusions.

/rant

I do ‘ops’ — which invariably ends up being a lot of ‘glue’ coding to make things work. We’re currently implementing a cloud type system in our (small) datacenter, which we’re referring to as a “self-healing” system so that we don’t have our budgets cut. It’s essentially made up of virtual containers that are geographically distributed and constantly-or-frequently backed up.

What does it mean for our users? We have 9.however-many-nines-you-want-to-put-here% uptime as long as the campus network is up, and there’s less wait time for new applications to come online because we don’t have to acquire new hardware and develop a disaster recovery plan (among other documentation) every time we address a request.

Of course, it depends what point you are in your business. We went through a period where we would spend almost every day installing new hardware. Luckily that doesn’t apply so much anymore.. I like my desk and datacenter’s are a horrible environment, and get to do the above ops work!