Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I recommended ECS instead of Kubernetes to my latest customer

leanercloud.beehiiv.com

Post reply on HN
Print view View original

61–70 of 126 posts

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#61

Post by moduspol »

pid-1 wrote: post #58

IMO ECS is in a weird position right now, because: 1 - It's simpler thank K8s, but not that much simpler than your avg managed K8s offering 2 - It really locks you in the AWS ecosystem 3 - It is way less used than K8s or just running things on servers, so there are way less help / learning resources I really don't see how using ECS is much better than EC2 + compose for small setups and this post didn't provide many g…

The IaC / knowledge you need to know to use ECS in a way that replaces EC2 + compose is minimal, bordering on negligible.

I'd use it on day 1 (over EC2 + compose) just to avoid managing an OS or deployment infrastructure.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#62

Post by 20thr »

topspin wrote: post #59

I'm tracking cloud-hypervisor and kata containers closely. I'm convinced there is a unicorn opportunity here for the SME/private-cloud world. An easily managed cluster of lightweight, live-migratable, hardware isolated VMs running containers (as opposed to just herding containers) solves problems people actually have, as opposed to the problems k8s solves. k8s is fine for the scale of enterprise for which it is actua…

We have a similar vision at namespace.so; we are starting with development and testing. But that’s the start.

(disclaimer: I’m part of the team)

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#63

Post by interroboink »

sigstoat wrote: post #13
itsmemattchung wrote: post #2

> When looking at the cloud resources, we noticed many On-Demand EC2 instances with relatively low CPU utilization, which can be expected considering they don't have customers yet. As a software consultant myself, I'd probably stop the conversation right there and ask why they are building such a robust distributed system — SQS, SNS, etc — without any customers. Still want to be deployed in AWS? Toss the damn app on…

