what the fuck is devops anyway and why should i give a shit?







W..T..F.. is this new thing they call devops? 
its even more of this absolute insanity of working endlessly
just to stay in the same place you were. keeping abreast of 
the endless churn of meaningless 'updates' and replacing
all the components that keep getting deprecated (the easy
alternative to actually fixing bugs) nevermind that theyre
full of bugs while theyre still in use.. all to
accomplish a goal that one already had accomplished 
last month, three months ago, a year ago, over and over,
but also a goal that we had solved decades ago with
simpler tools.. but hey, all the blogs say this is how we
have to do things!

At the core of this 'devops' craze there are a handful of
dogmatic rules, compliance with which in a sense comprises 
the meaning of 'devops' as a word. The main items of dogma
are, each building on the others,

first, this idea of 'continuous integration and deployment', meaning
that there is no stable software environment, rather an
endlessly re-deployed binary soup constantly being updated by
whoever and whatever modifies it. 

second, this idea that everything must run in a 'container'
on a 'cluster' in some manner 'managed' by a 'system'... which
concepts are poorly understood by these people, and which
in practice ends up being some mishmash of half-assed software
offferings that are trendy at the moment to provide more and more
layers of separation between running code and anything 'specific'
anywhere in the world. The definition of the value of the number 4
is too 'specific' and thus must be referenced from somewhere 
should we want to change it - where we reference it from is 
of courseone more of these pieces of critical 'infrastructure', which 
as a rule must originate from some san francisco startup 
made up entirely of 25 year old hipsters who spend all their time
drinking expensive coffees in absurdly decorated 'offices' which look
more like an ikea showroom. It of course , as a piece of software, itself 
must also conform to this dogma of statelessness and dependence on
external 'infrastructure' which adds more links to the chain, and they
all get extra points if they dont run anything on any computers of their
own, but instead at the very least run them 'in the cloud' or perhaps 
even dont run them at all but rather invoke them 'as a service' from
someone else's management. Moreover, as 'infrastructure' , it must
also conform to the dogma of 'continuous deployment' , so there is no
stability in these elements of 'infrastructure' either- things you depend 
on are supposed to be changed out from under you with no warning
(wait you don't read all of our commit logs? youre not agile enough!) 
and you're supposed to scramble to reconfigure or rewrite other things
(which if you're following dogma, means waving some magic wands far
far from an actual program or computer and letting subtle side-effects
percolate back) which of course also means other things you depend on 
will have to do the same before anything works again. 
but this is what they call being a 'ninja' or a 'rockstar' or some shit
like that, where you run around like an asshole trying to figure
out what the fuck just got broken and how to get your shit somehow
working again. over and over and over again. 


third, the idea that everything is temporary, and therefore must be
stateless and therefore any state (alas that there must still be some
actual state somewhere, as much as these new age nihilists would
hate to admit it!) must be hidden 'somewhere else' as much as
possible. This idea gets repeated over and over up and down the
stack, so in the end you get this horrendous chain of reference, where
half a dozen different mechanisms for _transferring_ state in a
temporary manner, get used to keep pushing the origin of any information
further and further away, and at each stage there is some opaque
synthesis going on, where it is difficult or almost impossible to
reconstruct an accurate picture of just what the hell is going on
at any point in time, or to trace a change back to which _combination_
of fragmentary snippets of information in the various scattered stores
will yield which changes in behaviour. At many stages along this chain,
one might think one has found the spot wherefrom some item of data
might be originating, that it appears in the running instance,
only to find that changing it there does nothing, it's being synthsized
from somewhere even further up the chain.

What do you actually want? a more rigorous and robust
way of developing software? 
there is no magical infrastructure which will do this for 
you. The answer there really is in the category of 
best practices and the simple tools we had decades ago were
fine for it - the real meat was always in discipline and
organization of your team. You should have been using
revision control, tests, backups, code reviews before 
committing changes, and some kind of release engineering
already.. if you needed some magical tool calling itself
'technology' to get your act in order then you were
already screwing up. 

There has never been and never will be a substitute for
actually knowing what you're doing and doing it well. No
matter how many software packages and how many management
fads come and go none of them will change this basic reality.
Though, by trying to enable people who don't
know what they're doing, to write some code, or to get
some results they don't understand, these tools might
simply make knowing what youre doing a whole lot more
of a pain in the ass by forcing arbitrary and pointless
complexity on the people who ultimately must make this
heap of junk work. Add to that the consequence of the
rest of the industry following the same fads, and you get
this neverending churn of half-finished software always
in flux, always needing attention, and a handful of smug
and dishnoest 'gurus', actually charlatans, who will sell
you the fantasy of everything ready and running at the
push of a button.

really, get over it. Institute some basic discipline
in your team, get a grip on understanding what the hell
you're doing and why you're doing it, and go back to
writing actual programs, maybe say some makefiles etc, 
producing actual binaries, with minimal dependencies
and minimum sensitivity to other peoples' shit changing 
on you unannounced, and try to regain some stability,
reliability, predictability, and reproducibility in 
your software development.




*** BONUS RANT ***

this popular piece of shit called jenkins fails one
more of the golden design principles for good software,
which is 'use human readable data formats wherever possible'..
their brilliantly bloated binary log formats make it near 
impossible to quickly just look at a log file without using 
their horrifically shitty web interface (which by the way doesnt
even work with large logs, as these modern browsers seem
to choke the hardest on plain text files! ten tabs playing video
simultaneously, no problem. a half-meg text file? browser response
lag stretches out to close to a _minute_) , and also makes
any simple machine analysis very difficult (say i want
to run a simple awk script on the log to try to analyze something)
of course there's sure to be some 'plugin' for some other heavyweight
'tool' like elasticsearch or some shit, but for fucks sake,
i wanted to just do some stats myself on this fucking log file! 
thanks again assholes!

followup: it turns out this is some dipshit programmer 
on the jenkins crew deciding to output fucking HTML color and formatting
tags for EVERY GODDAMNED LINE of the log, and this HTML then gets compressed(!)
and encoded and takes up the first 300-plus bytes of every line (where your
typical line might be 50-80 bytes long on average! only a 10x blowup in logfile
sizes!)
for fucks sake people!





This file copyright 2018 by G. Economou