Hacker News Reader

Comment by sontek | Hacker News Reader

  > On AWS, that would be Fargate on ECS, or on Google Cloud, Google Cloud Run.
  > You won't have to manage servers, network overlays, logging, or other necessary middleware.

I disagree with this take. EKS is a managed service just like Fargate and you have to learn how to manage both equally (VPCs, CIDR ranges, IAM rules, etc). You might as well start on kubernetes if you are going to switch to it eventually.

  > I'd suggest that teams adopting Kubernetes (even the managed versions) have an SRE team, or at minimum, a dedicated SRE engineer.

I'd love to hear what parts of running EKS require an SRE team and how Fargate/ECS solve that issue and make it self-serviceable.

View on HN

If your developers already have a basic understanding of AWS, the APIs are more similar between ECS and other AWS services. K8s introduces an unrelated API nested inside other Amazon APIs. Imo ECS service setup is a simpler interface/API and the load balancer integration is very good.

K8s can go a lot of different ways depending on the type of LB and whether you opt for ingress and whether your ingress is cloud provided or runs in your cluster.

Same with logging. ECS you just configure a log group and get persistent logging and basic aggregated searching with Cloudwatch Insights. K8s you get ephemeral, unaggregated logs unless you introduce additional tools.

When I worked with ECS, it was originally setup by software engineers and it was scripted using the AWS SDK and worked almost exactly the same as the rest of the stack that used things like S3.

Starting with k8s would require learning a new SDK/API versus some new endpoints in the one you're already working with.

On the other hand, as we grew, we'd hit weird issues like ECS nodes going dead without the backplane rescheduling containers on working hosts (I think they've improved ECS agent health checks since then, though)

But if we are comparing apples to apples, you would just use AWS provided stuff for EKS right?

  > K8s can go a lot of different ways depending on the type of LB

k8s flexibility shouldn't be counted against it here. If you are considering k8s against fargate, you should only be considering ALB / NLB ingress and not the many more ways you could. Just use what AWS provides and be happy with it :)

  > ECS you just configure a log group and get persistent logging and basic aggregated searching with Cloudwatch Insights

You can log to cloud watch with EKS as well. Fluentd can log to cloudwatch with very little configuration.

I agree that if you are already "all AWS" and just want to put one more thing in there, Fargate might match your existing patterns better. But saying "Fargate is easier than managed kubernetes" is very wrong.

In general I've seen people have an easier time understanding kubernetes manifests for declaring their services instead of the equivalent terraform to get fargate up and running to do the job.

Fargate is a subset of ECS that uses fully managed VMs. We used our own ASGs with the AWS provided ECS optimized AMI.

Even adding fluent-bit is more software to manage. ECS uses the Cloudwatch Logs driver integrated directly in Docker with full support by AWS. Fluent-bit adds another layer of buffering, permissions, and resource usage you have to account for

Even using AWS provided stuff there's at least 4 ways to put nodes in your cluster (manually managed ASGs, cluster autoscaler managed ASGs, EKS managed node groups, Karpenter)

Reply on news.ycombinator.com