7 ms·

Really strong language without any backing arguments whatsoever. You can’t just pick some random tech and decide this is boring tech so it’s good and so the oth

Really strong language without any backing arguments whatsoever. You can’t just pick some random tech and decide this is boring tech so it’s good and so the other is bad and has always been. This type of comment is so incredibly meaningless and infuriating. Please explain why you are saying what you’re saying so at least we can learn from it.

mjr00 3y ago
I do think specifying JVM/PG/k8s in that comment was a mistake. Boring tech will be different for different people and companies. Boring tech doesn't just mean it's time-tested and battle-hardened, it means you have deep knowledge across the company because you've used it for so long. I'm in a Python shop, so Python is my boring default tech stack choice. If I introduced C++ into our tech stack, it would be not-boring tech for us, despite C++ not being a cutting edge language. k8s is funny to call "boring tech" because it's notoriously complex. But if your company has set up dozens of k8s clusters and has a bunch of k8s experts on staff, it can be considered "boring tech." It's all relative.
- jpgvm 3y ago
  Yeah probably. I should have specified "sufficiently boring tech stack of choice".
  - dylan604 3y ago
    or append "for example"
jpgvm 3y ago
Serverless actual pros: "infinite" (meaning wallet level) scalability. Integrated deployment tooling usually. Integrated ingress usually. Those last 2 really don't matter though as neither problem is that difficult if you know what you are doing. They both would have been a huge selling point in a world where k8s doesn't exist. Alas it does and thus mostly moot. The first however is a big deal as managing very bursty loads on k8s can actually be a bit of a challenge. This is doubly true when you are using some sort of queue and don't have good queue scaling metrics for whatever reason. Serverless lets you cop out of managing that by using infinite concurrency. Ok so now cons of serverless: Turns all your code into spaghetti, this is probably the biggest one. Cold boot performance is highly varible and generally worsens with added function complexity but this depends on tech choice. Infinite concurrency is a bit of a curse. Want to use that MySQL DB that contains all your business critical data? Better use some MySQL Serverless proxy nonsense because unbounded connections isn't fun. Lock-in is awful, migration story is awful. Amount of Infrastructure as Code overhead, ala Terraform, CloudFormation, whatever else floats your boat to support serverless is insane. The sheer number of objects that need to defined, kept in sync etc is just bonkers. Not to mention if you have multiple services setup like this it's all boilerplate you either need to abstract or carry around. Hides serious programming deficiencies like memory leaks because context is thrown away after servicing request. Unpredictable runtime makes observability more complicated, probably forcing you into poor decisions as a result, i.e prom push gateway. Runtime/execution time limits mean people trying to do all-serverless end up doing horrible things to accomplish long-running tasks. All of the above leads to increasing pressure to make poor architectural decisions to work around limitations of the runtime. I could probably go on but that is a reasonable set for you. EDIT: Actually I forgot the worst con. The cost. The $/CPU/RAM cost of Serverless is beyond bonkers. When I was pricing up Cloud Functions vs Spot instances on GKE I think I came to the conclusion Cloud Functions are about 300x as expensive. If your code can run on serverless it can probably run on Spot instances which you can just add to your GKE deployment using another node pool and only schedule things that can handle nodes going away within 60s there and instantly reap 300x cost savings. This is because Serverless is sold at a massive premium to CPU list prices and Spot is sold at like ~30-40% of list prices depending on machine type (for those curious when I last checked T2D was the best for price/performance for highly single thread performance dependent workloads, ala Node.js)
- kpw94 3y ago
  > cons of serverless: > Turns all your code into spagetti, this is probably the biggest one. Overall agree with you, but I don't think spaghetti is the right term here - even if the typo is corrected :) Spaghetti code is more of a term for monolithic mess where you have a hard time following all the code logic (cyclomatic complexity) and dependencies. Understanding & tracking dependencies is actually easier with serveless, it's pretty clear what dependency that one tiny micro service has. But where it becomes worse is regarding the code logic mess, you've now turned it in a distributed system problem where, in addition to having a even hard time with cyclomatic complexity, you also have to think about transient failures/retries at each service boundaries. That and the other problems you describe (performance hit etc)
  - jpgvm 3y ago
    Yeah I completely agree with all of that.
  - bcrosby95 3y ago
    How about spaghetti architecture.
    - jpgvm 3y ago
      I like that one.
    - hyperhopper 3y ago
      Prior art: https://preview.redd.it/y3pw78z0s3oz.jpg?auto=webp&v=enabled&s=6d65658e38c993ea7bccfc6c0b378262ee98bcd9 https://preview.redd.it/y3pw78z0s3oz.jpg?auto=webp&v=enabled...
  - goalieca 3y ago
    > Spaghetti code is more of a term for monolithic mess where you have a hard time following all the code logic (cyclomatic complexity) and dependencies. I started using distributed monolith.
  - 3y ago
