Why Yes?
How many time did we heard "can we do this?" and the answer was "why not?"... And then usually what follows is a Michael Bay-esque scene, with the only problem that, instead of being at a safe distance watching the show with popcorn in hand, you're in the middle of the disaster area dodging wrecks, bullets, explosions and fire (and there isn't a single hot woman in sight).
And everytime (after having left the disaster zone and in a quasi-safe spot) I think why the fuck instead of answering "why not" didn't we answered "why yes?".
That posed in a less-crytpic way it become: why the fuck are we supposed to do "that" thing? Which advantages (if any) does it produce? And pay attention please, is not that I am against improvement or changes or progress, is just that in many, too many cases the "thing" in question is implemented without a real reason. It is done because somebody had the idea and the answer to the question was "why not" instead of "what the fuck are you talking about".
The problem is that when the question is posed in many cases everybody around has no real clue of what is the "thing" in question, if it is good or bad or has any reason to exists and they prefer to err on the side of "do not show that you have no clue", if everybody say "ok" then nobody can be singled out when the result is a total (or partial) disaster. When everybody is guilty, nobody is. Except the scapegoat of course, but that is quickly replaced.
And with this, we're talking about $sgobblet, another company that we found in our pool of customers after the last round of acquisitions.
Their problem was that they had no problem. And when there are no problems to be solved, a company that does IT has the moral duty to create some (a dozen or so would be good) to persuade the moneyholder to use some of the money. And obviously the ex-company had done exactly so.
I've alredy told a bit about the 'problems' that the so-called "dev-ops" method can create, methodology that consist in always using scripts to configure or change the configuration of any system, regardless. And you're probably thinking "and where is the problem with that?".
Now, I am a script-fan, if I have to do a thing 'n' times I'll try to automate the shit out of it, but if the probability for repeat is low, and the time required to automate the thing is possibly a lot, I prefer to go with the manual mode.
Let's be frank: if you have 'n' (with 'n' >= 2) machines that are basically IDENTICAL and must perform the very same function, with the same software and the same configuration, then DevOps is ok. But if what you got is a rag-tag collection of servers with hundreds of "special single snowflakes", each one unique and a world apart, the you'll end up managing several hundreds of scripts, each one of them has to be specifically tailored to its personal destination and if you run them on the wrong machine you're screwed because there is no way to figure out which one is which.
Unfortunately, somebody only watched the powerpoint presentation without reading the documentation and got convinced that DevOps is the best thing after sliced bread and insists in using that approach even when it has no reason to be.
And it was so that UL from $sgoblet showed up a nice day to talk about their "new" mail environment.
UL - ...and thanks to the selfresizingselfregulatingwithsidedishofshrimp as explained in the presentation if there are problems we simply restart the whole shebang and all the servers are rebuilt with all the configuration taken from the repository that...blah blah blah yeada yada yada. What do you think?
Me - And why all this?
UL - What do you mean?
Me - Yes, why are you doing all this?
UL - ...to rebuild the whole environent.
Me - And why do you want to "rebuild" the whole environment? Isn't not enough to "build" it once?
UL - Well, no, because... disaster...
Me - What disaster?
UL - The one that could happen.
Me - Ok, let see, What you want to do is to put together a system to manage e-mail for your office, that is something like 20 peoples and has to handle... don't know, an hundred mail a day maybe? All this is handled by ONE server for smtp, ONE server for IMAP/POP and ONE server for webmail. That's it. What you need is a good backup of the mailboxes ('cause you don't want to rebuild the mailboxes from scratch) and the configuration.
UL - And using the script we can rebuild everything and get the structure back.
Me - And when are you going to run this thing?
UL - When we have a problem.
Me - And what kind of problem should be to cause the full rebuild of the entire system?
UL - Well... for example an error in the configuration...
Me - If you rebuild the system with the same configuration you get the error back.
UL - Hemmm no the configuration need to be tested first.
Me - So how do you test it?
UL - Well testing it and if it works you copy it into the repository.
Me - And what guarantee you that the configuration is actually copied into the repository?
UL - ...we could copy it into automatically every 10 minutes or so...
Me - So if the configuration is wrong it will get copied into the repo anyway and you get the same error as before.
UL - Hemmm...
Me - My point is that some things have to be done manually and after a while, the version in the repository and the version that is actually in use began to differ and there is no real way to reconcile the two. I've seen that happens way too many times. At that point you'll have to pick which one you want to keep and throw away the other.
UL - But...
Me - My question still stand: Why do you want to do all this?
UL - ...in case of a disaster...
Me - And how many time per day do you expect a disaster?
UL - Well, never actually but...
Me - So you want to build an ultra-complex system that require strict adherence to a manual procedure to be able to sustain itself for an eventuality that you hope will never happens, and in case it happens you still need a full backup to be able to restore the whole thing?
UL - Hemmm... yes.
Me - And why yes?
UL - What do you mean?
Me - You heard my critique, now leave the 'disaster' bit alone because it's the wrong answer, so why do you want to build tha thing?
...I'm still waiting for an answer.
Davide
04/10/2019 11:47
