5 ms·

Kubernetes is the biggest joke. I remember working with a sysadmin who worked for The Guardian provisioning servers remotely as demand spiked. This is pre-AWS.

by cutler 6y ago

Kubernetes is the biggest joke. I remember working with a sysadmin who worked for The Guardian provisioning servers remotely as demand spiked. This is pre-AWS. He used Puppet and remarked that you would only ever need what he was using for managing massive fleets of servers. Then Kubernetes and Docker arrived, which were intended for even bigger deployments in data centres. Before you knew it, just as with SPA's, Kubernetes and Docker became the new requirements for web devs working on simple apps.

Nextgrid 6y ago
Also never underestimate the power of a single bare-metal server. Today everyone seems to be in the clouds (pun intended) and has seemingly accepted the performance of terrible, underprovisioned VMs as the new normal.
- wvenable 6y ago
  Stackoverflow -- the website that every developer uses probably all the time -- is an example of a site running on a very small number of machines efficiently. I'd rather have their architecture than 100's of VMs.
  - systemvoltage 6y ago
    It’s remarkably efficient and simple: https://stackexchange.com/performance https://stackexchange.com/performance For those who are discouraged by the massive complexity of Kubernetes/Terraform and various daunting system design examples of big sites, remember you can scale to a ridiculous levels (barring video or heavy processing apps) with just vertical scaling. Before you need fancy Instagram scale frameworks, you’ll have other things to worry about like appearing in front of congress for a testimony :-)
    - Nextgrid 6y ago
      This is indeed the standard example I refer to to prove my point, and all my personal projects follow this model whenever possible. The huge advantage in addition to performance is that the entire stack is simple enough to fit in your mind, unlike Kubernetes and its infinite amount of moving parts and failure modes.
    - skytreader 6y ago
      Wow. Stack Exchange is a curious case study. I share the general HN sentiment over microservices complexity but just to play devil's advocate... I suspect that server cost in this case is asymptotic. If the (monetary) cost of SE's architecture is F(n) and your typical K8s cluster is G(n), where n is number of users or requests per second, F(n) < G(n) only for very large values of n. As in very large. In essence, the devil's advocate point I'm making is that maybe development converges towards microservices because cloud providers make this option cheaper than traditional servers. We would gladly stay with our monoliths otherwise. I tried to contrive a usage scenario to illustrate this but you know the problem with hypotheticals. And without even a concrete problem domain to theorize on, I can't even ballpark estimate compute requirements. Would love to see someone else's analysis, if anyone can come up with one.
      - mercer 6y ago
        I can't recall reading much on how going for 'the cloud' or 'serverless' saved anyone money. On the other hand, I've read my fair share of horror stories about how costs ballooned and going for the old-fashioned server/VPS ended up being much, much cheaper. The main argument in favor of the 'cloud' is that it's easier to manage (and even that is often questioned).
        skytreader 6y ago
        Monetary savings is basically the main selling point of serverless: https://read.acloud.guru/how-going-serverless-helped-us-reduce-costs-by-70-255adb87b093 https://read.acloud.guru/how-going-serverless-helped-us-redu... https://techbeacon.com/enterprise-it/economics-serverless-computing-real-world-test https://techbeacon.com/enterprise-it/economics-serverless-co... https://medium.com/perfsys-blog/how-serverless-computing-saves-money-2b3450477e15 https://medium.com/perfsys-blog/how-serverless-computing-sav...
      - barrkel 6y ago
        Microservices will add latency because network calls are much slower than in-process calls. Microservices, as an architectural choice, are most properly chosen to manage complexity - product and organizational - almost by brute force, since you really have to work to violate abstraction boundaries when you only have some kind of RPC to work with. To the degree that they can improve performance, it's by removing confounding factors; one service won't slow down another by competing for limited CPU or database bandwidth if they've got their own stack. If you're paying attention, you'll notice that this is going to cost more, not less, because you're allocating excess capacity to prevent noisy neighbour effects. Breaking up a monolith into parts which can scale independently can be done in a way that doesn't require a microservice architecture. For example, use some kind of sharding for the data layer (I'm a fan of Vitess), and two scaling groups, one for processing external API requests (your web server layer), and another for asynchronous background job processing (whether it's a job queue or workers pulling from a message queue or possibly both, depends on the type of app), with dynamic allocation of compute when load increases - this is something where k8s autoscale possibly combined with cluster autoscaling shines. This kind of split doesn't do much for product complexity, or giving different teams the ability to release parts of the product on their own schedule, use heterogeneous technology or have the flexibility to choose their own tech stack for their corner of the big picture, etc.
  - cutler 6y ago
    I haven't looked for a while but Plenty Of Fish (POF) also ran on the same infrastructure and the same framework - ASP.Net. Maybe ASP.Net is particularly suited to this approach?
- icemelt8 6y ago
  In the world of crazy SEO and ridiculous demands by Google for lighthouse score if the page is not static, the competition wins.
- aitchnyu 6y ago
  What about interpreted languages? I was taught a Python web server can do $NUMCPUS+1 concurrent requests and therefore 32 1 CPU VM will perform as well as a 32 CPU VM.
  - Nextgrid 6y ago
    You still have the overhead of the OS. In the first case you’re running 32 instances each with their own OS, the latter you have a single OS to run. Unless high availability is the concern, I’d always recommend a big machine with lots of CPUs than lots of small ones.
te_chris 6y ago
Kubernetes has been great for us and is much easier to manage over time than servers. There’s an adoption cliff, but I’d take kube over spinning your servers with puppet any day. Hell I might even run kube if I was running bare metal. Declarative workloads are amazing.
black3r 6y ago
Kubernetes is overkill for most applications that's true, but Docker is awesome because it solves almost all of the "it works on my machine, doesn't work in prod" and "it worked yesterday, doesn't work today" issues and isn't that hard to adopt.

by cutler 6y ago

Nextgrid 6y ago

Also never underestimate the power of a single bare-metal server. Today everyone seems to be in the clouds (pun intended) and has seemingly accepted the performance of terrible, underprovisioned VMs as the new normal.

wvenable 6y ago
Stackoverflow -- the website that every developer uses probably all the time -- is an example of a site running on a very small number of machines efficiently. I'd rather have their architecture than 100's of VMs.
- systemvoltage 6y ago
  It’s remarkably efficient and simple: https://stackexchange.com/performance https://stackexchange.com/performance For those who are discouraged by the massive complexity of Kubernetes/Terraform and various daunting system design examples of big sites, remember you can scale to a ridiculous levels (barring video or heavy processing apps) with just vertical scaling. Before you need fancy Instagram scale frameworks, you’ll have other things to worry about like appearing in front of congress for a testimony :-)
  - Nextgrid 6y ago
    This is indeed the standard example I refer to to prove my point, and all my personal projects follow this model whenever possible. The huge advantage in addition to performance is that the entire stack is simple enough to fit in your mind, unlike Kubernetes and its infinite amount of moving parts and failure modes.
  - skytreader 6y ago
    Wow. Stack Exchange is a curious case study. I share the general HN sentiment over microservices complexity but just to play devil's advocate... I suspect that server cost in this case is asymptotic. If the (monetary) cost of SE's architecture is F(n) and your typical K8s cluster is G(n), where n is number of users or requests per second, F(n) < G(n) only for very large values of n. As in very large. In essence, the devil's advocate point I'm making is that maybe development converges towards microservices because cloud providers make this option cheaper than traditional servers. We would gladly stay with our monoliths otherwise. I tried to contrive a usage scenario to illustrate this but you know the problem with hypotheticals. And without even a concrete problem domain to theorize on, I can't even ballpark estimate compute requirements. Would love to see someone else's analysis, if anyone can come up with one.
    - mercer 6y ago
      I can't recall reading much on how going for 'the cloud' or 'serverless' saved anyone money. On the other hand, I've read my fair share of horror stories about how costs ballooned and going for the old-fashioned server/VPS ended up being much, much cheaper. The main argument in favor of the 'cloud' is that it's easier to manage (and even that is often questioned).
      - skytreader 6y ago
        Monetary savings is basically the main selling point of serverless: https://read.acloud.guru/how-going-serverless-helped-us-reduce-costs-by-70-255adb87b093 https://read.acloud.guru/how-going-serverless-helped-us-redu... https://techbeacon.com/enterprise-it/economics-serverless-computing-real-world-test https://techbeacon.com/enterprise-it/economics-serverless-co... https://medium.com/perfsys-blog/how-serverless-computing-saves-money-2b3450477e15 https://medium.com/perfsys-blog/how-serverless-computing-sav...
    - barrkel 6y ago
      Microservices will add latency because network calls are much slower than in-process calls. Microservices, as an architectural choice, are most properly chosen to manage complexity - product and organizational - almost by brute force, since you really have to work to violate abstraction boundaries when you only have some kind of RPC to work with. To the degree that they can improve performance, it's by removing confounding factors; one service won't slow down another by competing for limited CPU or database bandwidth if they've got their own stack. If you're paying attention, you'll notice that this is going to cost more, not less, because you're allocating excess capacity to prevent noisy neighbour effects. Breaking up a monolith into parts which can scale independently can be done in a way that doesn't require a microservice architecture. For example, use some kind of sharding for the data layer (I'm a fan of Vitess), and two scaling groups, one for processing external API requests (your web server layer), and another for asynchronous background job processing (whether it's a job queue or workers pulling from a message queue or possibly both, depends on the type of app), with dynamic allocation of compute when load increases - this is something where k8s autoscale possibly combined with cluster autoscaling shines. This kind of split doesn't do much for product complexity, or giving different teams the ability to release parts of the product on their own schedule, use heterogeneous technology or have the flexibility to choose their own tech stack for their corner of the big picture, etc.
- cutler 6y ago
  I haven't looked for a while but Plenty Of Fish (POF) also ran on the same infrastructure and the same framework - ASP.Net. Maybe ASP.Net is particularly suited to this approach?
icemelt8 6y ago
In the world of crazy SEO and ridiculous demands by Google for lighthouse score if the page is not static, the competition wins.
aitchnyu 6y ago
What about interpreted languages? I was taught a Python web server can do $NUMCPUS+1 concurrent requests and therefore 32 1 CPU VM will perform as well as a 32 CPU VM.
- Nextgrid 6y ago
  You still have the overhead of the OS. In the first case you’re running 32 instances each with their own OS, the latter you have a single OS to run. Unless high availability is the concern, I’d always recommend a big machine with lots of CPUs than lots of small ones.

te_chris 6y ago

Kubernetes has been great for us and is much easier to manage over time than servers. There’s an adoption cliff, but I’d take kube over spinning your servers with puppet any day. Hell I might even run kube if I was running bare metal. Declarative workloads are amazing.

black3r 6y ago

Kubernetes is overkill for most applications that's true, but Docker is awesome because it solves almost all of the "it works on my machine, doesn't work in prod" and "it worked yesterday, doesn't work today" issues and isn't that hard to adopt.