No post body was provided.
Ask HN: Who operates at scale without containers?
111–120 of 446 posts
Re: Ask HN: Who operates at scale without containers?
#112> ... without relying on the specific practice of shipping software with heaps of dependencies. Whether that be in a container or in a single-use VM.
Either you have to package your dependencies with your software, rely on your deployment environment to have all of the dependencies available, and correctly versioned, or write software without dependencies.
Since you seem to have a pretty specific pattern in mind, I'd be curious to know more about what you've envisioned or are dealing with.
Re: Ask HN: Who operates at scale without containers?
#113Earlier quoted context omitted.
Thanks, CentOS was on my radar too. I’ll take a closer look!
Isnt CentOS basically discontinued at this point?
It's changed from a downstream distro to upstream. Rocky Linux has since appeared to take its place in the community, by one of the original CentOS founders.
Re: Ask HN: Who operates at scale without containers?
#114I'd imagine the answer largely depends on whether or not your company either builds or buys software. If your company builds - it's no garuntee containers are used (but it's a choice). If your company buys software - I highly doubt containers are used at all.
The commercial, licensed software I've dealt with in the past year has all been containerized.
OCI images don't necessarily mean lxc/docker style containers. Many are run directly on MicroVMs. https://fly.io/blog/docker-without-docker/ Ditto Google Cloud Run.
Re: Ask HN: Who operates at scale without containers?
#115Earlier quoted context omitted.
> Containers only give reproducible deployments, not builds Could someone elaborate on this please? Doesn't it depend entirely on your stack how reproducible your build is? Say I have a Python app with its OS level packages installed into a (base) image and its Python dependencies specified in a Pipfile, doesn't that make it pretty reproducible? Is the weak spot here any OS dependencies being installed as part of the…
> Containers only give reproducible deployments, not builds I think that means containers alone are insufficient for creating reproducible builds, not that containers make reproducible builds impossible.
I believe that is correct. It’s also hard to make container builds really reproducible (even with other parts of the build being so).
Some sibling comments have talked about why.
Containers are to ops like C is to programming languages. Man is it useful, but boy are there footguns everywhere.
Usually still better than the ops equivalent of assembly, which is what came before though - all the custom manual processes.
Kubernetes is maybe like early C++. A bit weird, still has footguns, and is it really helping? Mostly it is in most cases, but we’re also discovering many more new failure modes and having to learn some new complex things.
As it matures, new classes of problems will be way easier to solve with less work, and most of the early footguns will be found and fixed.
There will be new variants that hide the details and de-footgun things too, and that will have various trade offs.
No idea what will be the equivalent of Rust or Java yet.
Re: Ask HN: Who operates at scale without containers?
#116My company runs without containers. We process petabytes of data monthly, thousands of CPU cores, hundreds of different types of data pipelines running continously, etc etc. Definitely a distributed system with lots of applications and databases. We use Nix for reproducible builds and deployments. Containers only give reproducible deployments, not builds, so they would be a step down. The reason that's important is t…
> Containers only give reproducible deployments, not builds Could someone elaborate on this please? Doesn't it depend entirely on your stack how reproducible your build is? Say I have a Python app with its OS level packages installed into a (base) image and its Python dependencies specified in a Pipfile, doesn't that make it pretty reproducible? Is the weak spot here any OS dependencies being installed as part of the…
https://github.com/GoogleContainerTools/distroless
This is the container community’s response to this ambiguity I think.
Re: Ask HN: Who operates at scale without containers?
#117Most AWS dataplane services are on ALB + EC2, some of the newer higher level ones do use containers.
Re: Ask HN: Who operates at scale without containers?
#118Booking.com - at least until I left in 2018, not sure about now. Their code base is (still) mostly in Perl (5), running on uWSGI bare instances, installed on KVMs deployed on a self-hosted infrastructure.
Working in Perl in 2022, the horror, especially because most likely it's 10y/o perl version.
Re: Ask HN: Who operates at scale without containers?
#119We run on thousands of EC2 instances and our biggest systems operate at millions of requests/sec. No containers*. We use EC2, Route53, S3, and some other AWS stuff, plus custom tooling built on their APIs. Most of our code is Go or Clojure so deployments generally consist of self-contained artifacts (binary or jar) plus some config files; there's little to no customization of the instance for the application.
*Well we do have an in-house job queue system that runs jobs in Linux namespaces for isolation. But it doesn't use Docker or whole-OS images at all.
Re: Ask HN: Who operates at scale without containers?
#120Earlier quoted context omitted.
npm packages can change without a version change? Can you explain this? npm doesn't allow you to delete any published versions (you can only deprecate them). You aren't allowed to publish a version that's already been published. Even when there have been malicious packages published the solution has been to publish newer versions of the package with the old code. There's no way to delete the malicious package (maybe…
Sorry, without a minor version change. You can easily publish a patch version and most people don't pin that part of their dependency.
They don't need to pin it directly.
They only need to "npm ci" (based on package-lock.json) instead of "npm install" (based on package.json) within the Docker container to get a fully reproducible build.