
A Practical Introduction to Container Terminology - rayascott
https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction/
======
hguhghuff
When Java came along I felt sad. I loved computers and software but I just
didn't like Java. But this was the early 2000s and Java had taken corporate
and web development by storm. Everything was Java.

So I felt flat. Computing was diminished not because Java was inherently bad,
but it just didn't appeal to me personally.

As it is with Docker and containers. I'm sorry to go against accepted wisdom
but I just don't like this technology. To me it is a complex kludge. I feel
that it is simpler software technology that should succeed current overly
complex technology.

It's my personal subjective opinion but I just feel that docker and containers
are a big complex mess and I'm saddened that this is the direction of the
entire industry.

Probably you love docker and containers. I don't knock that. It's just not to
my preference.

~~~
tyingq
The popularity of docker in corporate environments is mostly because it allows
developer teams to control the OS without dealing with sysadmins that are in a
separate organization. Similar for cloud in general.

I think many people don't see that a lot of the popularity is less about
technology, and more about politics. "Devops", in general, is basically an
organization change to move sysadmin's duties into the development team's
domain. It has predictable upsides, and downsides.

~~~
cookiecaper
Yes, microservices and containers are a way for developers to feel important
and grant cover to an unabashed manifestation of Conway's Law. This particular
fad is wreaking ridiculous havoc that is going to have the computing world in
quite a mess soon.

In the real world, distributed systems are a _complication_ that is better
left alone if they're not necessary for a problem space. You very likely _don
't need_ Kubernetes (watch out, this sentiment will get your HN account
throttled; I've already been punished for it so it's safe for me to say).

The reason Google et al push these distributed systems is because it gets you
to buy more cloud instances. Very predictable and straightforward behavior
there.

Like all technology that proliferates, this is definitely more about politics
than merit, but it doesn't really move the duties around practically; anyone
who thinks that a group so undisciplined and lackluster as your average
software developer will willingly take on new responsibilities is detached.

As a sysadmin, you just get developers delivering garbage to your doorstep and
expecting you to deal with it, same as always. It's just packaged in a stupid
way now, that makes the developers say "Well I sent you a container, so this
should be up and running in like, 5 minutes, right?" In practice, most
developers won't even write their own Dockerfiles; my experience has been that
they develop locally as they always have, and then expect the
sysadmins/"devops" (now a term for sysadmins) to do all that mumbo-jumbo.

But yes, we've been through this song and dance before. It's static v. dynamic
linking. It's shared tenancy v. single tenancy. None of it is new, it just
gets a different name and oscillates from position A to position B.

It's an embarrassment and a testament against our industry that we continue to
thrash wildly and be so thoroughly dominated by fads.

~~~
_jal
Looks like someone else has been around the block a couple times.

There are going to be massive opportunities for good consultants in this
muddle. I'm currently watching one train wreck, thankfully at a distance.
Nothing novel - they moved ops under the engineering umbrella. The engineering
manager not only has no clue what the differences in managing the two are, but
seems unaware that there are any. So of course the good system people quickly
left, the engineers are slowly discovering that containers don't magically
erase the need for understanding how things work, and they're spending six
figures a month on K8s consultants.

We seem to have a generational cycle on IT/sysadmin/ops hate. As you get
older, it becomes amusing watching every new batch of engineers learn why they
exist.

~~~
devonkim
This kind of cycle is part of why I’m regretting 13+ years in different
incarnations of ops. Developers have always gotten business priority over ops
unless it comes to security and I’ve seen far more places brush aside even
security in the name of more features than should be healthy to one’s sanity.
Even at the peak of ops when everyone was scrambling to get security engineers
and such, I simply never heard of some bright kid graduating from school and
getting $200k+ comp packages... for being in ops, even for DoD cyber security
BS. Ops is a cost center even in the cutting edge of organizations in this
respect. Few companies will make more money by throwing more money at ops that
is. Combined with the serious health hazards of being on-call I’m a bit
worried when I hear about companies asking their developers to get more
involved with ops.

~~~
cookiecaper
Yeah. "DevOps" originated as a naive attempt to fix this issue by eliminating
the "wall" between the roles, but it was quickly misunderstood.

The old-school, master of the universe-style sysadmin who had to use advanced
wizardry developed out of deep knowledge and intuition about how the computer
worked at a fundamental level is still the ideal developer OR operator. But
it's hard to find people who even understand this role, let alone people who
are hiring for it.

