4 ms·
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 A
by zedpm 8y ago
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 8y agoRegardless 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 8y agoWith 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 8y agoOr, 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 8y agoAgreed.
- halbritt 8y agoGiven the adoption of Kubernetes, would you honestly recommend that someone seriously consider ECS?
- zedpm 8y agoYeah, 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 8y agoThat last part, I wholly agree with. The learning curve is steep and difficult.
- falcolas 8y agoIn 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 8y agoYou still need ansible to setup the hosts and the databases.
- halbritt 8y agoNot 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.