
Ask HN: Devops-is the future just handing a dockerfile to container services? - ransom1538
Devops: Wont the future just be handing a dockerfile over to a container service?<p>What is the point of Puppet&#x2F;Chef anymore?  A dockerfile specifies everything you need. Do people really want to continue to script company specific infrastructure code? In the future, with a docker file, can&#x27;t a container service just figure out the loadbalancers, networking, etc? Isn&#x27;t this more secure?  Will this end the devops madness?
======
usgroup
If there is a no devops reality any time soon then it'll be something
following the AWS serverless pattern.

The container orchestration craze (i.e. Kubernetes et al) is buoyed by
irrational decision making. I.e. the number of legit use cases are much
smaller than the number of implementations purely because it's cool or career
building.

Meanwhile, in the cost-efficient world, running 5-10 mega-machines in
rackspace and managing them with Ansible is still often the most rational
option.

~~~
wayn3
"or career building" is an undersold point.

for some reason, hopping onto the hypetrain and shitting out a github repo
over the weekend that does the minimally possible thing for a really new
technology is about as much career building as having been the PM responsible
for google maps.

"having a repo" is somewhat equal to claiming non-"provable" 5 years of
experience.

~~~
usgroup
Interesting point but I disagree on grounds that most devs don't have github
repos and dont contribute to open-source IMO.

~~~
wayn3
that makes those who do have them so appealing.

------
caw
So let's consider the hypothetical future where you hand a dockerfile to a
container service.

Where is this container service? Maybe it's in the cloud, you're paying Amazon
for it. That's a possibility, and there's nothing for you to do there, but
maybe you're a F500 company (or Amazon) who runs everything in-house.

How do you provision the container cluster host? Maybe you PXE boot, but you
still need a configuration to join the cluster.

Maybe you don't configure via confs, and instead try to auto-detect nodes via
multicast. Sure, but now you're constrained to a single broadcast domain on
your network. Can't make that too large or you'll have a very chatty network.

How do you provision the switches? They need configurations still.

You'll also want security enforced on the hosts, to ensure certain container
ports aren't exposed to the world (oops MySQL is now public due to a debug
container instance getting rolled into production).

You still need backups of your data. What, where, when are the backups? I
doubt tape robots connect into containers, but I could be wrong.

So there's definitely ops work to be done, and configuration management is a
part of it. Maybe you outsource this, but it has to be done.

Let's go back to the what goes into the container. You're going to be running
an application, and depending on the language you may need to compile it, and
your production containers are going to be slim so you strip the build tools.
So you need some other kind of build container or host to manage this.

In most (all?) cases you're going to want to test your code. This means a CI
system, and probably a CD system since you want containers to be built
automatically with the latest code so it's easier to deploy. What manages the
CI/CD system? More importantly, who? DevOps, in the conceptual sense, even if
the title changes.

------
superflit
Docker files are good for small units of your app stack (nginx, web
frameworks,etc). As you grow you need to have consistency and predicability
between all your servers. Like same version of libs, configs, etc.

As docker is a userland[0] app it does not provide that natively (there are
some workarounds).

My workflow:

1\. machine setup - puppet or ansible 2\. Is machine ready for app? If yes
pull app using Docker or Git 3\. Need to modify update? Change configs, commit
(always version your puppet/ansible configs and apps) 4\. Profit

[0] - [https://docs.docker.com/get-started/#container-
diagram](https://docs.docker.com/get-started/#container-diagram)

------
BjoernKW
I hope the future is containerless (as in "serverless"). I don't want to deal
with container configuration and infrastructure in general at all. These
technologies will still play a vital part in the fabric underlying software
solutions but deploying software should as easy as defining a function, its
inputs and its output.

Function as a Service platforms such as AWS Lambda are definitely a step in
the right direction.

