Hacker News Reader

Comment by TheHydroImpulse | Hacker News Reader

We're using Docker pretty extensively at Segment with over 1,200 containers running in production with ECS (total count, not uniqueness).

We haven't touched Swarm and are staying a couple versions behind. With that said, we're pretty happy with the setup right now.

View on HN

Airtime is also using ECS to run docker containers in production. We ran into a few issues early on due to early adopter status, but the AWS team was very quick to add many features we needed.

I have no complaints about ECS now, and in fact I'd say that ECS solves a lot of the problems that the author complains here. I'd say that Swarm is not production ready, but docker itself as an engine for running a container is fine. You just need to build your own orchestration layer, or use something like ECS.

More details on Airtime's docker setup here: https://techblog.airtime.com/microservice-continuous-integra...

Maybe things has changed since Apr 2015, but I found ECS pretty limited and K8S solving those limitations. One big issue was container-to-container addressing. It was not available last year when I put an ECS cluster into production. Has it been added since?

Direct container to container communication isn't the recommended pattern when using ECS. Instead you let ECS associate with either a legacy Elastic Load Balancer, or one of the new Application Load Balancers, which can direct requests to different classes of containers based on the request path, allowing you to take a set of containers of different types and meld their http resources together into one API on one domain.

If one container needs to talk to another container of a certain type it just uses the load balancer, and the load balancer takes care of directing the request to the other container which may be on the same machine, or another machine, or maybe even in a different cluster.

Obviously this forces you into a fully stateless design because the load balancer round robins all the requests across random containers, but its very fail proof, and gives you high resiliency.

That doesn't necessarily give you resiliency or fail proof. It's recommended that way because there is no other way with ECS. The reason is that unlike K8S, ECS does not inherently have a service discovery. K8S solved it well with a notion of services and has a built-in load balancer. The design is very solid and doesn't require you to pay for a set of ELB instances every time you want to do that. That is why I asked if ECS has added this. It sounds like it has not.

Yeah ECS is a pretty much just a dumb layer on top of docker that handles two things: placing your containers onto instances (and restarting them or replacing them if needed), and adjusting the settings on an ELB, or ALB so that the load balancer is pointed at an instance running the container.

The ECS approach is a pretty minimal to glue together a cluster of instances running docker and ELB, while Kubernetes has a lot more baked into the core implementation.

I've also used ECS for a production system, and have found it to be an excellent runtime for docker containers.

Reply on news.ycombinator.com