Sysadmin blog From every angle, developers are the key to the public cloud. Unfortunately, today's developers often aren't up to the challenge and frequently end up being as much of a roadblock as operations administrators. New breeds of technologists are required, bringing new ways of thinking to using the emerging infrastructure superpowers of tomorrow.
Actually, I lie. What's needed isn't – for the most part – a particularly new way of thinking. It's a rather old one, with a twist. But I'm getting ahead of myself. Let's start at the beginning, of the modern era of computing.
This began with the introduction of the microcomputer. Suddenly (it took about 15 years) everyone had a computer on their desks. Servers held some centralised resources, but individual PCs could crunch away on things and nobody had to worry about time sharing on mainframes.
The web was born. High level programing languages, just-in-time interpreted languages and markup flourished. Assembler and even languages like COBOL faded. Developers stopped learning about the nitty-gritty of the systems they were developing for; they focused on writing applications and let the compiler, development framework, operating system and hypervisor take care of ensuring things didn't blow up.
"Coding in Assembly is easy. It's like riding a bike. Except the bike is on fire & you're on fire & everything is on fire & you're in Hell
— Khalil (pilgrim) (@sehnaoui) June 14, 2015
Systems administrators - who are now called operations or infrastructure teams - forgot how to code. Decades of putting out fires and writing truly appalling, kludged little scripts reduced most of the operations caste to mere plumbers. Computers became so complex, and applications ran through so many layers of abstraction, that rebooting was often the only tool that operations had left.
Prejudices and rivalries developed. In most organisations operations hated developers and developers hated operations right back. This interdisciplinary bunfight started happening just as pressure began mounting on organisations to be "adaptive" – a lovely euphemism for "replacing people's jobs with computers". China's economy really started to take off, and the only way Western organisations were going to survive was heavy amounts of automation. This reached from Fortune 500 companies all the way down to SMBs.
DevOps emerged as a discipline mostly to get the two sides talking again. DevOps was essentially the formal recognition that most developers were cranking out non-deterministic code and most operations teams were building infrastructure that behaved in a non-deterministic fashion.
Meanwhile, for the past 20-plus years, security has been screaming at the top of their lungs but who is listening? And now we have these "cloud" things, and few organisations have clue how to use them.
Operations has become a discipline of professional paranoia and blame management
Developers feel the lash of the overseer if deadlines aren't met. Features must be added at a frightening pace and there is never enough time to do things right. Unfortunately for many - if not most - this means pushing code out the door with alarmingly little testing. Indeed, entire disciplines of development philosophy emerged around just how exactly one could push code out live with minimal testing and not get vanished in a dark alley for it.
Operations feel the lash of the overseer when things inevitably break. When something goes splork, the finger of blame points first (usually "last and always" as well) to operations.
Nearly everyone who has ever worked in operations can tell tales of being berated for the failure of devices or code over which they have little control and even less input. The result is that operations has become a discipline of professional paranoia and blame management.
Security is viewed by both developers and operations as being constantly "in the way". Until the inevitable breach occurs, at which point security is first against the wall.
Clouds are different
Clouds are not traditional infrastructure. Oh, they're made out of the same stuff, but the process of provisioning everything – storage, compute, networking and more – is "self-service". That is to say it can easily be accomplished by sending commands to an API. This can be done either through a user interface, operations scripting or as part of the application being assembled by developers.
This lets developers provision their own infrastructure whenever they feel like it. Of course, it's a lot harder for developers to blame their mistakes on a multi-billion-dollar company's highly trained, specialised, automated and testing-obsessed operations team. In a cloudy world you can't just jab a finger at operations and fob an angry suit off on the room of weird socially inept people down the hall.
While operations teams at organisations going cloudy are initially elated not to be in the firing line for every little error, that doesn't last long.
Operations are used to thinking a certain way: one centered around controlling every last detail, having plenty of surplus capacity and being able to run workloads 24/7 without thinking about it. Public clouds cost too much for those sorts of workloads.
Oh, and still nobody listens to security.
The death of operations
Developers are going to have to evolve into DevOps. Security will evolve into SecOps. Operations as a separate discipline will go away.
Even for companies buying their own infrastructure, private and hybrid clouds will be consumable as plug-and-play appliances within five years. The entire discipline of IT operations is in transition. Operations will fade away as their knowledge is imparted to developers and procurement staff.
Operations as we know it will shard into support (living knowledge repositories that can do basic tier 1 and 2 help desk work) and incident response (black helicopter specialists summoned when you push the "oh shit" button).
The role of developers too is changing. Companies of all sizes depend on them now more than ever, and as cloud adoption - public, private and hybrid - increases, developers will take more direct control of the infrastructure their applications consume. In order to adapt, developers are having to learn to think differently. They have to become DevOps.
This will require that developers become more paranoid. Increased control brings with it increased responsibility. With operations out of the way and infrastructure provisionable through APIs there is no one to blame for delays but themselves.
We have an incident
And they can't go on ignoring security any longer.
DevOps are going to have to step up their testing, because downtime can't be allowed. Also - not to put not too fine a point on it - a lot of jobs are going to be replaced by their code. If the computers stop working, there simply won't be anyone left to do things the old fashioned way.
Security and operations will have to merge into that incident response team and it will take a lot of adapting. Security has to stop hollering into the inky blackness about prevention and detection and start building policies and procedures for when things inevitably do go wrong.
The former operations guys can help a lot here; data protection is part of their psyche, and automation is what they do. There's a lot of overlap in the mindsets of security and operations – namely paranoia – and so they're a good fit.
Given that their job is essentially to presume that the DevOps side of the house have failed at their job, it's probably easier to integrate security and operations into SecOps than marrying operations and developers into DevOps.
Breaking down the walls only to build them up again
Of course, it's not that cut and dried. DevOps and SecOps are both going to have to learn to listen; to take the advice of one another if either is to survive. DevOps are about to become the most important staff members in any company, even the small ones.
Without their code, few organisations will be competitive. SecOps will be the mop-up crew, finding breaches and isolating them in as automated a fashion as possible. Responding to threats, performing forensics and – most crucially – navigating the very human politics of delicately convincing others they need to care.
Some of SecOps can be done behind the scenes. Some of DevOps can be done in isolation. But where the two meet new rivalries will replace old...and this time we can't wait decades to build bridges. At least, finally, security has a seat at the table. The disruptive influence of the cloud was good for something, after all. ®