People only seem to understand pigeonholes, despite occasional well-intended
attempts to unify, that generally have disastrous results. You just need a
special breed to get someone who can really function up and down the stack,
and every company should seek out, train, and develop such highly-empowered
"tech special forces", for lack of a better term. It's tragic that so many
companies don't realize this.

------
neals
Who here is willing to name a few downsides of using containers?

~~~
jeremyjh
It isn't an unsolvable problem but I predict that in many organizations,
containers will mean more instances of critical hot-fixes (to library
components outside the kernel - e.g. openssl) not being applied across the
board because the development teams manage the container image and once the
product is in maintenance no one is going to be updating them. This is
mitigated by a smaller attack surface but its still a concern.

~~~
nova22033
>once the product is in maintenance no one is going to be updating them.

That's not a container specific problem. That happens even when you don't use
containers.

~~~
sedachv
There is a lot of misleading marketing hype, misunderstanding, and plain
misinformation about how containers/Docker make updates, and in particular
security updates, easier, when the opposite is the reality. A lot of people
buy into the CoreOS marketing hype, as though it was the only Linux
distribution to offer automatic security updates. If you use containers as
recommended, in fact the only thing CoreOS gives you are kernel updates, which
is less than what other distributions provide. To get userland updates with
Docker, you have to update your base image, then rebuild and re-deploy your
application image, for every single application that you have. Or use custom
kludge layers for updates: [https://github.com/SUSE/zypper-
docker](https://github.com/SUSE/zypper-docker)
[https://github.com/projectatomic/rpm-
ostree](https://github.com/projectatomic/rpm-ostree)

Making maintenance and updates harder is definitely a container specific
problem.

------
Aelius
Commenting to offset the negativity:

I'm looking forward to flatpak, and I currently use firejail + liberal use of
`chromium --user-data-dir=~/.config/chromium-<website>`.

Because web-app based software and web-services I frequently interact with
(slack, gitter, discord, twitter) should absolutely be separated from my
general browser, and from each other. Most methods of web tracking and
phishing/XSS attacks will be neutered in this setup.

And because my browser, and all of these separated services, should not have
unfettered access to my system and personal files.

I don't think I will bother with containers for general software, but web
services are an attack vector and should be treated as such, even at the
expense of complexity over simplicity.

Frankly, the notion of simplicity was out the window the moment we started
using the web as a development platform.

------
billfruit
Perhaps containers are an amazing thing, but on trying to learn more about
them, and Docker in particular, what I observed is that most of the
documentation is full of enterprisy buzzwords coming out of marketing, rather
than real technical information. The docker website and documentation, I feel
is more a disservice in this regard.

I was looking at containers for maintaining a sane and replicable environment
for software development without interference from changes on my host machine,
yet most docker guides do not go into that workflow.

Difficult to find crucial info, like can linux containers run on windows and
vice versa, licencing requirements and so on at a quick glance.

------
teknopaul
"Red Hat is working hard to make OS Containers easier by enabling systemd to
run inside a container"

Redhat is still refusing to admit that containers highlight systemd's
weaknesses.

Containers benefit from simple init. The systemd argument has become so
religious iside RH now they are blind to the fact that, for all systemd's
benefits on a laptop linux install, it complicates a container.

Its affecting their position on containers badly, because they have no middle
ground between "full os" and "1 bin per container". Everyone else can see that
sshd in a container is not _ideal_ but a handy stop gap sometimes, as long as
you dont then stuff the container with stuff you dont actually use. Redhat are
blind to that and, as a customer, its horrible. They refuse to "support"
simple RHEL OS containers, i.e. a container without systemd.

Its a full RHEL vm or Docker, or your warranty is void. This makes migration
to containers hard for us. Its probably counter productive for Redhat because
when we do go full "bin per container", RHEL is out of the picture entirely.

------
talkpush
`The second big argument for project-based learning is that it more closely
resembles what students will actually do on the job` I never understood this
argument as this is so far from the truth. Most of the time working in
professional environment you have to deal with legacy code, you are a lucky
bastard if you can start a project from scratch.

------
m3mnoch
it sounds like a lot of the negativity revolves around devops. that's
understandable. it's part of a pendulum that swings back and forth. devops and
docker as topics aren't really mutually inclusive.

docker, however, is more about the abstraction of complexity stemming from the
industry's overall drive toward scalable, distributed applications and
development teams. it's more analogous a developer saying, "why do we even use
virtual machines?!? bare metal is way faster!"

