
How to Deploy All Day yet Deploy Nothing - mrfoto
http://mr.si/posts/2015/11/22/how-to-deploy-all-day-yet-deploy-nothing/
======
derefr
Two important points the author (re-)discovered here, that are really not as
commonly known as they should be:

1\. Docker is a first-class citizen on Linux, and a second-class citizen
everywhere else. "Setting up Docker" on Linux means installing the Docker
daemon. "Setting up Docker" on OSX or Windows means _installing a Linux VM
containing Docker_ and getting it to port-forward the docker daemon from that
VM to your host. After it's set up, there's no day-to-day usage difference—but
that stumbling block is a big one.

2\. Nothing AWS offers—no matter how much it might look that way—is an end-
user platform. It's all infrastructure, the kind of thing sysadmins set
up/deal with. Infrastructure-as-a-Service effectively means "our market is
bigcorp CIOs making buy-vs-build decisions": decisions of whether to provision
more local data-center infrastructure, or provision that same infrastructure
"in the cloud."

In other words: Elastic Beanstalk isn't for prototyping an instance of your
app! Instead, it's for CIOs considering replacing "our data center containing
a bunch of machines with docker daemons on them" with "our AWS VPC containing
a bunch of opaque instances with docker daemons on them." The same goes for
every other AWS service: the documentation and "semantic models" of AWS
services are not _targeted at_ app developers, but rather at the _sysadmins_
who were implementing the CIO's whims by keeping local infrastructure going
at-scale, and are now implementing the CIO's whims by porting said
infrastructure to the Amazon cloud.

AWS might be intuitive to you as a developer _if_ you have 5+ years of devops
experience, deploying your own code and and managing the infrastructure it
sits on. Otherwise, the choices AWS offers will be pretty opaque to you.

(Side-note: there's a business model [that AWS allows and encourages] in
taking an AWS IaaS-level component, and shellacking a coat of UX onto it to
make it _into_ a PaaS component, and making your money by arbitraging on the
"PaaS premium." Heroku is PaaS-shellacked EC2 instances; Tarsnap (or Dropbox,
even) is PaaS-shellacked S3 buckets; etc. I'm surprised more of these
businesses don't exist.)

~~~
nothrabannosir
_> Once it's set up, there's no day-to-day usage difference_

On a laptop you now have an extra OS running, with all the associated costs:
talking to disk every now and then, doing os-y things.

If nothing else, it feels like my battery runs out faster with docker-machine
on and no containers running. But maybe somebody has actual numbers on this?

~~~
TeMPOraL
Yes, you have one unnecessary OS there, and it _isn 't_ Linux running Docker.
:). Personally, I run Windows because for some unknown reason that's what I
get issued at every company I join. This Windows runs a VirtualBox with Linux,
where I do actual work. Docker is amazing operated directly, and you get all
the benefits of your dev and production environment being essentially the
same.

------
dkarapetyan
That's because most of these tools are built by people who are borderline
psychos. I don't mean the murderous kind but the kind that is emotionally
stunted, working under intense business pressures to deliver (which is really
just another group of psychos higher up the hierarchy), and overworked. The
best part is that there is nothing new. It's all just the same old stuff
except now it's in the cloud and requires 10 layers of configuration being
held together by heroic manual effort. I know you think chef, ansible, salt,
puppet, etc. helps. Nope, tried them all, same thing applies and I'm no longer
in the mood to learn yet another DSL for shell scripting.

It's not just AWS. This is pretty much true of every infrastructure/cloud as a
service company. They either have too many knobs with all sorts of unintended
interactions and half-baked integrations or they abstract away way too much
and you have no control over anything and can only deploy a nodejs or django
application that follows a very specific rigid structure. Oh and did I mention
most of this stuff is insecure by default and if you want to do anything in a
secure way then your n-layer configuration nightmare is now 10x worse
(probably why most places are looking for 10x programmers). Oh and there is
also networking/NAT, user management, logging, artifact distributions, service
discovery, etc. to worry about as well using tools that are just as half-
baked.

~~~
TeMPOraL
> _Oh and there is also networking /NAT, user management, logging, artifact
> distributions, service discovery, etc. to worry about as well using tools
> that are just as half-baked._

Oh the good old times when I was learning to program. Configuration was just a
simple INI parser written in two hours from scratch. Networking was done by
Apache, user management meant a database table, logging was done with a
function wrapping over fprintf(), "artifact distributions" meant res/ folder,
service discovery was done on paper. And somehow everything worked. It worked
better and was infinitely more manageable, and was mostly dependency-free.

I can see how the above would cause problems for e.g. Google. But 99% of
companies and open-source projects are _not_ Google.

Web development is insane.

~~~
jacques_chester
> _And somehow everything worked. It worked better and was infinitely more
> manageable, and was mostly dependency-free._

You and I apparently remember things very differently.

