3 ms·

It can be good for software too. Best practices and new ways of working slowly dissolve through other companies as employees move around. Many of the great tech

by pests 2y ago

It can be good for software too. Best practices and new ways of working slowly dissolve through other companies as employees move around. Many of the great technologies invented at the FAANGs eventually get recreated at other companies or in open source because of this movement.

mschuster91 2y ago
> Best practices and new ways of working slowly dissolve through other companies as employees move around. Doesn't help against cargo culting and reinventing wheels Just Because We Can And Have The Money. Just because Google did Kubernetes everyone else followed suit despite there being competitors available (e.g. DCOS, but that one sadly failed because it was utter bananaware). Everyone followed Google for Angular and then went over to Facebook's React, and on the backend side it's Go here and Rust there.
- zappchance 2y ago
  All of those were made to solve problems with their predecessors and I believe that almost every one of them (Angular is debatable) has been a success in moving the needle.
  - mschuster91 2y ago
    > All of those were made to solve problems with their predecessors This is not really a question, yes. But... they're sledgehammers and most of the people used them because "the large ones are doing it" - for a loooot of use cases simpler solutions such as plain old jQuery+SCSS / Portainer or Docker Swarm/Compose would have been more than enough.
- p_l 2y ago
  I have worked with both DCOS and Kubernetes - the latter is way more coordinated and polished, with also better fundamentals underneath. This results in a situation where a lot of different places have logical, reasonable reasons to pick k8s because it matches reasonably well 80% of their needs, and while everyone's 80% is different, there's enough overlap. This pulls in, like frame dragging, others who might not actually need it, but it's not because some scaling memes. In practice, a lot of initial intake for k8s was not bananas scaling arguments, but it actually solving problems for people who either had growing complex messes, or considered the spend associated with "good practices" that are often thrown as argument against kubernetes, like running separate cloud instances for every application. Similarly, everytime I look at Nomad and related stack, it turns out that various bits are missing, and DIY will be harder than with k8s-like stack because it's not properly designed to be extensible.

by pests 2y ago

mschuster91 2y ago

> Best practices and new ways of working slowly dissolve through other companies as employees move around. Doesn't help against cargo culting and reinventing wheels Just Because We Can And Have The Money. Just because Google did Kubernetes everyone else followed suit despite there being competitors available (e.g. DCOS, but that one sadly failed because it was utter bananaware). Everyone followed Google for Angular and then went over to Facebook's React, and on the backend side it's Go here and Rust there.

zappchance 2y ago
All of those were made to solve problems with their predecessors and I believe that almost every one of them (Angular is debatable) has been a success in moving the needle.
- mschuster91 2y ago
  > All of those were made to solve problems with their predecessors This is not really a question, yes. But... they're sledgehammers and most of the people used them because "the large ones are doing it" - for a loooot of use cases simpler solutions such as plain old jQuery+SCSS / Portainer or Docker Swarm/Compose would have been more than enough.
p_l 2y ago
I have worked with both DCOS and Kubernetes - the latter is way more coordinated and polished, with also better fundamentals underneath. This results in a situation where a lot of different places have logical, reasonable reasons to pick k8s because it matches reasonably well 80% of their needs, and while everyone's 80% is different, there's enough overlap. This pulls in, like frame dragging, others who might not actually need it, but it's not because some scaling memes. In practice, a lot of initial intake for k8s was not bananas scaling arguments, but it actually solving problems for people who either had growing complex messes, or considered the spend associated with "good practices" that are often thrown as argument against kubernetes, like running separate cloud instances for every application. Similarly, everytime I look at Nomad and related stack, it turns out that various bits are missing, and DIY will be harder than with k8s-like stack because it's not properly designed to be extensible.