11–20 of 446 posts
Using nomad as a job scheduler and deployer allows you to use various modules for jobs: java, shell, ec2, apps (and containers).
I use it in my homelab and it’s great. That said, I don’t use it professionally.
I think Cloudflare is running this stack alongside firecracker for some amazing edge stuff.
Depends what you mean by 'container runtime' or 'container orchestration tool'... For example, Google's Borg absolutely uses Linux namespacing for its workloads, and these workloads get scheduled automatically on arbitrary nodes, but this doesn't feel at all like Docker/OCI containers (ie., no whole-filesystem image, no private IP address to bind to, no UID 0, no control over passwd...). Instead, it feels much closer…
Depends what you mean by 'container runtime' or 'container orchestration tool'... For example, Google's Borg absolutely uses Linux namespacing for its workloads, and these workloads get scheduled automatically on arbitrary nodes, but this doesn't feel at all like Docker/OCI containers (ie., no whole-filesystem image, no private IP address to bind to, no UID 0, no control over passwd...). Instead, it feels much closer…
Many companies just rely on the practice of shipping software with heaps of dependencies.
I worked at a place that simply spun up blank AWS images in autoscaling groups and allowed configuration management to install literally everything: security/infra/observability agents, the code and dependencies (via AWS CodeDeploy), and any other needed instance configuration.
The downside of this practice was slow startup times. The upside was...I don't know, I think this pattern happened by accident. Packaging these AWS instances into images beforehand would be smarter. Newly created services were generally moved over to k8s.
These were stateless web services for the most part.
I think the lesson I learned from this was "nearly any operating paradigm can be made reliable enough to tolerate in production."
I'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.
I've been at a company where they weren't (yet) using containers nor K8S. The build process would just create VM images with the required binaries in there and then deploy that to an autoscaling group. It worked well and if you only ever intend to run a single service per machine then is the right solution.
I’ve been trying to pick the right Linux distro to base my images on. Ubuntu Server is the low effort route but a bit big to redeploy constantly.
I’ve also been looking at the possibility of using Alpine Linux which feels like a better fit but a bit more tweaking needed for compatibility across cloud providers.
Unikernels are also interesting but I think that might be going too far in the other direction for my use case.
For others doing this, I’d be interested in what distros you’re using?
I believe tools like nomad and consul shine here. Using nomad as a job scheduler and deployer allows you to use various modules for jobs: java, shell, ec2, apps (and containers). I use it in my homelab and it’s great. That said, I don’t use it professionally. I think Cloudflare is running this stack alongside firecracker for some amazing edge stuff.
https://www.nomadproject.io/docs/who-uses-nomad
(have advocated for its use in multiple financial orgs as part of my day gig, no affiliation with Hashicorp)
I've been at a company where they weren't (yet) using containers nor K8S. The build process would just create VM images with the required binaries in there and then deploy that to an autoscaling group. It worked well and if you only ever intend to run a single service per machine then is the right solution.
Back in 2016 at least, Stack overflow was container free https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar... No idea how much has changed since then