

Confessions of a Full Stack Devop - hkarthik
http://www.ansible.com/blog/confessions-of-a-full-stack-devop

======
mlieberman85
For too long Operations and Development have had an adversarial relationship
that bordered on belligerent. At a lot of large organizations I've had a
working relationship with development didn't really care how efficient their
app worked or whether it crashed every half hour, just that it provided the
functionality that it was supposed to. This became a nightmare for operations.
The same goes the other way around. Operations didn't really care much about
how the development environment is setup and don't care how difficult it is
for developers to deploy and test their code.

DevOps, as widely debated what the actual meaning is, brings development and
operations into a more symbiotic relationship. Whether that means that devs
have a more operations minded outlook, or operations looks into how to make
development more efficient, or automating operations or any of the other
various definitions in the end it's about making sure the entire life cycle of
an app is run more efficiently. From initial development and testing through
scaling.

------
mncolinlee
Thanks for the proper permalink!

As a former DevOps engineer turned to development, DevOps has been much
maligned. The idea is not to get everyone to wear all hats. DevOps makes
deployment part of the development cycle rather than the broken practice of
throwing code over the wall. Nothing hurts morale like resting soundly each
time ops is fighting fires your code created.

DevOps done properly does not require an engineer to deploy her own code, but
it does require a sense of ownership over what happens with your code in
production. If that means helping someone understand your code changes enough
to fix the monitoring tools or tune the database then your product will
benefit.

Most importantly, deploying more often means automation gets better. As Martin
Fowler keeps saying, "if something hurts, do it more often." (It must hurt him
to say that.)
[http://martinfowler.com/bliki/FrequencyReducesDifficulty.htm...](http://martinfowler.com/bliki/FrequencyReducesDifficulty.html)

------
rartichoke
I spent months working with Chef and made a good amount of progress but I feel
like it drained years off my life. It's not because "devops" is even hard, but
it's because the tooling is still horrible and the community is still split /
documentation sucks in general / etc..

It actually killed my motivation to program in general so it's not like I'm
some ansible fanboy too. I don't use anything now because I haven't deployed a
line of code in about 2 months.

~~~
mlieberman85
Tooling is still difficult. I've used Puppet, Chef and Ansible all in
production environments and though I like Ansible the best I just think none
of them are all that great yet. Chef had some major issues between versions
(entire suites of cookbooks made obsolete) and certain operations weren't
deterministic. Puppet's DSL is just awful in my opinion though they have
probably the best feature set . Ansible is definitely much simpler than the
other two and easier to use, but a lot of the gotchas are just frustrating,
e.g. jinja2 templating issues, a lot of new features that have unintended side
effects when used with certain other features, where you can use conditionals
and where you can't use conditionals seem arbitrary, etc.

~~~
rartichoke
Most people do need simple. Just having 2 or 3 servers is enough to handle
quite a bit traffic and you can always vertically scale up to a certain point.

Once I recover from burn out I'll likely look into an alternative to Chef.

