4 ms·

Yes, k8s is an abstraction, and it's a useful one, even though not everyone needs it. At this new level of abstraction, your hardware becomes homogeneous, makin

Yes, k8s is an abstraction, and it's a useful one, even though not everyone needs it. At this new level of abstraction, your hardware becomes homogeneous, making it trivial to scale and recover from hardware failures since k8s automatically distributes your application instances across the hardware in a unified manner. It also has many other useful capabilities downstream of that (e.g. zero downtime deployment/rollback/restart). There's not really any other (well supported) alternative if you want that. Of course, most organizations don't need it, but it's very nice to have in a service oriented system.

zug_zug 2y ago
> There's not really any other (well supported) alternative if you want that You don't think AWS autoscale groups give you both of those things?
- stouset 2y ago
  I think you comically underestimate what Kubernetes provides. Autoscaling groups give you instances, but Kubernetes automatically and transparently distributes all your running services, jobs, and other workloads across all those instances. Amongst a laundry list of other things.
  - zug_zug 2y ago
    I think you’re comically misunderstanding what 95% of companies actually are doing with kubernetes
    - hadlock 2y ago
      A big part of what kubernetes provides is a standard interface. When your infra guy gets hit by a bus, someone else (like a contractor) can plug in blindly and at least grasp the system in a day or two.
- root_axis 2y ago
  Nothing wrong with ASGs, but they're not really comparable to k8s. k8s isn't simply "scaling", it's a higher level of abstraction that has granular control and understanding of your application instances in a manner that allows it to efficiently spread workloads across all your hardware automatically, all while managing service discovery, routing, lb, rollbacks and countless more. Comparing it to ASG suggests you may not be that familiar with k8s. I think it's fair to argue that k8s is overkill for many or even most organizations, but ASG is not even close to an alternative.
  - roncesvalles 2y ago
    It seems that you don't understand ASGs. They do all the things that you listed. K8s is essential when working with a fleet of bare metals. It's an unneeded abstraction if you're just going to deploy it on AWS or similar.
- enoent 2y ago
  AWS autoscaling does not take your application logic into account, which means that aggresive downscaling will, at worst, lead your applications to fail. I'll give a specific example with Apache Spark: AWS provides a managed cluster via EMR. You can configure your task nodes (i.e. instances that run the bulk of your submitted jobs to Spark) to be autoscaled. If these jobs fetch data from managed databases, you might have RDS configured with autoscaling read replicas to support higher volume queries. What I've frequently see happening: tasks fail because the task node instances were downscaled at the end of the job, because they are no longer consuming enough resources to stay up, but the tasks themselves haven't finished. Or tasks failed because database connections were suddenly cut off, since RDS read replicas were no longer transmitting enough data to stay up. The workaround is to have a fixed number of instances up, and pay the costs you were trying to avoid in the first place. Or you could have an autoscaling mechanism that is aware of your application state, which is what k8s enables.
  - zug_zug 2y ago
    Asgs can do both of those things, it’s a 5% use-case so it takes a little more work but not much
    - enoent 2y ago
      Can you elaborate on that "little more work", given that resizing on demand isn't sufficient for this use-case, and predictive scaling is also out of the question?
  - znpy 2y ago
    > since RDS read replicas were no longer transmitting enough data to stay up. As an infra guy, I’ve seen similar things happening multiple times. This could be a non problem if developers handled the connection lost case, reconnection with retries and stuff. But most developers just don’t bother. So we’re often building elastic infrastructure that is consumed by people that write code as if we were still on the late 90ies with the single instance dbs expected to be always available.

zug_zug 2y ago

> There's not really any other (well supported) alternative if you want that You don't think AWS autoscale groups give you both of those things?

stouset 2y ago
I think you comically underestimate what Kubernetes provides. Autoscaling groups give you instances, but Kubernetes automatically and transparently distributes all your running services, jobs, and other workloads across all those instances. Amongst a laundry list of other things.
- zug_zug 2y ago
  I think you’re comically misunderstanding what 95% of companies actually are doing with kubernetes
  - hadlock 2y ago
    A big part of what kubernetes provides is a standard interface. When your infra guy gets hit by a bus, someone else (like a contractor) can plug in blindly and at least grasp the system in a day or two.
root_axis 2y ago
Nothing wrong with ASGs, but they're not really comparable to k8s. k8s isn't simply "scaling", it's a higher level of abstraction that has granular control and understanding of your application instances in a manner that allows it to efficiently spread workloads across all your hardware automatically, all while managing service discovery, routing, lb, rollbacks and countless more. Comparing it to ASG suggests you may not be that familiar with k8s. I think it's fair to argue that k8s is overkill for many or even most organizations, but ASG is not even close to an alternative.
- roncesvalles 2y ago
  It seems that you don't understand ASGs. They do all the things that you listed. K8s is essential when working with a fleet of bare metals. It's an unneeded abstraction if you're just going to deploy it on AWS or similar.
enoent 2y ago
AWS autoscaling does not take your application logic into account, which means that aggresive downscaling will, at worst, lead your applications to fail. I'll give a specific example with Apache Spark: AWS provides a managed cluster via EMR. You can configure your task nodes (i.e. instances that run the bulk of your submitted jobs to Spark) to be autoscaled. If these jobs fetch data from managed databases, you might have RDS configured with autoscaling read replicas to support higher volume queries. What I've frequently see happening: tasks fail because the task node instances were downscaled at the end of the job, because they are no longer consuming enough resources to stay up, but the tasks themselves haven't finished. Or tasks failed because database connections were suddenly cut off, since RDS read replicas were no longer transmitting enough data to stay up. The workaround is to have a fixed number of instances up, and pay the costs you were trying to avoid in the first place. Or you could have an autoscaling mechanism that is aware of your application state, which is what k8s enables.
- zug_zug 2y ago
  Asgs can do both of those things, it’s a 5% use-case so it takes a little more work but not much
  - enoent 2y ago
    Can you elaborate on that "little more work", given that resizing on demand isn't sufficient for this use-case, and predictive scaling is also out of the question?
- znpy 2y ago
  > since RDS read replicas were no longer transmitting enough data to stay up. As an infra guy, I’ve seen similar things happening multiple times. This could be a non problem if developers handled the connection lost case, reconnection with retries and stuff. But most developers just don’t bother. So we’re often building elastic infrastructure that is consumed by people that write code as if we were still on the late 90ies with the single instance dbs expected to be always available.