
Is there trouble brewing in the land of DevOps? - EwanToo
http://blog.gardeviance.org/2015/08/is-there-trouble-brewing-in-land-of.html?m=1
======
dkarapetyan
Nothing new here really. Shitty architecture and practices are shitty
architecture and practices. If you're not disciplined enough about how you
package, deploy, and manage the lifecycle of your software then putting the
blame on technology X or methodology Y will not change anything. The root
cause of the problem is never the technology really. The root cause is almost
always the human processes that lead to creating poorly documented and buggy
software and sprinkling magic DevOps, agile, or whatever dust over things
doesn't make a difference no matter how much advocates would like to believe
otherwise.

A concrete example is that even before containers I saw plenty of binaries
that were magical black boxes that no one knew how to re-create from source
anymore, well not without some human intervention anyway by poking and
prodding things at certain points during the compilation process. So to say
containers and microservices are making things worse or better misses the
mark. Things are the same as they've ever been and the more disciplined
software shops are still doing just fine. The less disciplined software shops
are still finding plenty of ways to blow off their feet (referencing a quote
about C++). DevOps, agile, lean, six sigma, or any other methodology has
nothing to do with it.

~~~
bbrazil
A phenomenon I've noticed is some believing that containers solves
configuration management. It's true that containers through being immutable
means you don't have to worry about what cruft has built up from previous
changes (which is a big win). That still leaves you with the core problem of
how you manage your configs.

The core of configuration management is a) how you express the state of the
world and b) how you move from state to state safely, with potentially
hundreds of changes in flight at once. For the former I'm excited about
projects like
[https://github.com/apmasell/flabbergast](https://github.com/apmasell/flabbergast),
and the latter is mostly a matter of breaking rollouts into individually
rollbackable changes combined with good policy.

~~~
jpgvm
Thing is containers themselves are not immutable. One implementation (Docker)
enforces this but it's not so when using raw namespaces/cgroups, systemd-
nspawn or lxc/lxd etc.

IMO it's not tools that are the problem but a lack of deep understanding. A
lot of people practicing "DevOps" lack the raw knowledge.

~~~
fapjacks
This I can agree with. It almost seems as though this new kind of "DevOps" (to
use the same air-quoted term as you) is being used as a band-aid for companies
to be able to accomplish traditional sysadmin goals, without having to pay for
people with depth of knowledge. Things like Docker and cloud services make it
easy to think that one does not need the knowledge a sysadmin needed to have
ten years ago, but that's not true. What's happened is that applications like
Docker have obscured the need for that knowledge by making things easier to
accomplish. And then when those companies run into problems, nobody on the
tech team knows how to put out the fire. Now, I suppose that's not such a bad
thing if you're outsourcing all that work to a cloud services provider. Then
it's a matter of opening a support ticket. But then again, you're at the mercy
of those providers. I can see why Docker is so attractive for companies, which
implies one can self-host these cloud services and save a ton of money, while
also appearing to not need that raw knowledge because of ease-of-use provided
by applications like Docker. It looks like an attractive way to cut down on
quite a lot of cost. But what happens is that the cost is actually offloaded
from needing the knowledge to build and maintain the infrastructure, and onto
the moment of failure. And the thing about that cost offloading is that this
cost could kill your business. Just picture a tech team with red status pages
and buzzing phones, but without the knowledge to dissect what's happening.
It's a ticking time bomb. Also I should mention I'm saying this as a huge,
huge fan and user of Docker, but also as someone with twenty years in the
industry, watching the "new DevOps" crowd.

------
kylequest
There's always been a gap between the devs and ops. And one of the core side
effects of this gap is the knowledge transfer problem. With the devpops
movement you have devs doing production deploys where the ops (or even other
devs) might not know exactly what's running out there:

"some IT landscapes contain components that people don't know how to recreate
especially since the person that created the component has left the company" ,
"if we consider multiple layers of microservices then it can be quite
disconcerting that some of those lower order component layers maybe in a
position that we cannot recreate".

The knowledge transfer problem between the devs and ops is not really a
technical problem. It's a human communication problem. With the new tools
(like containers and microservices) it manifests itself in a slightly
different way allowing you to deal with the communication problems further
down the line (because you can deploy a black box container without breaking
other things running on the same machine/VM), but you still need to transfer
that knowledge.

I'm curious if there's a market for tools and products that automate this
knowledge transfer...

------
stuaxo
This article was quite hard to read beyond the pretty wanky diagram:

Culture: Inertia vs Fluid / Gameable Corporate Focus: Profit / Disruption

I'm sorry, someone has been reading far too many startup articles, it's like a
parody.

------
jldugger
Buried deep within the self-fullfilling analysis, corporate buzz words, and
stale metaphors is a simple concept: the early adopters of containers
implicitly embrace NoOps, and eventually the absence of explicit dependencies
and documentation will drag organizations down.

