4 ms·

You probably need to scale the two features — SPA serving and APIs — independently, so you’d deploy them in separate pods. Multi-pod containers should be so tig

You probably need to scale the two features — SPA serving and APIs — independently, so you’d deploy them in separate pods. Multi-pod containers should be so tightly coupled that they should always deploy together. If you can insert decoupling between containers, do it.

yawaramin 5y ago
But it doesn't really make sense for them to scale independently, right? E.g., you would never want the FE to scale higher than the BE, because that would 'starve' the FE. And you wouldn't really want the BE to scale higher than the FE, because why waste the resources? If they scale together, that solves both problems.
- orf 5y ago
  Not at all. They both have different scaling characteristics - serving a static file (assuming you didn’t do it via a CDN for some reason) uses a lot less resources than serving a backend request. If it doesn’t, you’re doing something terribly wrong. If you couple them like you’re suggesting then you’re wasting resources by scaling out your FE serving infrastructure needlessly. And at some point you’ll possibly end up splitting your backend into multiple services. Would you couple a frontend container to each of those?
  - yawaramin 5y ago
    > If you couple them like you’re suggesting then you’re wasting resources by scaling out your FE serving infrastructure needlessly. But if I'm coupling them in the same pod then am I really wasting resources? Aren't pods the equivalent of 'hosts' in the Kubernetes world, i.e. aren't resources allocated at the pod level? And as you said, > serving a static file (assuming you didn’t do it via a CDN for some reason) uses a lot less resources than serving a backend request. If I'm serving static files from the same pod as my backend, the pod shouldn't really need any more resources than if it was just serving the BE, right? > And at some point you’ll possibly end up splitting your backend into multiple services. Would you couple a frontend container to each of those? The most likely scenario in that case would be having a backend-for-frontend pattern, so the FE and its BFF would still go in the same pod, and the other services would probably go in different pods.
    - orf 5y ago
      A pod is a collection of containers. The original suggestion was to pair them, so you’d have a backend container and a frontend container living within the same pod. This is wasteful for the reasons I listed. You can shove the backend and the frontend into the same container, but it’s needless. > The most likely scenario in that case would be having a backend-for-frontend pattern, so the FE and its BFF would still go in the same pod, and the other services would probably go in different pods. They are still two different concerns and don’t need to both be served from the same pod (the BFF pattern doesn’t even remotely require this). You of course can do whatever you want, but shoving different things together (even if coupled via an API) is an anti pattern.
    - HillRat 5y ago
      In general, you wouldn't expect SPA or hybrid-SPA architectures to have scale coupling between the front-end and backend, because you'll be hitting specific APIs more aggressively than you'll be downloading the SPAs (even in a mixed-render environment). In addition, if your backend is serving multiple channels, then you've got another source of incoming requests, and it wouldn't be ideal to spinning up additional webservers when only the business logic tier needs to scale out. In general, the "one container per pod, usually" rule works pretty well. Adding more pods does create additional cognitive complexity, but by the time you need k8s, you really should have someone, or a team of someones, responsible for dealing with that -- I find that too often folks reach for Kubernetes when they could use a simpler container strategy (RIP, somewhat, Docker Swarm).

yawaramin 5y ago

But it doesn't really make sense for them to scale independently, right? E.g., you would never want the FE to scale higher than the BE, because that would 'starve' the FE. And you wouldn't really want the BE to scale higher than the FE, because why waste the resources? If they scale together, that solves both problems.

orf 5y ago
Not at all. They both have different scaling characteristics - serving a static file (assuming you didn’t do it via a CDN for some reason) uses a lot less resources than serving a backend request. If it doesn’t, you’re doing something terribly wrong. If you couple them like you’re suggesting then you’re wasting resources by scaling out your FE serving infrastructure needlessly. And at some point you’ll possibly end up splitting your backend into multiple services. Would you couple a frontend container to each of those?
- yawaramin 5y ago
  > If you couple them like you’re suggesting then you’re wasting resources by scaling out your FE serving infrastructure needlessly. But if I'm coupling them in the same pod then am I really wasting resources? Aren't pods the equivalent of 'hosts' in the Kubernetes world, i.e. aren't resources allocated at the pod level? And as you said, > serving a static file (assuming you didn’t do it via a CDN for some reason) uses a lot less resources than serving a backend request. If I'm serving static files from the same pod as my backend, the pod shouldn't really need any more resources than if it was just serving the BE, right? > And at some point you’ll possibly end up splitting your backend into multiple services. Would you couple a frontend container to each of those? The most likely scenario in that case would be having a backend-for-frontend pattern, so the FE and its BFF would still go in the same pod, and the other services would probably go in different pods.
  - orf 5y ago
    A pod is a collection of containers. The original suggestion was to pair them, so you’d have a backend container and a frontend container living within the same pod. This is wasteful for the reasons I listed. You can shove the backend and the frontend into the same container, but it’s needless. > The most likely scenario in that case would be having a backend-for-frontend pattern, so the FE and its BFF would still go in the same pod, and the other services would probably go in different pods. They are still two different concerns and don’t need to both be served from the same pod (the BFF pattern doesn’t even remotely require this). You of course can do whatever you want, but shoving different things together (even if coupled via an API) is an anti pattern.
  - HillRat 5y ago
    In general, you wouldn't expect SPA or hybrid-SPA architectures to have scale coupling between the front-end and backend, because you'll be hitting specific APIs more aggressively than you'll be downloading the SPAs (even in a mixed-render environment). In addition, if your backend is serving multiple channels, then you've got another source of incoming requests, and it wouldn't be ideal to spinning up additional webservers when only the business logic tier needs to scale out. In general, the "one container per pod, usually" rule works pretty well. Adding more pods does create additional cognitive complexity, but by the time you need k8s, you really should have someone, or a team of someones, responsible for dealing with that -- I find that too often folks reach for Kubernetes when they could use a simpler container strategy (RIP, somewhat, Docker Swarm).