[zedpm]

It sounds like they really wanted to switch to K8s and rationalized it. The cons of their existing solution are minor and easily addressed with correct use of Ansible, and the massive complexity of K8s is understated.

As an example, they suggest that there's a heavy cognitive load associated with having devs run some Ansible playbooks, and then argue that to avoid that, they just have to introduce an entirely new toolchain via workshops and tutorials. Right.

[halbritt]

Regardless of your skepticism, the benefits are real.

Scaling applications in k8s, updating, and keeping configs consistent are a great deal easier for me than using Ansible or any other config management tool.

In the end, it's a singular platform that one can build tooling against that allows an organization to abstract away the infrastructure. My team has done that (on top of k8s). As such, a developer can spin up a new environment with the click of a button, deploy whatever code they like, scale the environment, etc. with very little to no training. Those capabilities were a tremendous accelerator for my organization.

Sure, you can build something similar with Ansible on AWS, but then you're married to AWS, you have to worry about sizing, and the cost of idle instances. In my experience, it's just a great deal more overhead.

[falcolas]

With ECS running on Fargate, idle instances don't exist. Throw in service autoscaling, and you have a simple scaling solution with no K8s cluster management required.

[oppositelock]

Or, you use EKS, no k8s cluster management required either.

I'm running a production service on EKS, also tried it on GKE. Both take away most of the cluster management pain.

[halbritt]

Agreed.

[halbritt]

Given the adoption of Kubernetes, would you honestly recommend that someone seriously consider ECS?

[zedpm]

Yeah, I would recommend it in certain circumstances. EKS has $150/month base cost for the control plane, so for small environments it's too expensive. For groups with existing experience with Docker and Docker Compose but no experience with Kubernetes, it's fairly easy to get things working on ECS. If you don't have a whole ops team with time to build out all the tooling to make k8s use easy for devs, then again k8s probably isn't the right answer.

Kubernetes is great, but you're not being honest with yourself if you can't acknowledge the difficulty in going from 0 to production-ready. There is a ton of complexity and lots of grief on the path to a fully functional k8s environment.

[halbritt]

That last part, I wholly agree with. The learning curve is steep and difficult.

[falcolas]

In addition to Zed’s comment, ECS is remarkably mature and for many cases has feature parity with K8s. It’s much more mature and better supported than EKS right now.

Migrating between the two isn’t even all that difficult if you change your mind later.

[user5994461]

You still need ansible to setup the hosts and the databases.

[halbritt]

Not in my environment.

Creating a cluster is a one-liner, no Ansible required. The node pool comes with that, which sets up the hosts. Databases are all created in cluster with a helm chart.

Many people will advise against running stateful workloads in k8s. It's tricky, sure, but the benefits are still there.

As a result of the orchestration my team has built on top of k8s, any developer in my organization can clone any production environment at any time with production data. Those cloned environments can be configured to receive streaming updates from the production environment, once created.

Developers can test bug fixes and features on live streaming production data with absolute certainty that they won't break anything. This capability is immensely valuable.