I believe that Docker would not have been nearly as successful if shared libraries had not taken over the Unix world.

Docker would have been helpful for putting together Python and Java installations, with all their ancillary bits, but less so for C binaries.

Now, though, we run an OS on the machine, put a VM on that, install a container on that, and run another VM (or JVM) inside the container, then maybe we're at the level where we can execute actual code. And that misses all the extra pieces that are distributed and layered and indirected and virtualized for management, logging, security, data warehousing, ...

It's a wonder any of it works at all.

Here's a map to guide you: https://landscape.cncf.io/

-rob


On Fri, Sep 17, 2021 at 9:15 AM Marshall Conover <marzhall.o@gmail.com> wrote:
While I got a chuckle from this, it focuses on security, and I don't
think security sold docker containers. I think what really sold
containers was their ability to solve the old, hard problems of
configuring and maintaining servers.

Docker's use of per-process namespaces is a godsend for running
different services on the same machine. I no longer run into two
applications fighting over dependency versions, because both
applications are running in their own world. This was somewhat
possible in chroots, but as someone who tried to use chroots that way
a decade ago, docker's made it trivial.

Containers are also a godsend for applications that have to be
deployed somewhere else. I know a container I deploy will have
everything it needs wherever it goes, and will be exactly the thing I
built and tested. It's hard to understate the benefits of this: when
deploying, I no longer run into issues like "oh shoot, there was some
configuration I forgot about on the dev server that I need for prod."
I no longer have to create server configuration documentation either,
as the documentation is "docker build," followed by "docker run." When
we were first starting out on our current project, we built a
container that runs our build system's agents. At one point the VM on
which we were running those agents went down, and our stop-gap fix was
to download and run a few copies of that container locally. As a
result, we had builds going the entire time we worked to fix the
issue.

---------------

Separately, for the larger discussion, I think the
abstraction-aerospace-engineering seen over the last few decades comes
from the adage "necessity is the mother of invention." People writing
business logic today are targeting an OS-independent platform: the
browser. That's where developers need solutions, and that's where we
see movement. Considering this, it's no surprise the browser has
stumbled backwards from a markup language-renderer into a full
platform for downloading and running applications and managing their
resources, as well as providing complex abstractions for interacting
with distributed systems. And it's no surprise those distributed
systems have separated as much as possible from whatever's not the
browser.

In fact, we're seeing agreement in the browser ecosystem for problems
like the directory system choice mentioned above. The OIDC workflow
was born out of the internet's many-users-to-many-services issue. Now,
it's such a decided approach for managing users' access to services
that big names like Amazon and Google offer identity provider services
using it, and I, as a service writer, can swap between any of them
transparently. The services I run only care that the token they're
handed is signed by the auth server they're configured to use, and
that the token says the user is allowed to use the service contacted.
The applications I write and use have no clue what the OS' permissions
are for anything they deal with. For them, OS permissions have been
made redundant.

With this context, I think most of us here have learned by experience
why the OS gets no more development, in every discussion they've had
with management where they've said "we need to refactor some code that
is wonky, but mostly works, because there will probably be errors and
bugs and security issues in the future if we don't." Management -
which in this case, means the world at large - demands new features,
not unspecified heisen-benefits from redoing things that already work.
For new features, the browser is their only recourse.

And, to boot - if you change the thing under the browser, what if it
breaks the browser?

Cheers!

Marshall










On Thu, Sep 16, 2021 at 3:41 PM Larry McVoy <lm@mcvoy.com> wrote:
>
> On Thu, Sep 16, 2021 at 12:34:15PM -0700, Jon Steinhart wrote:
> > As I've said before, I'm having difficulty distinguishing the "full stack"
> > in full stack programming from a compost heap.  It's not OK to me from a
> > security, safety, and reliability perspective to build on a rotting
> > foundation.
>
> Amen.
>
> > It's my opinion that the whole container thing sort of started as a "we
> > can't secure the underlying system so we'll build something secure on top"
> > combined with "it's no fun to fix the unnecessary incompatible mess among
> > virtually identical systems that we've made so we'll build a new fix-it
> > layer" ideologies.  How long until problems are found with containers
> > it's decided that the way to fix it is to build "safe deposit boxes" that
> > run in container?  Is there ever an end in sight?
>
> I think it is that the newer kids are less willing to understand stuff.
> So they build something on top that they understand.  I agree that they
> will hit problems and likely build "safe deposit boxes" because the
> containers are "too complex".
>
> Oh, and get off my lawn!