151–160 of 356 posts
The idea that an org that has hard time maintaining a properly structured monolith, will solve it's problems by shifting to building a distributed system was always strange to me.
The distributed system has benefits that the monolith doesn't, like scalability and resilience to failures though it opens doors to new kinds of failures.
No, they aren't. The entire point of the big ball of mud is that there are no meaningful divisions in the code. Everything uses everything willy-nilly, at the smallest possible level of abstraction. There is, metaphorically if not always entirely literally, not a single line of code in the system that you can change without fear of bringing something else down that you may not have even known they existed. Microservi…
This is bit of a strawman. The equivalent strawman criticism for microservices is that every function runs in its own networked service. Is that truly representative of the reality? Of course not, and neither is your breakdown of big ball of mud.
I think this is a fair analysis of the BBOM:
Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?
Scalability and stability. You need to process more requests? Launch more virtual machines, easy. Your microservice is a shit and it crashes every second? Don't care, it will be relaunched automatically.
Also in many cases work should not be performed synchronously in response to http requests but in a background queue to keep your service robust and responsive. When taking a new order you should just place it in some queue and respond ASAP so there is zero chance you miss a customer order because of some error. In that case there is no difference in scaling a monolith or microservice as you can indepedently deploy 25 consumers for module X events or 10 consumers for module Y events and so on.
Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?
> Why have a single database when we can silo our data across 200 mini databases? First, many orgs using, say, Kubernetes still run their database separately in a traditional way with replicas etc. Second, those who do run their DB inside Kubernetes, probably using an operator, gain scalability and additional resiliency (it also depends on the DB, but these days even PostgreSQL operator works quite reliably).
Earlier quoted context omitted.
The move to microservices is often more about scaling change management when an organization grows from tens to hundreds of engineers. Change management becomes the bottleneck when organizations exceed Dunbar's Number, and a "reverse Conway maneuver" is needed to counter excessive cost of coordination. https://cloud.google.com/architecture/devops/devops-tech-arc...
Linux kernel has a huge amount of contributors with their own goals and they seem to coordinate just fine. Monoliths can scale, but they can't be "owned"/leveraged by leaders/sociopaths into a bigger budget/team/etc, IMO.
There are also huge maintenance burdens that come from the lack of stable interfaces for modules. There is a reason there is a lot of excitement around ebpf. It is providing the sort of scaling that people have been needing for a while.
Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?
So you embed S3 into your app? Do you embed your ERP system? How about your marketing e-mail system? Your CRM? Do you use an in-process database? Everyone already has a service based architecture whether they want to admit it or not. The question is the efficiency and granularity of it. If you interface with any external systems that have data records (ERP, CRM, etc), your database is already spread out. You need to…
I'd rather work on a good monolith than a bad microservice and vice versa.
The problem is, working on a bad monolith is almost impossible. I'd rather work on a bad microservice than a bad monolith. Now... tbh this could be survivorship bias where I've never had to help with a well-running monolith, fair... but at the end of the day, I find microservices much easier to manage scope, change and scale.
Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore.
Should you spilt your system into as many pieces as possible?
No, of course not.
You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request. Or maybe you are, because context matters and I'm wrong in your particular case. Could be.
My advice would be to split your application up into enough pices so that;
1.your engineers feels like they have control over the code and are not afraid of doing changes.
2. if you get uptime issues. Get the heavy / unrealiable services over to new node. Don't let one service/endpoint take down other endpoints.
Think and act according to the problems you have in front of you. Don't go extreme in any direction. Context context context
Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?
The move to microservices is often more about scaling change management when an organization grows from tens to hundreds of engineers. Change management becomes the bottleneck when organizations exceed Dunbar's Number, and a "reverse Conway maneuver" is needed to counter excessive cost of coordination. https://cloud.google.com/architecture/devops/devops-tech-arc...
Don’t you find it weird that everybody else is either over or underengineering, but you , you engineer things exactly the right amount? I bet when you’re driving, you also tend to notice that everyone else is either an idiot driving way too slow in the middle lane or a maniac speeding past you. Nobody else drives as well as you do. It must be exhausting for these people to live in a world surrounded by strawmen, whil…
Don't you find it strange that YOU live in a world where everyone else but YOU thinks that everyone else around them is over engineering or under engineering things? You're not the guy who thinks everyone else is a maniac and is driving too fast or too slow. You're the guy who thinks everyone but you is under this delusion of thinking that everyone else is a maniac and you think you are an exception to the delusion b…
Finding the right abstraction is often an incremental process made of tradeoffs on a case by case basis. It doesn't really help to make absolute statements.