It's a decade since DevOps became a 'thing' – and people still don't know what it means To everyone with DevOps in their job title (and a quick LinkedIn search turned up 45,597 of you just in my network): folks, you're doing it wrong. To every employer looking to fill positions like "DevOps engineer" (and there are plenty): you, too, are miserably misguided. As it turns out, DevOps isn't "a job title, a software …
that is easy to slip up on by the unwary.
It also means that anyone brave enough to say 'I'm an expert' will get heaps of shit heading in their direction because the snake oil salesman promised that it is the answer to life, the universe and untold riches.
Sceptic? I still am and treat it as a septic tank. Good stuff goes in and only smelly stuff comes out.
The optomist in me says that one day it will all work and the roads will be paved with gold.
I disagree, DevOps has worked for 30+ years a lot better than modern IT has.
You buy a platform instead of building one. That means mainframe, private cloud etc... you the hire developers who build your business software to run on that platform or buy software made specifically for that platform. This is what banks do. Then, operations operates the mainframe and works with the developers to apply system updates that may contain breaks.
This system works absolutely damn near perfect and cuts IT spending to almost zero.
What DevOps were you thinking of?
Devops is simply making developers own their own work as opposed to them picking up tickets and checking in code. It also gives them a level of ownership over how their applications are deployed and how their infrastructure is built etc.
Thats pretty much it.
The rest of it, the conferences, the books etc, you dont need it. Anyone who says they dont need any devops software is lying to themselves - you think you can get away with no SCM? Or a build server? Or something like a Jira?
A cynic might think that the current buzz around DevOps is really about circumventing "least privilege" access control policies, increasing workload of devs for no more money and de-skilling ops staff, whilst also giving a marketing buzz to vendors who want to peddle more stuff to solve the problems of removing privilege separation, increasing workload and de-skilling staff.
"DevOps is not a skillset and it's not a toolset: it's a mindset."
That is why your company should certainly sell, DevOps, Cloud As A Service etc. and refrain from buying any.
The optometrist to me says that all this vague cloudiness can be resolved by buying a new pair of spectacles and then I shall clearly see.
Company IT heads convene for meeting one day...
"Let's move to the cloud next week, that bloke from the consultancy said it was easy! We can cut Ops to zero and Devs to almost nothing, outsource everything. I mean the cloud is magic right? We'll save bucket loads of money in IT and we can blame everyone else when things blow up! It's win-win!"
Next steps....
Handful of bright, development minded Ops get to stay on so long as they promise to renounce their bad old ways of sysadmin, join the dark side and become 75% development skilled.
Devs that are left are automatically given full sysadmin privs over systems they're responsible for. Devs are now promoted to Senior Dev positions and get to lord it up over the cowering menial Ops who are now second-class citizens of the new world order and should be damned grateful they still have jobs from their benevolent dev overlords!
Not even close. VMs exist mainly because software developers don’t have access to a stable platform to design against. As such, they set a bunch of requirements for all kinds of systems which traditionally required more servers... which required IT people to build from a list of requirements... who then virtualized them.
In a DevOps environment, there’s no need for VMs because the platform is probably fully distributed using technologies like Redis for example. Table stores are favored over traditional SQL servers. Object storage is available without the need for file servers. As such, we develop software towards a platform which is triggered by timers and HTTP servers.
When you don’t have DevOps, you have IT guys and generally absolute shitty platforms which are closer to super computers than business systems. When you have DevOps, you can dump shit like software defined data centers. You don’t need virtual machines or containers. You don’t care about x86 vs ARM.
So.... nope... not even close. DevOps is about a system wher developers and operators develop and operate business systems without the chaos and madness you would generally find with IT people involved.
We’re currently replacing about $20 million of data center equipment and about 150 IT people with some Raspberry PIs and a dozen programmers. All the crap that has to be VMs like AD, e-mail and collaboration is going cloud. All the business software will be developed in-house. We have done initial testing and have proven that security, agility and performance is substantially higher this way.
Isn't it nice?
It's awesome to be in a world where you can have developers on staff who... if the code is slow will work with the DBA to make it better.
Imagine a world where the operators would see 90% CPU usage and be able to discuss with the developers what was going on and work together to identify whether it was bad code, an anomaly, etc... and then correct the problem? This generally happens because code which was originally intended for batch processing is reused without optimization for transaction processing. So, instead of being run once a night or hour, it instead is run a million times a minute. So, we then optimize queries and cache data if necessary and make sure the database is sharding the hot data where needed.
If you're not pissing away $1.9 million for :
- 6x Rack servers with 20 cores each, 256GB RAM each and 16 enterprise SSD drives
- 4 leaf switches, 4 spine switches, 4 data center interconnect switches plus all the 40Gb cable
- 2 dark fibers with CWDM for DCI
- VMware Cloud Foundation with NSX, vSAN, ESX/vSphere
- Windows Server Enterprise 2016
Which is pretty much the lowest end configuration you would ever want to run for a DIY data center...
You can instead spend the money on things like making software which really doesn't need systems like that. Run your generic crap in the cloud. Build your custom stuff to run locally. And keep in mind that the developers are able to run their systems on 10 year old laptops while they're coding. But the good news is that by dumping the data center and the staff to run it, they can now have new laptops and a better coffee machine. :)
"We’re currently replacing about $20 million of data center equipment and about 150 IT people with some Raspberry PIs and a dozen programmers."
I hate to be the one to break the news to you sunshine, but if thats true (I have my doubts) then most of your department about to be outsourced. I'd get your CV sorted out ASAP if I were you.
I'm the software architect. Pretty sure my team is safe.
I hope to be eventually outsourced. It would mean we did such a good job that the system won't require having us around.
My next career is biotechnology. I hope to obsolete myself in the next 3-5 years while studying to enter my new field. I'm hoping to move on to making a medical device for imaging the inner ear of a human and possibly using ultrasound to perform some basic procedures related to balance issues.
I do really appreciate the concern though. It is very kind of you :)
DevOps is about a system wher developers and operators develop and operate business systems without the chaos and madness you would generally find with IT people involved.
You what! I've seen this too many times in the past. Wildcat changes directly into a product system stuffing up the whole thing.
Users complaining because everything they go to use the system it has changed and they end up carrying out the UAT.
Hmmm.
Anyone else noticed who wrote this article?
His employment history is still up and visible on LinkedIn. You'll have seen him round here intermittently too, though maybe not as memorably as Steve Bong.
Spot many real jobs, or is it more about... well... lots of evangelising and PR stuff?
Every time a customer of mine says they do devops I ask the developers how they are getting on with being paged at 4am to support the system. They always look horrified and tell me they don't have pagers because the operations team do that. They aren't happy when I say they aren't doing DevOps then - a key feedback look of DevOps is that developers feel the pain of operational support, resulting in them putting in more effort to make sure that issues are properly resolved and the system is reliable and stable.
And, consequently, the company saves money by getting rid of all those operations teams and the developers quit because they're never not working, having to be developing during the day and fixing some bug that's 99% caused by something entirely outside their control (like a patch to a dependency or OS component or the simple fact that some other muppet pulled out a vital cable and tanked their services).
As a developer, I'm quite prepared to say: "No thanks!" to that. There's a reason why operations are operations and I'm development. They don't have a clue about heaps and stacks and memory and how interlocked synchronisation primitives really work or how to design an indexed relational SQL database so that it doesn't crawl under real-life loads. I don't have patience to fix stuff broken by other people in the wee hours of the morning.
As a developer, I'm also quite prepared to write extraordinarily good tests and to implement a good workflow for my team, complete with continuous integration and staging environments and automated rollouts and all that other stuff. Not because it's DevOps (TM) but because those things just make sense when you're running a large team and some of the team members aren't all that experienced.
I'll never call what I do "DevOps", though. Just like I don't use hashtags.
I heard about a study that was done regarding programmers and their work environments. There are several "deal breakers" that would force a programmer to quit (or not take the job), things like having a PHONE RING all of the time (and having to answer it).
I don't recall anything else specific. but here's a list of things that I would consider "deal breakers":
a) having to answer a phone while at the office
b) having to carry a pager (so you're always "on call")
c) 'too many cooks in the kitchen' (bad project management)
d) unclear objectives and/or requirements, particularly if they CHANGE a lot
e) too much "feeling" goin' on. nauseating, yeah
f) consistently NOT giving me the access I need to get my work done
g) company politics [in any form]
h) being forced to give unrealistic estimates (and then LIVE by them)
i) being in an "open office" (rather than "your own office" or a VERY private cube). that includes offices with cubes that have 3 foot walls, aka "a fish bowl". (whereas sharing an office with 1 or 2 other people is fine)
So if 'DevOps' means that you MUST be "operations" (on call, open office, dealing with users/customers) as well as "development", then I think it's a model for FAIL. Because the personality of creative programming types (the good ones, specifically) isn't well suited to the 'customer service technician' requirement.
I think a nuance being missed here is that devops isn't really appropriate for all scenarios. As the article - which is actually really good! - explains, it really originated in *one specific* area: the provision of hosted web services at large scale.
If you think about it, this area has some attributes that others really don't. Most importantly for my argument here, it doesn't involve "releases" to "customers", exactly. No-one thinks in terms of "deploying Facebook 5.6". They just go to Facebook. There isn't a clear "you are a customer of BobCorp running BobSoft 3.4" relationship going on there. Also, there is - to a reasonable approximation - only *one* Facebook. There aren't 50,000 Facebook deployments in the world, with 50,000 on-site Facebook admins who each have their own concerns that might affect when they want to deploy Facebook 5.6.
If you're dealing with *this specific model* - where there's only a very small number of deployments of the codebase you're working on, and your organization has a high degree of control over them - full-fat devops, fully understood, makes an awful lot of sense. It would be rather silly for Facebook to have a Facebook Development Team cutting conventional releases of the Facebook Software, and an entirely separate ops team deploying and maintaining a Facebook Deployment using the Facebook Software. *It's all one thing*.
I think a lot of the cognitive dissonance and misunderstanding comes from people working in very different contexts not recognizing that that's what they're doing. You can't really reasonably apply the full set of devops practices if you're not working for Facebook but for BobCorp, where you deal with those 50,000 customer admins of BobSoft deployments, because *you at BobCorp don't actually do the 'ops' part*. Your customers do. So if this is your situation, naturally devops is going to seem like bullshit to you.
Then there's the more complex cases - like maybe BobCorp has its own internal deployment of BobSoft. Should BobCorp follow devops principles for its own deployment, but also have a process for cutting releases and supporting external customers with conventional releases? Or should it treat its own internal deployment as just another customer?
Bottom line, devops only really works/makes sense when there can be a single process with control over all the significant deployments of the software being developed, and the development of the software can be integrated into that process such that you can have a very high degree of confidence that any code which passes the commit tests can be sent out to all those significant deployments immediately and will not break anything.
How can so few people know what DevOps is? We’ve used it in banks since the late 60s and it’s been pretty stable since the 80s.
Of course, it is clear you don’t know what it is either. It has absolutely nothing to do with developers being operators. And yes there are still occasionally 4am calls, but ask the mainframe operators at banks how often that occurs.
"How can so few people know what DevOps is? We’ve used it in banks since the late 60s and it’s been pretty stable since the 80s."
Given you're literally the only person in the world who thinks DevOps has existed since the late 1960s, and the definitions you've offered for it thus far are completely at odds with those offered by any of the actual practitioners, I suspect you might just have no idea what DevOps is either.
haha What do you classify as a practitioner?
I know a lot of practitioners as well, and DevOps is the current name of the evolution of business software development, operations and process management. It's not new. We learn as we go and we improve. DevOps has nothing to do with writing software to perform the IT departments job. It has nothing to do with automating things like virtual machines and containers. It has nothing to do with any of that. It has to do with operations and development working together to ensure there is a stable and maintainable platform to build and maintain stable software against through proven test driven development techniques.
Software defined and automation and all that crap has nothing to do with DevOps. You could of course use those things as part of the DevOps process.
The goal is to not need all the IT stuff to keep things running. You should be 100% focused on information systems instead. Start with a stack and maintain the stack. A stack is not about VMs and containers. It's about a few simple things :
- Input (web server)
- Broker (what code should be run based on the input)
- Processes (the code which is run)
- Storage (SQL, NoSQL, Logging...)
There are many different ways to provide this. One solution would be for example AWS, another is Azure and Azure Stack. You can also build your own. But in reality, there are many stacks already out there and there's no value in building new ones all the time. As such, while the stack vendor may employ things like automation and kubernets and docker and such, they're irrelevant.
What we want is :
- The ability to build code
- The ability to test code
- The ability to monitor code
- The ability to work entirely transactionally
Modern DevOps environments are just a logical progression on classic mainframe development to include things like build servers, collaborative code management, revision control, etc... it's also adding an additional role which used to be entirely owned by the DBA which goes further to ensure that as the platform progresses, operations, DBA and development work as a group so that we reduce the number of surprises.
Of course, you may know more about this than me.
"I ask the developers how they are getting on with being paged at 4am to support the system."
Been there, done that. Specifically for aircraft functional tests. When the automated test fails, we aren't sure whether it is the aircraft system under test, the test hardware, software, test requirements or whatever. So everyone gets paged.
We started with a system built by our information systems people. Who couldn't be buggered to get their [censored] down to the factory when things went wrong. Worse yet, IS management was always looking for ways to export this task to someplace like India. So we (engineering) booted them out and took over their tasks. Now we had one person who would answer to the hardware/software/requirements issue. And the factory (and FAA) loved us for it.
".....When the automated test fails, we aren't sure whether it is the aircraft system under test, the test hardware, software, test requirements or whatever. So everyone gets paged....." LOL, that rings a bell! had an "agile" project where the developers had to deliver to fortnightly sprints, then they would go home on Friday evening and switch off their phones prior to the latest release being loaded into production - and falling over - at 2am Sunday morning. They simply got so far on the Friday afternoon and then couldn't be arsed to fix anything else, so simply fudged their testing to get the release out the door in the knowledge it would be Ops problem after 5pm Friday. Quality of code increased massively when I insisted ALL developers had to be available to help troubleshooting at 2am every Sunday. That was several years before "DevOps" suddenly became the fad of the week.
Old-school vendors like BMC are much worse. For example, BMC's site is a mishmash of meaningless buzzwords, all targeted towards "your DevOps team". CA Technologies, for its part, waxes lyrical about its "DevOps solutions" and how they help to "redefine culture" around DevOps. Finally IBM lumbers toward a "Cloud Garage Method".
Thanks, made my day ... BMC are really an easy target for us ;-)
Unless you have a system already in place that is not devops and that allows you to release frequently and early, test always, and have automated to hell and back, well done, you, sir (or madam) have earned the right to bash DevOps.
However, if you have not, you are like all those car manufacturers with mechanics walking miles to get nuts, bolts, screws and parts here and there in the factory laughing at Ford's assembly line.
No, you do not need paid for tools for this, you can do it yourself with FOSS.... yes, some DevOps evangelists come with their philosophy, voodoo BS and rules etc ... the thing is, the world is moving fast, your competitors are building those DEV assembly lines, streamlining development, test, and release cycles ... DevOps is a way to achieve that, you do not have to embrace the whole "philosophy" to make it work for you ... one of the central points of DevOps is: "Change is beautiful, if it makes a difference!"
Now, I mentioned dev, test, and release cycles, but you can adapt it to other areas of business .... what most C-types do not realize is that IT is not a cost center, imagine if you could streamline the period close or other financial processes ... most of the time, that will save you a lot of cash ... there are paid for solutions out there that do just that ... or imagine, SAP system copy, a bloody nightmare, get some setting wrong and you can start again ... taking the DevOps methodology, you constantly improve your processes, again, no one tells you you have to go 100% agile and have a SCRUM master, not necessarily needed, you can achieve all these goals without. It does help to start off like that, though, imho ... YMMV
"No, you do not need paid for tools for this, you can do it yourself with FOSS"
Of course you can't. Unless you're paying wedges for tools, lots and lots of consultancy and conferences (did you notice the bit at the bottom of TFA) you're not Doing It Right.
"Unless you have a system already in place that is not devops and that allows you to release frequently and early, test always, and have automated to hell and back, well done, you, sir (or madam) have earned the right to bash DevOps."
I have created 3 such systems from scratch, 2 of them well before anyone had ever uttered the word 'DevOps'. My main failing as an engineer seems therefore to be that I simply regarded that as doing my fucking job properly, when I obviously should have been inventing buzzwords and holding conferences instead.
However years of experience of development plus configuration and administration of servers with good mentoring and advice from older more experienced folk and an eagerness to learn and put in the hard graft..... well that will give the required insight. A short cut to this level that's possible via undefined hypey hype? Put me in the "totally unconvinced" category.
... and labelling it DevOps won't change that.
Shovel [redacted] as fast as possible down the continuous integration pipeline, pausing only to check it isn't toxic enough to trip the unit tests, then get your users to do your real QA, ask forgiveness rather than permission, then brag about your mean time to remediate metrics? Get the Devs to configure AWS security because Ops isn't a specialism we need any more?
Unfortunately, we know exactly what DevOps means.
"developers need to think about the stability of the product as just as important as the features"
Soooo....
It's about doing your job properly then?
You may have guessed that I'm rather cynical about this sort of stuff. Along with Agile and eXtreme (bloody stupid name). Whenever I hear any of these names I think of spotty youths who can't be bothered to actually design something right the first time round and cirtainly can't be arsed to document anything.
And even if I get over my cynicism for a moment, it all assumes that the system you're working on can tolerate a half baked broken change. I've never worked on anything that can be anything other than working perfectly. You might get away with it on faecesbook or some such but contrary to what many seem to believe, not all software is related to running a web site. And your fancy DevOps etc often doesn't work in other environments
In the interest of educating myself, can someone please explain who the "Ops" person/people are and why they might find it acceptable to be provided with (say) a super new software build from the "Dev" people that might be broken ("never mind the quality. feel the width") for a...
A/ Critical satellite comms system
B/ A heart monitor
C/ A railway signalling system
Just curious
You can add
4) Railway and Air Traffic Control Systems
I would not want to test beta software in production when mistakes could mean that planes fall out of the sky. (I have developled ATC system and the rigour of testing, testing and retesting before you get anywhere near production is just part of the culture and it seems to work)
Which leads to
5) Any safety critical system.
That takes me back to my University days, someone queried why a course in "Computer Science" was teaching "Software Engineering" (I am well aware of the vagueness of those terms in the real world, hence the inverted commas). We were told that we could be taught engineering principles in the software course, but we would be classified as scientists at the degree level because of professional bodies such as the IEEE being very protective of the term engineer.
Microsoft hit the same thing with the original MCSE certification hence why it's now Solutions Expert rather than Systems Engineer.
"it took me awhile to stop laughing at “engineer” as a term for a programmer, apparently it was because it “sounded better”"
I'm old enough to remember when "computer programmer" and "software engineer" were different jobs with precise definitions. I guess those days are long gone.
”Developers?” Yeah, it took me awhile to stop laughing at “engineer” as a term for a programmer, apparently it was because it “sounded better”. Haha, kids hey...
Wrong, as one who has worked as a software engineer we worked in a engineering environment along side the electrical, hardware and mechanical engineers on industrial process control systems. We used exactly the same processes and discipline as all the other engineers.
We needed to, our software was controlling some extremely expensive, dangerous plant.
Good article, seriously. However, half of this is mildly amusing -- you decide which half
That mindset involves a collaborative approach whereby operations folks trust product developers to deploy code, and product developers neither understand nor trust the way operations needs code deployed.
This post has been deleted by its author
To remove System Administrators and have Developers take over and be responsible for the security and integrity of the System that they use for development.
Since DevOps became a "Thing" System Security has increased, data theft has been reduced to almost zero and no one has accidentally left anything open and available to the public on the "Cloud".
No, I am not being sarcastic. If I have negative thoughts about popular trends and catch phrases in IT then I will be deemed negative and bring "negativity" down on the whole workplace, and that is worse than setting my desk on fire. So I am very optimistic about DevOps.
You can't buy or hire a mindset
Oh, that is good, for surely such would be a fraudulent sale.
Do any who would not be bothered to comment here, doubt all prime and any sub-prime mindsets are malleable, and can be easily manipulated and better beta micro/macro managed to server a cause with altogether quite different charted directions and which would be fully in the wish and command and control of A.N.Others?
When I hear DevOps, Agile, etc. I wonder if the shills have ever worked on a real system. To be a good developer, tester, system admin, etc. takes a specific set of skills that do not overlap that much with the others. Expecting someone to good at all is a fool's errand.
My teams role involves design, estimation, testing & development environment config and running support, recoveries, production config and implementation support, and system configuration. We have continued to develop a lot of semi or fully automated process to make it easier, quicker and better quality. We understand support each other out of necessity to reduce the stress, 'try' to keep people off our backs, with bureaucracy doing it's best to hinder at every stage. We have to evolve, you can't keep still because nothing and nobody else does.
Now with all this back-ground you might think it would qualify us somewhat to contribute to ideas and discussions (even peripherally) around 'DevOps' given that it seems to roughly fit how it is described? Well you'd be wrong it seems. Since the Agileisters and DevOps mania has invaded we've been sharp elbowed and talked over or totally dismissed. Not because we did anything wrong or failed to deliver within the tight parameters we work within. It seems more that it's because we don't speak their smug condescending 'inclusive' (except us) language which they endlessly foist upon us. We don't tremble like breathlessly excited children and wet ourselves every time a new Agile or DevOps 'bible' book hits the shelf, or some LeanAgileScrumDevOps 'guru' gives yet another presentation.
Now, all the chancers are jumping in, being given massive budgets to buy off the shelf solutions for processes we had to painfully develop ourselves because there was 'no budget, we're cost cutting'' whenever we asked. You realise there is an entirely parallel operation evolving that is the favoured one, while the yours is left to whither. You see endless rounds of conferences you're not invited too, and nauseating self promotion from the talking heads and their sycophantic side-kicks. You see wild often unfounded optimism all around, like protesters in front of the tanks in Tianamen Square.
The chancers, despite these canned solutions manage to often make a mess of it because of lack of experience, and the fact they never ask for advice at the early stages where deep knowledge helps embedding of standards that will set you up right for all that follows. Oh no, they want all the glory for themselves. 'I have my new 4x4 and I know how to mount a kerb thank you very much, I'm the expert here'. 'Mind the people and bollards though' you say as they accelerate on. Regularly you find they're on your shoulder all friendly for a 'minute' (which often becomes a considerable amount of effort), wanting you to help when they're floundering, even if you're working your bollocks off to support stuff that is actually working. ('Yes you're busy with that old stuff, but MY stuff is so much more important'). There will be no mention of your contribution to fixing it. Ever. But if you don't help, you'll marked down as 'negative', 'not supportive' and even further side-lined, if that is possible.
Eventually the parasite will consume the host, and find they have rely upon themselves, suffering the consequences of whatever they created, good or bad. In later years the ones that actually stay will become disillusioned as they're no longer the bright young things getting all the attention because the 'next best thing' will appear. They will then be at my paragraph two above. .
Of course the more 'Agile' parasites will have fled the ailing host well before this. They always do.They leave well sated, looking up at the maggots scrotum as they pass to a new host and start again.
My experiences echoes yours. I asked in an earlier comment what DevOps means, and I mean it as a serious question, not snark. Every answer I've gotten confuses me, because they are either descriptions of the same end goals as good engineering shops have always had, or are descriptions of general workflows that are the same as good engineering shops have always had, or are descriptions of specific tools and specific methodologies.
So, naturally, I think "DevOps" must mean specific tools and methodologies as those are the only things that are different from traditional practice. But this article is saying no, that's not right, it's a mindset (which is no different than the mindset good engineering shops have always had).
So I don't know what DevOps means, unless it means nothing more than "good engineering practices", in which case it's a meaningless marketing phrase.
UPDATE:
as predicted, our king parasite has recently exited its host, squeezing out below the maggots scrotum, dribbling the same narcotic trail to it's new host.
What a fucking surprise. Much easier to suck on a new, full blooded living specimen than a half coagulated rotten carcass. I'd say good luck, to the new host. Keep a few bags of blood in the freezer.
You might sense a tinge of negativity here. Well WTF. Still endeavoring to deliver, and evolve, but the zombies are at the door.
Scrumban
Now THAT made me laugh. Because SCRUM or Kanban weren't good enough. We must combine them! Please tell me it was a joke?
What really gets my goat here in the comments are the developers looking down their noses at ops guys (like myself) as if what we do isn't just as important or necessary as the code that gets written. If I had a dollar for every developer who was as clueless about systems integration as I am about programming in C++, I'd be retired. You can't have one without the other no matter how you slice it. Put it in AWS or Azure, sure. but there are still highly skilled technicians keeping things going on the back end so that your code has a place to live.
As to the fellow who mentioned VMs towards the top. The reason VMs are around is because the hardware that we use today is so undersubscribed that it made sense to abstract it out. It isn't because of the laundry list of ignorance you mentioned.
A DevOps team fills the unquantified void between normal Software Engineers and remotely managed cloud services. It's process management with some pseudo-technical work. It means that a DevOps team can claim they need a "Cloud DBA" then hire somebody who can read SQL, write up some policies, and mis-quote Stack Overflow. They can command junior Engineers to define new API wrappers for public standardized tools and then say they're API architects protecting internal standards. They can re-configure cloud SCM tools then claim they're in charge of the code quality process. There's no limit to how big a DevOps team can grow if there's no definition of what it should do.
Back in the 80s a small group of us handled development and system management. We had to do it all because at that time we were the only people in the business who knew this strange Unix and RDBMS stuff. The tools needed were part of the OS and RDBMS packages. Because we handled it as a whole we knew not to write something we couldn't support and providing support kept us in touch with what the business needed written.
We didn't have a special name for it. It was just what we did.
Now, not only is everything old new again, it also has to have a special name, lots of tools and courses and all the rest of it.
Not to slight "DevOps" but it's another method, style or approach (possibly perfectly valid) that comes under the general heading "once and future doing it wrong." DO possibly especially stands out as something that would have been considered extra screamingly incorrect not so long ago. Will its stock sink so low as to regain the name "chaos?"
Most of this churning and reflux is really about perfecting human nature. Good luck!
I'm the problem? Sure. I'm the guy that gets glared at for suggesting that there is a better way to work than manually provisioning Linux boxes, saying that it will take effort, new procedures, education, and may incur some cost in the short term.
Mentions of snake oil, and a some of it is; It takes a shift in the way more than just the technology part of a company is prepared to work, and selling that upstairs is hard.
It's definitely about relationships, no doubt. For the last couple of decades there has been a relentless push to create 'silos' which has destroyed many generalists that could understand the bigger picture and would have good networks in business and technology to understand and support the aspirations of both. I was quite heavily involved in Storage, System programming, CICS, DB2, Security, Disaster Recovery, scheduling, Operations and working with Developers in design and testing who were happy to share the business requirements to understand what technology could offer. Most of those applications are still key to the business and are very functional and solid platforms. As each area became more silo'd this sort of relationship gradually broke down because each became some ladder climbers little fiefdom. It's really dysfunctional, and kills any dynamism around making changes or innovating because the isolation means not understanding each other or even worse being pitted against each in a blame culture. This has put the whole industry into a kind of hiatus in a lot of ways, and these 'new' developments seem to be just a way to build connected teams again. That is a good thing, I'm fully for that and it holds a lot of promise. But when the 'team' is split over large geographical areas of different cultures it really is pushing shit uphill with a toothpick. Then throw in all the Outsourcing companies with their own agenda's, the Cloud providers, the internal politics. It's a pretty toxic mix really and needs some very clever and charismatic leaders to make it work, even partially. A good place to start is trust, and that is a very rare commodity, especially when people are not being given a straight story and living with precarious job security. It's a real 'long run' proposition, 5 to 10 years depending on the organisation, and there'll be a shit load of carnage on the way. Whether a Phoenix arises out of this or some overweight chicken with three feet, no beak and carrying a shed load of anti-biotic resistant bacteria emerges I don't know.
If you look at the DevOps jobs on the various recruitment sites, they do seem to be operations plus git. So we have infrastructure as code which can be versioned. And maybe DevOps is development techniques applied to operations.
But, like the author, I thought DevOps was supposed to remove silos and encourage development and operations to work together. And no one seems to look after development tools now and work with developers; that has been taken on by operations and sysadmins. Which is a mistake because the culture is different. Operations is more cautious, quite rightly - this is production with the possibility of reputational loss. Development can be more experimental in things.
So, I do wonder if DevOps is actually DevOps in 90% of the roles advertised.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
