• _cnt0OP
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    You often (if not most of the time) need some infrastructure in OCI containers (while we’re at it, let’s get rid of the misnomer Docker image). And that’s going to be some subset of a distribution hand-crafted for that purpose. Most of the time, that should be Alpine, because they provide the slimmest base image.

    • dan@upvote.au
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Most of the time, that should be Alpine, because they provide the slimmest base image.

      Distroless containers (e.g. https://github.com/GoogleContainerTools/distroless, Chiselled Ubuntu, etc) are often smaller than Alpine ones. Google’s smallest Debian-based one is around 2MB.

      I have a Dockerized C# app… I’m going to try .NET Native AOT (which was improved a lot in .NET 8, released today) to compile it into a self-contained binary, and see how well it works with a distroless base container.

      • _cnt0OP
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        I’m curious to hear how that works out. I’m a big fan of C#; not so much the Microsoft ecosystem. I’d say for maximum scalability you’d want languages which compile to small binaries. So, Go, Rust, C++, C, and theoretically some others. The approach with Java and C# to bundle the framework, JIT, etc, and then try to shave off as much as you can get away with feels kind of backwards. And I get the excitement of the Java folks when they manage to create a self-contained binary with GraalVM and co of 12mb. Like, that’s impressive, but had you developed the same thing with Go it would be .5mb. Curious to see how .NET fares in that comparison to Java.