Hacker News new | ask | show | jobs
by algesten 2528 days ago
At my company we did our own docker execution environment. We generally like docker's layers and packaging, but dislike the runtime.

With AWS you already have a virtualization, why do we need another layer?

We packaged a super slim Linux with an init that just has some minimal code reading out of AWS EC2 user info the conf. Downloads docker hub image and runs it as a process.

No virtual networking or ssh access. No magic. Just a process on an aws ec2 instance.

4 comments

It sounds very inefficient to be honest. Containers don't add much overhead - they are essentially processes that run in constrained environments (see http://man7.org/linux/man-pages/man7/namespaces.7.html).

Why dedicate an entire ec2 instance to a single container?

It wasn't that long ago that we were doing service-per-VM and really OP has just described an implementation of that strategy with containers.

You would scale the virtual machines to try and reach optimal resource usage rather than pick a standard fleet of virtual machines for all workloads and let a scheduler do some kind of knapsack scheduling based on available resources.

Comparatively, service-per-vm approaches are very wasteful and ineficcient, moreso if a container orchestration system is used to manage the deployment. It makes no sense to fine-tune VMs just to match the resource requirements of a single process, particularly as they change over time and as that approach leads you to a collection of custom-tayloted VMs that are needlessly cumbersome to manage and scale.

Meanwhile containers enable you to run multiple services on the same VM, scale them horizontally as you need on the same pre-determined amount of resources, use blue/green deployments to spread your services throughout your VMs automatically, and achieve all of this automatically and effortlessly.

I think this works fine for a lot of things.

The argument though is that can't run an EC2 (AMI) anywhere except AWS.

The advantage of Virtual box images or Docker/OCI images is that you can run them in multiple places (locally, AWS, GCP, Raspberry Pi, etc.) with consistent results.

Before Kubernetes existed, this is how most people used CoreOS [Container] Linux. Ignition/cloudconfig to configure the systemd unit files that start just the main container and sidecars.
Scaling up another ec2 instance is slower than a container.

So if you have 10 services deployed on 10 ec2 instances each, you will need 200 ec2 instances to give yourself 50% headroom for each service.

With containers, you can give each container 10x headroom for the same amount of hardware.