------
ryandrake
Note, I'm definitely not a web developer. I've put static web pages together
and fooled around with Rails & Heroku a little. So, as an outsider, I'm
curious: How did you all (the web development community) make DEPLOYMENT so
complicated? All these packages and environments and VMs and containers and
environment variables. Shouldn't deploying something on the web be a few
minutes of FTP and then go do something more productive the rest of the day?
What am I missing?

~~~
mschuster91
> Shouldn't deploying something on the web be a few minutes of FTP

It should be, but well... this is something if you're using PHP.

If you're using anything hipster (ruby, iirc python, Java) you're out of luck
with that.

~~~
jacques_chester
Yes and no. With PHP the complexity is all still there -- you've just
delegated to a shared host.

I worked on Cloud Foundry buildpacks for a while. The PHP buildpack is
actually one of the more complicated ones, because at staging time it tries to
recreate a shared hosting environment in a standalone container.

The Ruby buildpack is complicated for legacy reasons, but for 99% of modern
apps all it really does is run bundler and rackup.

Meanwhile every PHP app wants to keep on living in the 90s.

Arguably the Java buildpack has the simplest job, if you use a sane build
tool. "Here, launch this jar".

------
twunde
The sad part is that it's even worse when using windows. The only thing I've
got working without too much yak-shaving was node, but anything devops-y is a
pain including vagrant, otto and even the package manager (chocolately)

~~~
sakopov
That's funny because I was about to say the complete opposite.

~~~
ahmedfromtunis
That's funny because I run almost everything smoothly (Vagrant, Node (grunt,
bower, ...), Python, Chocolatey and now Meteor), on my Intel Atom NETBOOK.
It's not perfect. Can get laggy, but works just fine must log the time. That
said, I think I'll jump on the Linux bandwagon very soon.

~~~
TeMPOraL
> _Intel Atom_

I worked that way for two years. It doesn't really matter if everything works
smoothly under Vagrant if every day you want to kill yourself at your desk
because you can't run an Vagrant and a browser at the same time without
bringing the system to its knees.

------
Palomides
"I’ve wasted the whole day exploring new things and concepts" is a weird thing
to say after you set out with the goal of learning some new tools. Definitely
seems like he learned something.

~~~
TeMPOraL
I understand the frustration. Reminds me of the first time I tried to run
something on a VPS. I wasted at least a day or two fighting with bullshit
issues like botched up Unicode support on my Debian installation. I did learn
_something_ , but it was not the thing I wanted to be learning.

------
nevi-me
I wasted a lot of weekends getting Docker or Vagrant to work so the rest of my
team could follow what I was doing. After a few weeks of Google and outdated
documentation, I decided to try out LXC and throw away all the other fancy
tools. I went into each container and ran my provisioning script(s), updating
them for each trick I stumble upon. My sanity is back now, and my team will
clone the LXC repos for their development environment.

After a few nights of trying to get Docker to run on my work laptop, I figured
there was an issue with Windows security as the VM would be created but Docker
would fail to initialise. One of my colleagues said a CentOS worked for him.
By then I had dumped Docker for Vagrant; which also had the same issues. I was
now trying to figure out how to run Vagrant on Hyper-V as Vbox was acting up.
I grew some grey hair those weekends. I'd rather be conservative with my time;
use what works and wait for some of these tools to mature.

------
vinceguidry
Hah, this is why I don't use Docker. Too much added complexity for too little
gain.

I'm extremely conservative these days. I beat my head against Capistrano long
enough to learn its ins and outs, so if some new tool doesn't work with
minimal Googling, I go right back to good-ole' Cap. I have a provisioning
procedure I adapt for each cloud host that basically gets the machine ready
for cap deploy. If cap deploy doesn't run smoothly, I alter my provisioning
procedure once I figure out why. Usually it's for gem OS dependencies.

Any replacement strategy would have to beat the ease and reliability of
Capistrano. That's going to be tough.

------
pech0rin
Once you have the whole system figured out and setup then it seems to be that
you have a lot more configuration options and control with eb vs heroku. There
might be a steeper learning curve but once you jump the first few hurdles eb
does make sense. Additionally, the author mentions deploying a super simple
app. Obviously super simple apps are awesome to deploy on heroku because there
is nothing out of the ordinary. AWS offers a lot more services for when your
application gets off the ground and becomes more complex. It provides the
infrastructure and you provide the configuration.

------
jacques_chester
I guess my question is: why not Heroku?

Or, since I work for Pivotal: why not Pivotal Web Services?

The Ruby buildpack (which is > 90% identical code between the two) is pretty
well-tested for deploying Rails at this point.

------
falcolas
I'm reminded of the "Command Line Bulshittery" article recently featured on HN
[0].

So much effort, just to get to zero. Somehow, somewhere, this has to change.

[0] [http://pgbovine.net/command-line-
bullshittery.htm](http://pgbovine.net/command-line-bullshittery.htm)

