5 ms·

How many people actually need this level of scale vs how many people are implementing this because its $BUZZWORD

by geggam 11y ago

amouat 11y ago
You need orchestration even at small scale (say more than 2 nodes). Otherwise you have to manually take care of container scheduling and failover etc.
- dberg 11y ago
  Exactly, the biggest problem with running apps in Containers, is you need to ensure you dont have your entire cluster sitting on one physical node (or virtual node i guess), services can be restart, auto-scaled, etc. Even at a small scale some orchestration and management is required
  - blumkvist 11y ago
    >you need to ensure you dont have your entire cluster sitting on one physical node Why is this the case? My understanding of containers is that they solve exactly this problem - restart, rescale only a fraction of the application (only an individual service).
    - cpitman 11y ago
      Bringing up new containers will always take a finite amount of time. If all of a cluster is deployed to a single host, and that host dies, then the recovery time is the time needed to reschedule the container elsewhere, load it onto the machine (if not cached), and execute it. This is all downtime, since every instance was lost. If instances are on more than one host, then even in the case of a single host's failure the application is still available while the failed instance is rescheduled and started.
zwischenzug 11y ago
You do if you're running an internal paas or DCOS, and a large number of bigger organisations (eg Google...) do because of bin-packing saves on hardware costs. Many don't, of course...
vidarh 11y ago
"This level of scale" is very trivial for some of these. E.g. for fleet, the only dependencies are systemd and etcd. If you have a reachable etcd cluster (which you can run on a single machine, though you shouldn't) and your machines run systemd, and you have key'd ssh access between them, you can pretty much start typing "fleetctl start/stop/status" instead of "systemctl start/stop/status" and feed fleet systemd units and have your jobs spread over your servers with pretty much no effort. For me it's an effortless way to get failover. E.g. "fleetctl start someappserver@{1..3}" to start three instances of someappserver@.service. With the right constraint in the service file they'll be guaranteed to end up on different machines.
ownagefool 11y ago
It's not about scale, it's about manageability. Having a set of uniform nodes where you schedule containers is nicer, in my opinion, than managing an infrastructure where you've scripted applications to go places. Sure, you could make puppet manage containers on uniform nodes but then we're having a massive convention vs configuration argument, which we shouldn't bother with because the distributed schedules are giving us a lot of important stuff for mostly free.

How many people actually need this level of scale vs how many people are implementing this because its $BUZZWORD

by geggam 11y ago

How many people actually need this level of scale vs how many people are implementing this because its $BUZZWORD

You need orchestration even at small scale (say more than 2 nodes). Otherwise you have to manually take care of container scheduling and failover etc.

dberg 11y ago
Exactly, the biggest problem with running apps in Containers, is you need to ensure you dont have your entire cluster sitting on one physical node (or virtual node i guess), services can be restart, auto-scaled, etc. Even at a small scale some orchestration and management is required
- blumkvist 11y ago
  >you need to ensure you dont have your entire cluster sitting on one physical node Why is this the case? My understanding of containers is that they solve exactly this problem - restart, rescale only a fraction of the application (only an individual service).
  - cpitman 11y ago
    Bringing up new containers will always take a finite amount of time. If all of a cluster is deployed to a single host, and that host dies, then the recovery time is the time needed to reschedule the container elsewhere, load it onto the machine (if not cached), and execute it. This is all downtime, since every instance was lost. If instances are on more than one host, then even in the case of a single host's failure the application is still available while the failed instance is rescheduled and started.

zwischenzug 11y ago

You do if you're running an internal paas or DCOS, and a large number of bigger organisations (eg Google...) do because of bin-packing saves on hardware costs. Many don't, of course...

vidarh 11y ago

"This level of scale" is very trivial for some of these. E.g. for fleet, the only dependencies are systemd and etcd. If you have a reachable etcd cluster (which you can run on a single machine, though you shouldn't) and your machines run systemd, and you have key'd ssh access between them, you can pretty much start typing "fleetctl start/stop/status" instead of "systemctl start/stop/status" and feed fleet systemd units and have your jobs spread over your servers with pretty much no effort. For me it's an effortless way to get failover. E.g. "fleetctl start someappserver@{1..3}" to start three instances of someappserver@.service. With the right constraint in the service file they'll be guaranteed to end up on different machines.

ownagefool 11y ago

It's not about scale, it's about manageability. Having a set of uniform nodes where you schedule containers is nicer, in my opinion, than managing an infrastructure where you've scripted applications to go places. Sure, you could make puppet manage containers on uniform nodes but then we're having a massive convention vs configuration argument, which we shouldn't bother with because the distributed schedules are giving us a lot of important stuff for mostly free.