The first thing you’ll likely hear about moving to DevOps is that it’s not about specific tools or technologies, but about “culture.”
and talking total bollocks...
You’ve almost certainly heard about DevOps and the fact there’s a skills shortage. One study by data virtualisation specialist Delphix reckoned the most implemented DevOps initiatives include virtual databases, agile data masking and continuous deployment. That's opportunity, right? If you want to muscle in on the DevOps …
Have an upvote
' Ruby, Python or Go' Ok, so I've heard of Ruby, can use Python - but isn't 'Go' an ancient game?
'Chef, Puppet and Ansible' Ainsley Harriot? Sooty? wtf???
'Docker, Kubernetes, Nomand' ....
The problem with IT today is finding names for things that actually mean something useful or indicative of what it is. So many names of things in IT are now so separated from the thing itself they have no useful meaning
Go is Google's take on C, because apparently there weren't enough versions and derivatives of C already. Just like every other 'new' C, it's apparently intended to improve clarity and productivity, because nothing makes programming faster and more comprehensible than needing to learn yet another new language that's confusingly close to, but not mutually intelligible with, the last one your learned, and having to do this every 5 years.
This has been bugging me, so I checked:
Bismarck never said that.
It's actually a line from a play by Hanns Johst. The play is called Schlageter, and Johst wrote it in 1933 to celebrate Hitler being appointed Reichskanzler. Which may explain why this quote is sometimes attibuted to Hermann Göring or Joseph Goebbels.
So yeah, maybe a little consideration about at which time, place and context quoting this is called for.
The only connection to Bismarck I can see is that Bismarck also held the position of Reichskanzler, but this was from 1871 to 1890.
EDIT : Quentin North beat me to it! Have an upvote, Quentin, but I think I won't include the tradtional pint icon on this one.
The phrase is an often-mistranslated quotation commonly attributed to Hermann Göring -- "When I hear the word 'culture', that's when I reach for my revolver" -- the actual quote is "Wenn ich Kultur höre ... entsichere ich meinen Browning!" This translates as: "Whenever I hear [the word] 'culture'... I remove the safety from my Browning!" In fact, it is a line uttered by the character Thiemann in Act 1, Scene 1 of the play Schlageter, written by Hanns Johst.
DevOps just means the IT general practitioner. The jack of all trades who gets the whole thing working and finds where it's broken. I think I've been doing DevOps for 25 years.
PS. I think the article missed out the word 'holistic'. I'm sure holistic should be very important for DevOps
Indeed. This whole article is just an official announcement to learn the lingo and what the dance steps are.
Sysadmin who is supposed to be able to code ? I don't know one who doesn't, personally. Nor do I know any sysadmin worth a damn who isn't fully aware of what is running on his network and how it works - well enough to fix issues most of the time, that is.
For me this article is a confirmation : DevOps is just the new moniker for what competent people have been doing since IT was birthed.
"Sysadmin who is supposed to be able to code ? I don't know one who doesn't, personally."
Well, just as there's different levels of sys admin (knowing how to edit /etc/hosts vs rebuilding a kernel) there are different levels of coding. Most sysadmins can write a shell or python script to do some job control but I wouldn't trust many of them to implement a B+ tree library in C.
I wouldn't trust many developers I know to write a a B+ tree library in C. But then this shows a flawed mindset; why not use one of the pre-existing B+ tree libraries?
There are different levels of coding with developers too, you see. I know sysadmins that code better than a good proportion of developers.
"I wouldn't trust many developers I know to write a a B+ tree library in C. But then this shows a flawed mindset; why not use one of the pre-existing B+ tree libraries?"
If a developer couldn't write such a library I wouldn't count them as particularly good. And as for using libraries - fine for 99% of cases but there are always edge cases that need some internal tweek that would be hard to do with a library.
"Most sysadmins can write a shell or python script to do some job control but I wouldn't trust many of them to implement a B+ tree library in C."
And I think that highlights a good point, already touched-on but worth noting: every good Sysadmin I know is able to script pretty well, often in multiple languages both old and new.
But none (and I'll include myself among them) would call themselves a "programmer". None would be able (or even want) to code up a new application in C, at least not without a lot of effort and learning.
To my mind, Sysadmins script stuff to remove repetition, solve a problem, maybe even provide a tool or utility that will make a task easier for themselves and other systems types. Programmers do that kind of thing too, but tend to write applications for consumption by end-users, if not sales & marketing and ultimately, paying customers.
It's not an absolute line of course; I've also known Sysadmins who coded up nice web apps for the whole department to use, and DB programs that finance relied on. As OP said, those tend to be more rare, from the skillset standpoint as well as what they'd rather be working on anyway.
"But none (and I'll include myself among them) would call themselves a "programmer". "
This, really. Have an upvote.
If you think knowing some basic programming makes you a programmer, then you're kinda missing the point. Programmers don't go off and spend 4 or 5 years at uni just learning basic syntax and vocabulary. There's a lot of theory work in programming - optimization, security stuff, understanding how threading works etc - which a sysadmin I don't need to know in detail, but a programmer would.
Likewise, there's a lot of specific knowledge in systems admin work that a programmer doesn't need to know about. Network security alone has a pathway of certs that is more taxing than a 5-year degree. A real understanding of just the MS network infrastructure takes years, let alone storage architectures or networking. These are areas where only a few programmers (usually those directly involved in writing for exactly software directly related to these things) have more than a cursory understanding.
"DevOps just means the IT general practitioner."
Not really, since 'Devops' presently doesn't mean a damn thing tbh.
My official job title is 'ICT Support and Development Engineer", which means that yes, I'm the 'general IT practitioner' that you refer to; I write some basic programs, do a lot of automation, but also handle the entire operations admin work on the netapps, Vsphere and the entire MS stack. Also, because my job title implies I'm both a support dude (sysadmin) ad a development dude (programmer), I'm getting a massive number of calls from recruiters offering devops positions right now. And do you know what these jobs have in common?
Literally nothing. Some are basically Cloud Architect jobs. Others are bog-standard sysadmin work; another was actually fairly obviously just a Java dev job; yet another is what we would've called an application manager 5 years ago, another is really a DBA. A Devops job spec is a complete black box; it could contain literally anything. It's like loading a shotgun full of IT terms and just firing it at a target, and anything that lands in the central 2 rings is part of the spec.
This is why it initially appears to be a general IT practitioner's job; it's so absurdly general that you can jam almost anything into Devops. It homogenizes all IT job descriptions into either 'Engineer' or 'Manager' without making any attempt to distinguish between skill and techs at all. And that's going to be a huge problem after a couple of years, when everyone is calling themselves a Devops Engineer but they have no skills in common at all - no more 'linux systems administrator' or 'Java front-end developer', both are now 'devops engineers' with no alteration to their skillset whatsoever.
IT's basically just part of the ongoing progression of the whole of Western civilization toward just having two job titles - "master" and "servant".
>And do you know what these jobs have in common?
DevOps means "Talks to computers (and sometimes they talk back.)"
It's like being a horse trainer for things with blinky lights.
Specifics? Just keep it working, there's a good chap, so I don't have to worry about it at the golf course.
"The jack of all trades who gets the whole thing working and finds where it's broken. "
Indeed. It is most amusing that the breadth and depth of skills needed for that role were largely lost when many Baby Boomers were sidelined and then retired. They were told that "productisation" was the new skill - requiring specialisation in gaining and maintaining manufacturer's certification.
Youngsters, no matter how eager initially, soon learned that specialisation was the way to career and salary progression. The old fundi in the corner was largely ignored ...until there was a technical crisis when the specialists were all saying "no problem in my area".
No one can hope to be competent in all things. They need to be able to assimilate what specialists are saying - and translate that for other specialists. That needs breadth and depth of previous experience - and that doesn't come cheap in the number of hours spent "playing". You can't send people on courses when the need arises - and hope they will be able to think laterally.
Most people can code - most people can't write good software. A common problem is that they don't think defensively - the necessary contingency handling is often 80% of the task. They also have single track minds - rarely looking beyond their limited perspective at lateral possibilities - or timing races..
So the requirements are to be super lovely people with a super broad range of skills and super flexibility to learn even more skills without needing to take a break? I think I met one of those once, about 20 years ago. And of course we are all large corporates because anyone smaller doesn't have the luxury of being able to randomly swap around the Dev and Ops staff just for the 'broadening of experience'. Normally you get given a pile of books ans told "well volunteered, you get to be the standby, learn this in your own time".
Oh, and "hampering after"? Really? Are you sending out a large basket to capture people and wrap them in a gingham picnic blanket or did you mean "hankering"?
p.s. as remarked above 'DevOps' does have similarities to an IT GP (good name!) though the IT-GP would tend to be the solo small company tech person rather than this new desire for a team of randomly interchangeable bricks in the wall, sorry I mean valuable tech personnel...
" Isn't there some kind of axiom about "Jack of all trades"? "
yes there is but in my experience it's almost universally false in computing. Someone who can turn their hand to many different things is usually better at any one of them than someone who can only do that one thing.
"yes there is but in my experience it's almost universally false in computing. "
And my experience is the complete opposite. To become really good at something you have to practice it and practice precludes doing 101 different tasks. f I want someone to implement Voronoi diagram algorithm in C++ I need someone who's an expert in their field and on the ball - not some guy who's done a bit of everything but not a large amount of anything and might be able to knock together a "hello world" program given a day or 2.
@Tim 11 and boltar: I suspect that you're both right, for a given value of right. For the environment I'm in, as there are fewer than 10 of us, a JOAT is a better call much of the time. All of us have areas where our knowledge base is a little more developed but none of us are specialists, we hire those in for a given job when required. YMMV but that seems to work for the numbers we have. I imagine that in a 30 or 40 strong team it would be the opposite case.
Re the quote, it always irks me that people only mention the first couplet as it's then completely out of context:
"Jack of all trades, master of none, though oftentimes better than master of one."
You are of course right, but then you would try not to ask a generalist to do what is clearly a specialised task, even if he or she could probably learn it, given time. Unless of course said specialist was unavailable, and there was no other choice, no time to find specialist (or no budget).
Many "IT generalists" (I hate that term) can learn new tasks and still do tasks that give many "boxed-in" specialists the heebie-jeebies:
Source, install and configure the tools, platforms, hardware
Help debug and set up software test environments,
Troubleshoot performance issues.
Ensure and monitor that sufficient resources are available for those precious C++ apps.
Build VMs and set up cloudy systems and networks
Write test and user docs,
Learn new things, as required
Relearn old forgotten things, as required.
Script much of the above.
Deal effectively with users and PHBs
Maintain project plans
yada, yada, yada
Specialists will always need generalists (and vice versa) to get projects done.
Today, there is very little room left for caste-driven separation within IT teams (devs vs sysadmins).
It just slows things down and makes grumpy old farts look even grumpier and older.
Do what you are good at and learn as much as you can from people with specific skills you don't have. You too can become a gifted "generalist" and start earning those big bucks everyone is talking about.
At the end of the day, it is still about experience and adaptability and always has been.
Most projects don't actually require rocket scientist skills anymore and if they do, there will soon be an app for it.
So you can call me a devop if you like, ..... just don't call me late for dinner
Theres some areas where the specialist shows their worth, e.g. if you are working with a very large database backend e.g. petabyte level with high concurrency, lots of transactions etc, then you get the DB specialist in to configure the servers, tweak the DB design and to help with the query strategies to use (not just the obvious such as appropriate use (lets assume a SQL DB in this e.g.) of prepared statements but using their knowledge to tweak tables, indexes, SQL syntax to get the best performance - e.g. to get certain data out there's often many possible ways you could write queries, your proper expert on that DB knows which one(s) are likely best candidates & which will crawl.
Using the DB expert suggestions avoids the hassle of having to trial all the alternatives and run benchmarking tests, instead you can just focus on testing a small subset of possibilities that the expert has picked out.
The sort of bad design, flawed queries, unnoticed deadlocks people often get away with on small DB systems are killers when things are scaled up big time.
N.B. Not talking as the DB expert but as someone who has collaborated with them to deliver solutions that make good use of the particular DB backend used.
I also fit the JOAT description - or as someone else described me, "Designated Grown-Up for Projects that Need One".
Someone else said "You're like that five-year-old kid that every Evil Overlord should employ, to make sure that their plans don't have inherent flaws".
I may not have the depth of knowledge that "Mission Specialists" bring to a team, but a broad overview means that I tend to spot flaws they don't. It also means that if a project is missing vital knowledge or experience, I know who to approach to fix that.
Bloody hell, does that mean I've also been doing DevOps most of my career ? Ewww.
Because it's not really a thing. It's some consultant-led business bullshit wrapped around 'Don't master any trades, fudge by in all'. This is so the consultants can sell the actual expertise when it turns out that a tier 1 helpdesk guy can't fix a timing flaw in your message queue-oriented Oracle system.
It'll pass, and it'll be repainted and repackaged - fashions shift. You'll do more or less the same whilst some higher-ups scurry about with meaningless graphs they can't interpret on big screens. It always happens. The wheels keep turning. Nothing will improve, things will change. What's centralised will diversify and vice versa.
If you want to get ahead in DevOps, realise that you'll do the same thing, people paid more than you won't implement anything properly and call in consultants paid more than you. You'll get bollocked for things you don't understand but which were dumped on you, but won't get fired as whoever is bollocking you realises they'll look like an idiot too. Young people who say the right words to the numpties will get promoted ahead of you, but then find out they know squat about squat and you'll end up fixing their stuff. However, you'll sacrifice chickens every morning, or bow to the 60" monitor with meaningless graphs, or whatever the superstition of the day is.
If you want to THRIVE in DevOps, get onto the reporting TV system stuff and make it show pretty graphs. Start off with random data that looks good and award yourself points for every month it goes unnoticed.
Sounds like server admin 101. Run tail -f on the server log so it actually appears you are doing something, screw with the log in script so the MFC encounters the random core dump (yeah, that's listed under RFC whatever, schedule us some over time and we will get it fixed)
And of course. . .
Keep the cattle prod charged.
Biting the hand that feeds IT © 1998–2019