211–220 of 356 posts
Earlier quoted context omitted.
> the situation where those APIs and team boundaries are exclusively (or at least primarily) composed of separate applications communicating over the network
Are you, perhaps, not familiar with Conway's Law?
Microservice architecture splits the functionality farther, than Conway's law talks about. When a single team owns 4-5 microservices - that's beyond Conway's law.
There are a few gripes I have with microservices. I think most places rearchitect to microservices because it’s the new shiny. They don’t do the engineering necessary to create a detailed cost/benefit analysis, they just feel it will be better and so they jump in. For the same reasons the companies don’t do the cost/benefit analysis they don’t spend much time thinking about how they could benefit from rearchitecting…
In my experience, most places rearchitect to microservices because they have a shitty monolith that they are dealing with. The monolith has been built over a span of 10+ years. It is fragile, brittle, no one understands how the whole thing works, and large scale refactoring without widespread breakage is near impossible. No one wants to touch it because no one understands how the whole thing works. Because of this th…
It's true the lack of bounded contexts is a big problem. But I also see a lot of orchestration services with multiple dependencies on other services, some of which are themselves orchestration services. This quickly cascades into dependency hell only you don't get the benefit of a compiler to alert you to the problems.
Earlier quoted context omitted.
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.
We learned in the 90s to not distribute the objects and instead just spin up more copied of the whole application. And if only scalability is the point this is still valid.
It has become more and more true each passing year.
Earlier quoted context omitted.
Are you, perhaps, not familiar with Conway's Law?
Conway's law doesn't apply to microservice architecture. Microservice architecture splits the functionality farther, than Conway's law talks about. When a single team owns 4-5 microservices - that's beyond Conway's law.
I really do not understand the debate on monoliths and microservice anymore. 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…
An important part of programming as a discipline is coming up with things that work regardless of context.
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…
The main reason is to stop crap developers using globals all over the place, or passing around hash maps stuffed full of config that aren't clearly defined in one place just continually mutated (and similar bad issues). Still, crap devs will just find their own ways to mess up with microservices, but at least they limit the blast radius.
Are there any architectures which would allow you to monolithize services like this? Changing product requirements sometimes mean you've just arrived at a better abstraction, which may need you to combine services directly.
Earlier quoted context omitted.
> the situation where those APIs and team boundaries are exclusively (or at least primarily) composed of separate applications communicating over the network
Are you, perhaps, not familiar with Conway's Law?
I really do not understand the debate on monoliths and microservice anymore. 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…
An important part of programming as a discipline is coming up with things that work regardless of context.
Let's say we're deciding between floating point arithmetics, fixed decimal numbers, or rational numbers. All three of which are very well-established and useful solutions to the problem of subdividing integers. We have some context already here, and we'll need to provide a bit more context to know which solution to choose. Would you agree with that?