bawolff 3y ago
I think the big thing with "boring" vs "exciting" tech is people pick exciting tech for reasons other than it being a good technical fit (lets board the hype train!!!). Bad results then happen. Boring tech is usually more stable and more mapped out. Everyone knows where its good and where its not. Other people have already had whatever problems you have. I'll always bet on the boring tech over the hyped exciting tech.

mjr00 3y ago

I do think specifying JVM/PG/k8s in that comment was a mistake. Boring tech will be different for different people and companies. Boring tech doesn't just mean it's time-tested and battle-hardened, it means you have deep knowledge across the company because you've used it for so long. I'm in a Python shop, so Python is my boring default tech stack choice. If I introduced C++ into our tech stack, it would be not-boring tech for us, despite C++ not being a cutting edge language. k8s is funny to call "boring tech" because it's notoriously complex. But if your company has set up dozens of k8s clusters and has a bunch of k8s experts on staff, it can be considered "boring tech." It's all relative.

jpgvm 3y ago
Yeah probably. I should have specified "sufficiently boring tech stack of choice".
- dylan604 3y ago
  or append "for example"

jpgvm 3y ago

Serverless actual pros: "infinite" (meaning wallet level) scalability. Integrated deployment tooling usually. Integrated ingress usually. Those last 2 really don't matter though as neither problem is that difficult if you know what you are doing. They both would have been a huge selling point in a world where k8s doesn't exist. Alas it does and thus mostly moot. The first however is a big deal as managing very bursty loads on k8s can actually be a bit of a challenge. This is doubly true when you are using some sort of queue and don't have good queue scaling metrics for whatever reason. Serverless lets you cop out of managing that by using infinite concurrency. Ok so now cons of serverless: Turns all your code into spaghetti, this is probably the biggest one. Cold boot performance is highly varible and generally worsens with added function complexity but this depends on tech choice. Infinite concurrency is a bit of a curse. Want to use that MySQL DB that contains all your business critical data? Better use some MySQL Serverless proxy nonsense because unbounded connections isn't fun. Lock-in is awful, migration story is awful. Amount of Infrastructure as Code overhead, ala Terraform, CloudFormation, whatever else floats your boat to support serverless is insane. The sheer number of objects that need to defined, kept in sync etc is just bonkers. Not to mention if you have multiple services setup like this it's all boilerplate you either need to abstract or carry around. Hides serious programming deficiencies like memory leaks because context is thrown away after servicing request. Unpredictable runtime makes observability more complicated, probably forcing you into poor decisions as a result, i.e prom push gateway. Runtime/execution time limits mean people trying to do all-serverless end up doing horrible things to accomplish long-running tasks. All of the above leads to increasing pressure to make poor architectural decisions to work around limitations of the runtime. I could probably go on but that is a reasonable set for you. EDIT: Actually I forgot the worst con. The cost. The $/CPU/RAM cost of Serverless is beyond bonkers. When I was pricing up Cloud Functions vs Spot instances on GKE I think I came to the conclusion Cloud Functions are about 300x as expensive. If your code can run on serverless it can probably run on Spot instances which you can just add to your GKE deployment using another node pool and only schedule things that can handle nodes going away within 60s there and instantly reap 300x cost savings. This is because Serverless is sold at a massive premium to CPU list prices and Spot is sold at like ~30-40% of list prices depending on machine type (for those curious when I last checked T2D was the best for price/performance for highly single thread performance dependent workloads, ala Node.js)

kpw94 3y ago
> cons of serverless: > Turns all your code into spagetti, this is probably the biggest one. Overall agree with you, but I don't think spaghetti is the right term here - even if the typo is corrected :) Spaghetti code is more of a term for monolithic mess where you have a hard time following all the code logic (cyclomatic complexity) and dependencies. Understanding & tracking dependencies is actually easier with serveless, it's pretty clear what dependency that one tiny micro service has. But where it becomes worse is regarding the code logic mess, you've now turned it in a distributed system problem where, in addition to having a even hard time with cyclomatic complexity, you also have to think about transient failures/retries at each service boundaries. That and the other problems you describe (performance hit etc)
- jpgvm 3y ago
  Yeah I completely agree with all of that.
- bcrosby95 3y ago
  How about spaghetti architecture.
  - jpgvm 3y ago
    I like that one.
  - hyperhopper 3y ago
    Prior art: https://preview.redd.it/y3pw78z0s3oz.jpg?auto=webp&v=enabled&s=6d65658e38c993ea7bccfc6c0b378262ee98bcd9 https://preview.redd.it/y3pw78z0s3oz.jpg?auto=webp&v=enabled...
- goalieca 3y ago
  > Spaghetti code is more of a term for monolithic mess where you have a hard time following all the code logic (cyclomatic complexity) and dependencies. I started using distributed monolith.
- 3y ago

bawolff 3y ago

I think the big thing with "boring" vs "exciting" tech is people pick exciting tech for reasons other than it being a good technical fit (lets board the hype train!!!). Bad results then happen. Boring tech is usually more stable and more mapped out. Everyone knows where its good and where its not. Other people have already had whatever problems you have. I'll always bet on the boring tech over the hyped exciting tech.