this post was submitted on 29 Jul 2023
62 points (93.1% liked)
Programming
17494 readers
121 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
My hot take is that unmaintainable monoliths result from poor system design / too strong coupling. If you can't cleave off portions of your monolith without breaking it you built it wrong in the first place, and the choice between monolith and microservice isn't going to save you. Perhaps starting with a microservice forces people to make (or at least consider) better design choices from the beginning but 1. there is no reason you can't make those same architectural decisions with a monolith and 2. you can still strongly couple microservices with poor design.
Getting back to basics of "what makes for good application development" using good abstractions, Go4 patterns, SOLID / KISS / DRY / etc, means that whether your threads are running colocated vs on another VM vs on another box vs in another datacenter vs in another continent shouldn't affect you much. If your app breaks in ways beyond "I wonder if moving this job to another system means we'll suffer from memory nonlocality or sync latency" the walls are already closing in lol.
Yeah I agree with all of that. Architecture is hard and you don't normally fully understand what you need until you've built it the wrong way.