
Maybe we’ve not improved things as much as we think we have with Devops? - michaelbiven
http://biven.org/devopsdays-rockies/
======
Spooky23
Of course we haven't. In many cases, DevOps == have developers push code to
production platforms.

IMO, there's been a lack of attention to the engineering side of the platforms
themselves. In the places that I've seen that yammer on about devops, I see a
lot of agile projects where version 1.0 works great, but the ongoing
maintenance of the platform (whatever it is) is a complete nightmare.

------
davexunit
Unfortunately, developing and deploying web applications is still a total
nightmare. To build anything useful you'll need about four distinct package
managers to get all of the necessary dependencies and some mish-mash of
configuration management and provisioning tools to develop it, and perhaps a
different set of configuration management and provisioning tools to deploy it.
We can do better than this!

~~~
danudey
Hmm, let's see…

> To build anything useful you'll need about four distinct package managers to
> get all of the necessary dependencies

* Ubuntu packages (dpkg via apt)

* Python packages (via pip)

* Our own software packages (via our own dependency manager)

* Custom-built software packages (e.g. nginx) or non-package software installations (e.g. activemq)

> some mish-mash of configuration management and provisioning tools to develop
> it

We use salt for (some of) our configuration management along with just
symlinks into git repositories (where possible, e.g. MySQL and others won't
follow symlinks for security)

> perhaps a different set of configuration management and provisioning tools
> to deploy it

We have a custom-built deployment system which we use to deploy git packages
(including the configuration packages that the configuration files are
symlinked into) as well as our actual software.

So… yeah. You pretty much hit the nail on the head.

~~~
davexunit
Thanks for the real life example.

------
rjbwork
Y'know what? Up until Jan last year I had never even touched a server to
deploy an app, much less set up a CI/CD/DevOps environment.

Now, I'm comfortable with TeamCity, Octopus Deploy, Azure (a ton of hosted
services), PowerShell, and a host of other tools.

I've set up bunch of HipChat integrations so we know exactly where in our
pipleline a particular build is (code pushed, dev build/deploy, and promotions
to various environments), if there was a problem with a unit test run, if
there were problems with integration tests, and if there are problems in
dev/staging/production with our actual live running code via HipChat
integrations with our structured log processing server.

There are good tools out there and they're pretty usable - just maybe not at
your price-point of free for your environment. I went from 0 to 1-click whole-
environment deployments in just over a year.

~~~
mordocai
I don't know if you read the same article I did.

The author specifically said that we'd come a long way on tools but not made
much headway on the people issues related to Dev/Ops.

Your comment does not appear to be adding anything to the article besides
another anecdote that the tools are good (and if that is what you meant it to
be, then I misread the tone of your comment).

~~~
rjbwork
My intention was more, "I went from 0 knowledge at the beginning of last year,
to setting up a full devops pipeline on my own at the beginning of this year.
What's your excuse?" But I wanted to highlight the tools I'm using as well.

------
whistlerbrk
This recent trend of articles wrt to devops it making me want to post here.

Not trying to be too snarky, but why can't people just use shell scripts for
automation?

They are easy to repair, in a language you (should) know, reproducible, and
testable. They are native to your target, supremely portable, etc, etc.

~~~
cheeseprocedure
Because it's not worth re-implementing the functionality available in Jenkins,
Chef, etc. etc. etc.

~~~
stonogo
This is a misunderstanding of the situation. Jenkins specifically has no
business being anywhere near a production deployment; it is a development
tool, despite "devops" people tending to use it as a web-interfaced crond.

Automation should be tooled to the production environment by people who are
familiar with the production requirements and -- most importantly -- by the
people who will be expected to maintain the environment and respond to
critical issues.

~~~
rev_bird
> Jenkins specifically has no business being anywhere near a production
> deployment

I'm curious about this -- what's wrong with using the same deployment tool for
running dev _and_ the other environments? Jenkins itself is a life-saver for,
like you said, doing development builds/testing/reporting, but if we've got
one script that deploys an image to production, why not trigger it with a
Jenkins job, if only to keep everything centralized and maintain coherent
deployment histories?

------
sgoings
I think it's worth reflecting that not every improvement initiative (in this
case: see DevOps) across the whole world is moving as one large entity.

The ending line: "Otherwise in my opinion it feels more like we’re treading
water and not making the advancements we could be making." sounds like an
existential fallacy to me - it has been my experience that although the
"DevOps vision" has not changed significantly, the actual practices and
evangelism of DevOps have been infiltrating and transforming the way
organizations think about software engineering.

~~~
sanderjd
Basically my thoughts: 5 years is not a very long time! It isn't treading
water, it's taking time to mature and penetrate. It's actually taking root
surprisingly quickly, and only looks slow from an early-adopter's perspective.
If those talks from 2010 and 2011 were given to substantially the exact same
audience as that talk from 2014, then yeah, maybe I see the point that things
are just being re-hashed with little progress, but I doubt that's the case.

Giving the same exact talks to an ever-expanding audience over 5 years is
already a win.

------
xj9
I'm really looking forward to Triton[1] coming out of beta. This may be
unpopular/wrong, but I don't think you should have to care about what machine
your app is running on in any way.

[1]: [https://www.joyent.com/developers/triton-
faq](https://www.joyent.com/developers/triton-faq)

------
PaulHoule
One problem is that existing devops tools are not that good.

For instance it seems insane to me that packer and vagrant exist as entirely
separate products. As a java programmer I find that vagrant files are way too
verbose. I am sure I could write some Ruby functions to take care of that and
also to fix zillions of other things that are awful about Vagrant, but then
everybody writes their own functions.

~~~
toomuchtodo
Try Docker instead. I can build Docker containers that provide our devs with a
full blown dev environment that mimics production, which anyone on the team
can then pull down with a simple "docker pull <registry>/<container
name>:latest" command.

~~~
falcolas
Docker has its own issues, and in the end is remarkably similar to Vagrant
when it comes to development. Docker's biggest win on the development (not
deploy) front is that docker containers are faster to set up and tear down;
though with a decent Vagrant setup and a package cache, you can build a brand
new Vagrant image in under a minute.

Since I'm on a Mac, and thus going to be running VirtualBox anyways, I prefer
to just work with the VMs directly.

