
DevOops, some common anti-patterns - kiyanwang
https://hackernoon.com/devoops-some-common-anti-patterns-1850ac2f5074
======
jillesvangurp
Having ops teams around is essential in bigger companies but I've seen them
turn into disablers instead of enablers as well. The devops movement was born
out of frustration with that inertia.

I witnessed AWS creeping into Nokia ten years ago. This did not go down well
with internal ops initially. They did not realize they were part of the
problem instead of the solution. They were a huge cost bottleneck and also a
source of huge time delays and pointless bureaucracy.

Ultimately a lot of what they did stopped being a thing. Resources they
controlled (e.g. firewalls between data centers, storage clusters, vms, etc.)
were replaced by IAAS. This turned out to be magnitudes faster, cheaper, and
more reliable (e.g. storage cluster outages were a regular thing).

Small organizations don't require dedicated ops teams anymore. If (dev)ops is
done done well, ops is just not a full time job anymore. However, letting
development teams do their own ops requires hiring people with ops skills as
well as developer skills: i.e. devops people. So, not an anti pattern and it
is perfectly valid to make sure that all teams have enough ops skills in the
team. Also, these days I would expect senior developers to be not completely
helpless doing ops. I don't expect them to like it but I do expect some
rudimentary skills.

So,hiring, people with devops skills is not an anti-pattern. I'd actually
argue having an ops team at all is an anti-pattern unless you are big enough
to justify needing one. And if you don't have one, not hiring people with
relevant skills would be a big anti pattern as well.

I've been around long enough to have seen most of what ops used to be about
automated away or replaced by IAAS style deployments or otherwise no longer
relevant. IMHO this is an ongoing thing and there is still a lot of non
trivial stuff involved. A lot of time is still wasted on what is fundamentally
tedious, repetitive, and error prone business of reinventing the same wheels
over and over. It still seems way too hard to push out bog standard web
applications in a way that results in responsible deployments with all the
boxes ticked regarding security, ease of use, logging, auditing, etc. For me
devops is a necessary evil. The less time I can spend on it the better. But
the reality is that it still requires skills and time.

~~~
asdkhadsj
Out of curiosity, any tips for companies small enough to not warrant an ops
position, but also so "lean" _(read: broke)_ that we can't too heavily rely on
cloud solutions?

Ie, I advocate self hosting a lot in my ~8dev team _(in a real, 10 year old
small company)_. I advocate this, because the last company I was at was the
traditional startup and we blew tons of money on cloud solutions. Ie, if we
needed to aggregate logs, we threw everything at papertrail, rather than
managing it ourselves. This has given me a cost aversion, so I theoretically
prefer self hosting when sane. Mostly for everything but actual VMs.

With that said, a lot of self hosting leads to a lot of infra. I agree that
hiring devs who also know ops is a good way to go _(and would fit us well)_ ,
but in this scenario, do you still think it's the better/best?

 _edit_ : to be clear, I advocate using AWS/etc. I don't advocate using dozens
of SaaS options to solve our modest needs at non-modest prices. Many SaaS
solutions were designed for scales much larger than ours, self hosting seems
most apt.

~~~
eajr
(Not the OP) If cloud equates in your mind to expensive, then you were
probably using the cloud wrong. Using AWS (for example) as a data-center and
self hosting on EC2 can be pretty expensive compared to just getting a few
dedicated boxes. The point of cloud architecture with tools like terraform are
meant to be able to have resources be torn down and scaled down when they are
unnecessary. You can't scale down bare metal, and you can't scale it up either
automatically. If you have a consistent workload and know exactly what you
need on any given day/time and for any given number of clients and can predict
what you need - bare metal is honestly not a bad choice.

Edit: Just realized I didn't answer your initial question in the post: A cloud
architect, who comes from an engineering background, is more along the lines
of what you would need versus just a pure ops person. My last company was a
small company (startup mentality) and as chief architect I was able to design
our cloud architecture as well as write code on our projects when my
developers were struggling to meet deadlines.

~~~
asdkhadsj
I think there's a miscommunication here, but I probably should have said SaaS
rather than "cloud".

Ie, I don't advocate self managing hardware. That's a difficult problem, one
more cheaply and easily solved by using AWS, GC, etc. Yet, there are dozens of
SaaS options for so many little problem you could have, and they can bleed you
dry. A balance is needed.

I mentioned in my original post that I advocated self hosting _except_ for
VMs. Ie, I promote usage of AWS/etc. I just don't think we can afford
Papertrail, and the billion other SaaS pieces I used in my last company. Self
hosting has been far more scalable and cheap, due to our modest needs.

~~~
jrumbut
In the most successful of the companies of the sort you've been describing
that I've been around SaaS was kept pretty minimal. This was less a policy
than a consequence of just having *nix skills or a desire to learn. Also many
SaaSes have relatively serviceable self-hosted FOSS counterparts.