i had a client who was burning… $10k? maybe $20k per month largely on nodes for EKS when they had no paying customers and ~zero load. (they had fully “production” sized clusters in all of their environments, and they had a slew of weird not-quite-prod environments.) they also had some rabbitmq-on-k8s system going that fell over during small tests because they couldn’t get k8s to actually scale it. (which then convinc…

The promise of cloud infrastructure is that it can scale to fit demand — start small, and grow as needed. But sometimes the truth is that it just lets people spend money more easily (:

Back in the day, it would have required a whole procedure to buy that hardware, have it set up, etc. Now you can needlessly spend $10k per month with just a few clicks!

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#64

Post by dabeeeenster »

pid-1 wrote: post #58

IMO ECS is in a weird position right now, because: 1 - It's simpler thank K8s, but not that much simpler than your avg managed K8s offering 2 - It really locks you in the AWS ecosystem 3 - It is way less used than K8s or just running things on servers, so there are way less help / learning resources I really don't see how using ECS is much better than EC2 + compose for small setups and this post didn't provide many g…

ECS is just docker instances. I don't really see how that locks you in.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#65

Post by moduspol »

NovemberWhiskey wrote: post #39
lapser wrote: post #33

I find it really wild that anyone would ever recommend ECS. A developer deploying a service involves: - Setting up certs (managed as TF) - Setting up ALBs (managed as TF) - Setting up the actual service definition (often done as a JSON, that is passed into TF) Possibly other things I'm forgetting. Some other things. It requires a *developer* to know about certs and ALBs and whatever else. With EKS, this can all be au…

That seems a strange way to look at things to me. If you're going to give credit for things that a devops engineer can do inside the Kubernetes platform, why not given equivalent credit for what a devops engineer can do with a Terraform module that would achieve substantially similar levels of automation and integration with ECS?

Also weird to leave out which things are versioned things that must be installed, maintained, and upgraded by you (e.g. cert-manager, an ALB controller, the Kubernetes control plane) that do not apply to a Terraform (or CloudFormation)-based deployment to ECS.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#66

Post by cmbothwell »

fnordpiglet wrote: post #51
danpalmer wrote: post #7

More accurately: "Given using AWS as a requirement, I recommended ECS instead of K8s". It's not really surprising that AWS's K8S setup isn't great, and their own implementation ties in more closely with other services they offer. It's lock-in. AWS provides just enough K8S to tick the box on a spec sheet, but have little incentive to go beyond that.

As someone who sat in on the product development discussions at aws about EKS the internal view was K8S was: * a lock in strategy by Google to substitute for the fact they don’t yet have systemic abstractions at a provider level. By “owning” the design and engineering around k8s through capture they can ensure the backing services they build in gcp naturally support k8s users as they develop their roadmap * the provi…

Not sure why you’re being downvoted, this is a very interesting history.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#67

Post by justrealist »

itsmemattchung wrote: post #2

> When looking at the cloud resources, we noticed many On-Demand EC2 instances with relatively low CPU utilization, which can be expected considering they don't have customers yet. As a software consultant myself, I'd probably stop the conversation right there and ask why they are building such a robust distributed system — SQS, SNS, etc — without any customers. Still want to be deployed in AWS? Toss the damn app on…

SQS and SNS are a perfectly good primitives for building a robust distributed system that costs $0 when not in use, by triggering compute via Lambda or Batch.

Your comment is really pretty ignorant of how these tools interact. Using serverless primitives is the opposite of leaving nodes running for no reason.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#68

Post by mlhpdx »

fnordpiglet wrote: post #53
mlhpdx wrote: post #44

Earlier quoted context omitted.

For me, setting up connections between SQS, SNS, DDB, Lambda, step functions, S3, Route53, API Gateway in CloudFormation is just a muscle memory. I’m much faster at it at this point that I am at standing up an EC2. I agree it can be hard to learn, but it certainly isn’t hard to do. Elsewhere in the comments, there’s a suggestion that this kind of thing isn’t appropriate for “hobby projects” and early stage but I disa…

Your muscles must be tuned to enormous amounts of IAM-fu ;-)

Indeed. One of the hard things to figure out is the keeping the number of roles small while avoiding stars (IAM ain’t GitHub).

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#69

Post by bdcravens »

honkycat wrote: post #36

I was not convinced by this article that ECS was the right choice. It felt more like a contrarian choice. > ECS is also relatively simple and not so far from their Docker-compose setup, but much more flexible and scalable. It also enables us to convert their somewhat stateful pets to identically looking stateless cattle that could be converted to Spot instances later. Have you ever built something in ECS? I have, and…

> What you DON'T get with ECS is awesome working-out-of-the-box open source software like External Secrets, External DNS, LetsEncrypt, the Amazon Ingress Controller, argo rollouts, services, ingresses, cronjobs... I could go on and on.

The AWS ecosystem has much of this baked-in. (Parameter Store, Certificate Manager, etc) Vendor lock-in is of course a concern, but for many, a theoretical one.

Re: Why I recommended ECS instead of Kubernetes to my latest customer

#70

Post by jpgvm »

tedivm wrote: post #42
lapser wrote: post #33

I find it really wild that anyone would ever recommend ECS. A developer deploying a service involves: - Setting up certs (managed as TF) - Setting up ALBs (managed as TF) - Setting up the actual service definition (often done as a JSON, that is passed into TF) Possibly other things I'm forgetting. Some other things. It requires a *developer* to know about certs and ALBs and whatever else. With EKS, this can all be au…

I honestly don't understand where you're coming from. If a devops engineer can set things up on eks for people to launch without thinking of those things, what's stopping that same engineer from doing similar for ecs? When I was at Rad AI we went with ECS. I made a terraform module that handled literally everything you're talking about, and developers were able to use that to launch to ECS without even having to thin…

Handing Terraform to developers has it's own host of issues.

A major benefit of k8s that is usually massively overlooked is it's RBAC system and specifically how nice a namespace per team or per service model can be.

It's probably not something a lot of people think about until they need to handle compliance and controls for SOC II and friends but as someone that has done many such audits it's always been great to be able to simply show exactly how can do what on which service in which environment in a completely declarative way.

You can try achieve the same things with AWS IAM but the sheer complexity of it makes it hard to sell to auditors which have come to associate "Terraform == god powers" and convincing them that you have locked it down enough to safely hand to app teams is... tiresome.

Post reply on HN