4 ms·

> Kubernetes gives infra teams scalability superpowers Gives nightmares too. Im sticking with Fargate, full, native IaaC support, feature parity with k8s. Or p

by nuker 4y ago

> Kubernetes gives infra teams scalability superpowers Gives nightmares too. Im sticking with Fargate, full, native IaaC support, feature parity with k8s. Or plain EC2s in ASG.

dividedbyzero 4y ago
Fargate has full feature parity with Kubernetes? Is that true? Also, what exactly is "full, native IaaC support" in this case, compared to e.g. EKS?
- nuker 4y ago
  I meant ECS with fargate launch-type, of course. IaaC support is you can use single CFN template to deploy autoscaled service, with load balancing and run time parameters. No kubectl or helm needed.
  - dividedbyzero 4y ago
    Question stands for ECS too, does it actually have full feature parity by now? Last time I used it it was still more limited.
    - nuker 4y ago
      Give me one, not too esoteric plz
    - crgwbr 4y ago
      I’m sure it doesn’t have “full” feature parity, but do you really need 100% of k8s’ features? ECS is a lot simpler to work with and has plenty of features for most systems.
      - jnsaff2 4y ago
        So like Full Self Driving?
maccard 4y ago
I don't think you need to take the advice of "use Kubernetes" as a literal "there are no other options", but more as along the lines of "use an existing implementation that you will be able to hire engineers to maintain, rather than a kludge of batch scripts and home rolled abstractions" > Im sticking with Fargate, full, native IaaC support, feature parity with k8s Fargate by itself doesn't provide anything that k8s does, ecs does. You can run k8s on fargate via EKS, for example. > Or plain EC2s in ASG. This is exactly what this post is saying not to do. ASG's are a subset of the features of k8s. k8s does load balancing, service discovery, deployments, health checks for example. You may not need all of those, and that's fine, but most containerised applications IME benefit from the _majority_ of k8s features.
- nuker 4y ago
  > I don't think you need to take the advice of "use Kubernetes" as a literal "there are no other options" It looks pretty literal there. And why everyone talks about service discovery? Put an LB in front of your app instances and give it DNS name. Here, sorted, no service discovery needed, service is reachable at this URI only.
  - maccard 4y ago
    > And why everyone talks about service discovery? Because service discovery is pretty much the next problem that people find themselves facing once they've decided to not use kubernetes or ECS or something, and it's also something that it solves very well, without relying on DNS with all its quirks. To use my favourite saying, "it's always DNS". > Put an LB in front of your app instances and give it DNS name. Here, sorted, no service discovery needed, service is reachable at this URI only. Dumping a service behind a load balancer and relying on DNS is a heavy handed approach. Sure it's "simple", for some definitions of the word simple, but so is writing 3 60 lines of yaml and/or terraform to spin up an eks or ECS cluster
  - nine_k 4y ago
    When you spin more instances as load grows, what updates the DNS? When you have more than one service interacting, or when your LB restarts / fails over, what updates the DNS? Here's where service discovery enters the picture. It needs not be excessively complex.
pjmlp 4y ago
For .NET folks, Dapr.
- jen20 4y ago
  Not to be confused with the _other_ “Dapper” that .NET folks may be familiar with! [1] [1]: https://github.com/DapperLib/Dapper https://github.com/DapperLib/Dapper
viridian 4y ago
What is IaaC? Infrastructure as a container?

by nuker 4y ago

> Kubernetes gives infra teams scalability superpowers Gives nightmares too. Im sticking with Fargate, full, native IaaC support, feature parity with k8s. Or plain EC2s in ASG.

dividedbyzero 4y ago

Fargate has full feature parity with Kubernetes? Is that true? Also, what exactly is "full, native IaaC support" in this case, compared to e.g. EKS?

nuker 4y ago
I meant ECS with fargate launch-type, of course. IaaC support is you can use single CFN template to deploy autoscaled service, with load balancing and run time parameters. No kubectl or helm needed.
- dividedbyzero 4y ago
  Question stands for ECS too, does it actually have full feature parity by now? Last time I used it it was still more limited.
  - nuker 4y ago
    Give me one, not too esoteric plz
  - crgwbr 4y ago
    I’m sure it doesn’t have “full” feature parity, but do you really need 100% of k8s’ features? ECS is a lot simpler to work with and has plenty of features for most systems.
    - jnsaff2 4y ago
      So like Full Self Driving?

maccard 4y ago

I don't think you need to take the advice of "use Kubernetes" as a literal "there are no other options", but more as along the lines of "use an existing implementation that you will be able to hire engineers to maintain, rather than a kludge of batch scripts and home rolled abstractions" > Im sticking with Fargate, full, native IaaC support, feature parity with k8s Fargate by itself doesn't provide anything that k8s does, ecs does. You can run k8s on fargate via EKS, for example. > Or plain EC2s in ASG. This is exactly what this post is saying not to do. ASG's are a subset of the features of k8s. k8s does load balancing, service discovery, deployments, health checks for example. You may not need all of those, and that's fine, but most containerised applications IME benefit from the _majority_ of k8s features.

nuker 4y ago
> I don't think you need to take the advice of "use Kubernetes" as a literal "there are no other options" It looks pretty literal there. And why everyone talks about service discovery? Put an LB in front of your app instances and give it DNS name. Here, sorted, no service discovery needed, service is reachable at this URI only.
- maccard 4y ago
  > And why everyone talks about service discovery? Because service discovery is pretty much the next problem that people find themselves facing once they've decided to not use kubernetes or ECS or something, and it's also something that it solves very well, without relying on DNS with all its quirks. To use my favourite saying, "it's always DNS". > Put an LB in front of your app instances and give it DNS name. Here, sorted, no service discovery needed, service is reachable at this URI only. Dumping a service behind a load balancer and relying on DNS is a heavy handed approach. Sure it's "simple", for some definitions of the word simple, but so is writing 3 60 lines of yaml and/or terraform to spin up an eks or ECS cluster
- nine_k 4y ago
  When you spin more instances as load grows, what updates the DNS? When you have more than one service interacting, or when your LB restarts / fails over, what updates the DNS? Here's where service discovery enters the picture. It needs not be excessively complex.

pjmlp 4y ago

For .NET folks, Dapr.

jen20 4y ago
Not to be confused with the _other_ “Dapper” that .NET folks may be familiar with! [1] [1]: https://github.com/DapperLib/Dapper https://github.com/DapperLib/Dapper

viridian 4y ago

What is IaaC? Infrastructure as a container?