Tales from the Machine Room

Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Login/Register

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.

04/10/2019 11:47

Previous Next

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

9 messages post new
Manuel By Manuel - posted 28/10/2019 12:30 - reply

La magnificenza del dev-ops inutile. Buon inizio settimana!

::: meksONE :::

Martillo By Martillo - posted 28/10/2019 16:41 - reply

La domanda è in generale: ma serve 'sto dev-ooooops?


Davide Bianchi@ Martillo By Davide Bianchi - posted 29/10/2019 13:36 - reply

La domanda è in generale: ma serve 'sto dev-ooooops?

E la risposta e', come sempre, DIPENDE...


Davide Bianchi

Messer Franz By Messer Franz - posted 29/10/2019 09:42 - reply

In genere, se dove lavoravo ero tra quelli che "discutevano della fattibilità di un progetto" e capivo che la realizzazione sarebbe stata sulle mie spalle, mi mostravo tutto gasato ed ottimista ( sennò nemmeno ti ascoltano, perchè chi dice che nel mondo reale gli inconvenienti accadono è un gufo, non uno che cerca di evitare disastri ) e iniziavo ad elencare cose necessarie al programma ( o buttate là alla caXXo, tanto non ne capivano mai niente ) e dire frasi del tipo "...poi questa cosa la si può fare molto bene con la tecnologia XXX, che costa parecchio, ma vale i soldi che chiedono...e quest'altro non ci vuole molto per farlo, anche se bisgona vedere dopo quanto ci viene inviata la licenza YYY, ma penso sarà in fretta, voglio dire, con quello che costa ci si aspetta un servizio adeguatamente efficiente..." ; dopo 10 minuti di "spesaspesaspesa" si passava sempre a "certo, bisogna valutare bene la cosa, visti i capitali da investire", frase cui si attaccavano come cozze allo scoglio e il progetto finiva nel dimenticatoio.

ps: bello quando ti fanno fare uno script per un sistema unico nell'intera galassia e giustificano la cosa con "lo mettiamo nel repository, che magari poi ci servirà di nuovo" e lo salvano come file 36uh5_uk47536weh.zip senza documentazione...

Messer Franz

Anonymous coward By Anonymous coward - posted 29/10/2019 10:05 - reply

>Il problema di sgambini e' che non avevano nessun problema.

mo stavo strozzando dal ridere!

>perche' vorreste fare questa roba?

semplice: hanno letto dal barbiere  he devops e' FIGO e loro lo vogliono.

Ogni X anni esce una nuova CAGATA che per vari motivi (principalemente, un nome figo scelto dai geni del marcketing) diventa "bleeding edge" (altro termine figo che pero' non conta un CAZZO) e tutti i dementi lo volgiono.


Anonymous coward

Antonio Pennino By Antonio Pennino - posted 29/10/2019 13:05 - reply

Li hai convinti? Probabilmente no...

Antonio Pennino

Anonymous coward By Anonymous coward - posted 29/10/2019 19:39 - reply

Perchè un UL vuole fare qualcosa?

Ovviamente perchè la farà un altro, che si prenderà eventuali colpe, mentre l'UL si prenderà il budget, che non andrà ad un UL suo concorrente.

Serve? È il modo giusto? Queste sono considerazioni che non interessano un UL, figurarsi un SL o SUSL... fino a che ci sono soldi da spendere.

Anonymous coward

gabriel By gabriel - posted 29/10/2019 19:50 - reply

ciao davide,

secondo me la risposta non la vuoi sapere perchè ti butteresti dal quinto piano una volta saputa.


Guido By Guido - posted 04/11/2019 13:28 - reply

Vorrei piu' gente che ragiona come te...

who uses Debian learns Debian but who uses Slackware learns Linux

9 messages post new

Previous Next

This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.

This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project
Powered By Gojira