Log management in particular is really a shell script/self hosted app kind of
task, just share the money saved on Papertrail with the team and I'm sure
they'll get on board.

------
notacoward
The point about "you build it, you run it" not being sustainable really hits
home for me. On a large project, there's a fairly natural specialization along
many axes, with "deep in the guts" development vs. "close to the users" ops as
one of the more natural ones. It's definitely important for developers to get
some direct experience with operating what they produce. That's why I took my
current job instead of letting myself become one of those awful "senior
architect" types divorced from reality. Still, being on call is stressful.
That stress is even greater when it's into areas others know 10x better, or
when it interrupts progress toward the longer-term outcomes on which
developers are measured even in a "devops" culture.

Changing teams to get a break from being on call starts to seem less
disruptive than staying, and I'm sure plenty of other people where I work hit
that realization long before me. I think more of a "pair programming" approach
would often produce superior results. Two close associates don't need to know
every command-line flag and semicolon of each others' work to understand and
appreciate each other's contributions to the challenges they share.

------
thrower123
I'm not much of a fan of devops. I would really like to have an ops person who
_really_ knows what they are doing, and has that as their prime concern,
rather than having it be just one more concern tacked onto everything else
that developers already are responsible for. Specialization is dead, we just
have a bunch of generalists muddling along. Right now I'm wearing more hats
than a hat rack, between front-end, back-end, database, operations, support,
security, project management, testing, and sorta kinda managing a few junior
engineers. I can do one or two of those things well at a time, the rest I'm
just bailing water or it goes by the wayside entirely.

~~~
dijit
DevOPs is not one person doing everything, it's removing the walls between
developers and operations. Ideally you have a "devops team" consisting of devs
and ops.

But as I always say: "Devops is not a job title"[0] only cheap hiring managers
think it is.

[0]: [https://www.infoworld.com/article/3263812/devops/do-not-
hire...](https://www.infoworld.com/article/3263812/devops/do-not-hire-a-
devops-engineer.html)

------
manishsharan
Also How about using kubernetes when all you are running is a few web
applications?

~~~
place1
Is it though? Hosted k8s clusters make deploying a single app just as simple
as heroku or elasticbeanstalk, but you still have the flexibility to deploy
more. For a small team it's just as easy to setup a managed k8s cluster as it
is any other PaaS - you go though a wizard on GKE or some other provider. And
if you apps are simple then you don't need to use the complicated features of
k8s itself. 1 deployment and 1 LoadBalanced service is simple enough for most
Ruby, Python, C#, Java monolith apps to be off to the races.

I'm not trying to argue that it's a silver bullet but there's a bit of circle
jerk over k8s complexity when it's not that hard.

------
mtberatwork
> Thinking, you build it, you run it, will work in the long term

This is basically the "hit-by-a-bus" scenario and it applies to pretty much
anything in which you have a single point of failure in terms of manpower, not
just in-house software. e.g. What happens when the engineer who installed your
open-source solutions leaves? Who is left to support updates, migrations, etc?
The solution to this is of course is to staff correctly...so that you don't
have a single engineer building out an entire code base or system that your
company heavily relies on.

~~~
spdionis
In a way, after 3-4 years, there isn't much difference whether you have to
update your self-hosted service, or the SaaS you're using is finally removing
the functionality you rely on after having deprecated it 2 years earlier.

The only difference is server resource management, which is not much effort if
automated correctly, and security fixes which is not that much more.

------
tkahnoski
Strikes close to home as current employer try to shifts to better delivery
patterns. I find
[https://web.devopstopologies.com/](https://web.devopstopologies.com/) talks a
bit more about organizational mistakes.

------
kerng
Long ago companies had testers, but then they turned them into developers
also, and at the same time everyone became an ops person too. What could go
wrong?

------
leetbulb
Double-take moment. I thought this was related a machine named "DevOops" on
HackTheBox :P

------
sethammons
"DevOops," very cleaver. I nearly missed it and almost wrote it off as a typo
:)

~~~
kerng
It's a very common term amongst security engineers. There are entire series of
talks related to security and vulnerabilities that are introduced by DevOoops.

It's like some companies had testers, but then they turned them into
developers also, and at the same time everyone becomes an ops person. What
could go wrong?

------
pricechild
> 5 — Implement Ansible, Puppet, Chef, Kubernetes, OpenShift, Terraform…

Irrespective of personal feelings on these individual projects, they're all
aimed at automating something?

I don't get the point of this item?

What's wrong with them?

~~~
jbb67
I think sometimes they are implemented as a solution looking for a problem.
I've seen many times when the automated solution is much more complicated than
the manual solution. Sure, it's more reliable, except that it breaks when you
change something.

The tools are good, but use them when you need them and when they help, not
just because someone told you it was best practice.

------
m23khan
is there an alternative URL where I can read this article? It won't load on my
end. Thx in advance.

~~~
rnotaro
Here a mirror: [http://archive.is/jjBhY](http://archive.is/jjBhY)

