Google cosplay is not business-critical : programmer

[-] thesmokingman@programming.dev 91 points 3 months ago

Absolutes in programming tend to lead to bad designs. This is more a “I’m gonna stir up some shit on Twitter” post than real wisdom.

No microservices usually leads to bloated, tightly coupled logic that ignores business domains
No monoliths usually leads to sprawling microservice deployments with tightly coupled dependencies and flavor-of-the-week new ones
No Kubernetes usually leads to VPS pets or crazy obstacle courses trying to get SSL termination without a million fucking dependencies in a cloud container orchestration system that isn’t as good as Kubernetes
All Kubernetes usually leads to huge SRE costs for a tiny app

The same shit happened last summer when AWS came out with their “we dropped microservices for a monolith and look at our speed increase” article which ignored good design principles. Sometimes you should split things over business domains so you can deploy and code independently. Sometimes Kubernetes is the best way to handle your scale needs. The stories we normally read are about people doing it wrong (eg AWS making a bunch of microservices inside a domain sending fucking gigs of data between what should have been functions in a single service). Inexperienced folks don’t always know when to move from their minimum viable solution to something that can scale. That doesn’t mean you remove these things, it means you train on when you need them.

Should we abandon design patterns because singletons or flywheels aren’t the correct solution all of the time?

[-] TexasDrunk@lemmy.world 22 points 3 months ago

All Kubernetes usually leads to huge SRE costs for a tiny app

Hush, I'm working as an SRE and don't want anyone to figure this out.

[-] thesmokingman@programming.dev 9 points 3 months ago

Add Istio and no one will be able to fire you without fucking up mutual TLS

[-] JoYo@lemmy.ml 13 points 3 months ago

Even if what you say isn't true I'm giving my vote of confidence so I can just shrug whenever someone disagrees with my architecture.

Don't like that I chose a single API server? We're avoiding sprawling microservice deployments with tightly coupled dependencies.

Don't like all the docker containers? We're avoiding bloated, tightly coupled logic that ignores business domains.

[-] thesmokingman@programming.dev 14 points 3 months ago

Monoliths are the answer to bad microservices. Microservices are the answer to bad monoliths. It’s all cyclic and four different architects are going to have fifteen different opinions on how your system should be built. Do the thing that makes sense for your team and try to stay flexible.

[-] suy@programming.dev 10 points 3 months ago

Precisely, Gary Bernhardt has given a talk on ideology. I don't think he's precisely someone who thinks in absolutes. It's just preaching that some stuff is (probably) used more than it should. I've seen way, way, way worse projects that over engineered things and made things slow and unmanageable, than the opposite. Of course, everyone has seen different things, and our perceptions are amplified and biased by that.

[-] docAvid@midwest.social 3 points 3 months ago* (last edited 3 months ago)

Saying that some projects, at some point in their lifecycle, don't need certain things, is not saying that those things have no place. Also, if one can't design a monolith that isn't bloated and tightly coupled, one definitely has no business designing microservices. Using microservices is neither necessary, nor sufficient to achieve decoupling.

Monolithic services are the ideal way to begin a project, as using basic good practices, we can build a service that does many things with minimal coordination, and as it grows and requirements change or are discovered, we can easily refactor to keep things simple. As the software matures, we find the natural service boundaries, and find that certain pieces would perform better if they were separated out and could scale independently, or act asynchronously. Since we have followed good practices, this should usually be a simple matter of removing a class or module to a new service, and replacing it with a facade, such that the rest of the monolith doesn't have to change at all.

[-] Midnitte@beehaw.org 1 points 3 months ago

This is more a “I’m gonna stir up some shit on Twitter” post than real wisdom.

Ah, the irony.

[-] blotz@lemmy.world 65 points 3 months ago

xD just blocked the spammer and all his comments disappeared. Imagine working so hard to spam and it takes 2s to for someone to hide your posts.

[-] LostXOR@fedia.io 32 points 3 months ago

What's even up with that guy? What's he trying to accomplish? Spammers confuse me.

[-] kakes@sh.itjust.works 16 points 3 months ago

Some bored kid, I would assume.

[-] Lemminary@lemmy.world 12 points 3 months ago

I feel like they were banned or something and decided to go scorched Earth on Lemmy

load more comments (1 replies)

[-] quicksand@lemm.ee 17 points 3 months ago

Oop looks like he moved servers. I blocked them on one yesterday and just saw their post again. Oh well, another 2s wasted :p

[-] BakedCatboy@lemmy.ml 17 points 3 months ago

Lemmy really needs pixelfed's naive bayes spam detection, it would be able to easily classify the new accounts after classifying one post as spam, then it would be 0 seconds wasted.

[-] quicksand@lemm.ee 8 points 3 months ago

I know some of those words and agree that that would be better

[-] slazer2au@lemmy.world 5 points 3 months ago

I thought my client was chucking a wobbly with so many removed comments be the same person.

[-] jbk@discuss.tchncs.de 3 points 3 months ago

Couldn't a bot just automate that easily? Especially with how open Lemmy's API probably is

[-] abbadon420@lemm.ee 3 points 3 months ago

2 clicks, reload the thread and it's gone. Easy peasy!

[-] jlh@lemmy.jlh.name 34 points 3 months ago

I mean this is kind of bullshit. There's a lot of things that run in containers these days, and kubernetes is the best way to run containers. If you can do everything with static js or managed services, more power to you, but as soon as you have multiple services talking to each other, you should be using kubernetes, and you should probably consider message queues.

[-] dfyx@lemmy.helios42.de 14 points 3 months ago

I never got into kubernetes but docker swarm mode services (not to be confused with old docker swarm) are pretty similar and they're absolutely amazing for small deployments, even for just a home lab. If there's anything I want to self-host, no matter if it's homeassistant, jellyfin, nextcloud, a mastodon instance, a lemmy instance, GitLab or whatever, I can usually just get a preconfigured container, adjust some lines in a docker-compose.yml to fit my environment and be done with deployment in under 5 minutes without having to worry about dependencies, isolation or most configuration. Same for the stuff I write myself. Most of my stuff has a very simple GitLab CI config of maybe 20 lines and immediately shows up live when I merge my changes into main.

[-] platypode@sh.itjust.works 32 points 3 months ago

I've been migrating one of my company's apps from microservices back to monolithic Java. It's wonderful. I haven't touched a line of yaml in weeks.

[-] clif@lemmy.world 32 points 3 months ago

Currently migrating a massive monolithic Java application to microservices... The circle of life continues.

Want to just swap jobs in ~5 years to keep the cycle going? You can migrate this project back to a Java monolith and I'll migrate your monolith back to micros :D

[-] SmoothLiquidation@lemmy.world 17 points 3 months ago

Honestly this just sounds like periodically refactoring everything to remove cruft can be a good thing. Also, it helps you understand how the existing code works if you change it and not break everything.

[-] supercritical@lemmy.world 12 points 3 months ago

There’s someone at my work who really needs to see this…

[-] 4am@lemm.ee 11 points 3 months ago

Small app developers are all just temporarily embarrassed cloud service providers

[-] sabreW4K3@lazysoci.al 6 points 3 months ago

No lies were told