A lot of the products I've seen built that attempt to be made of microservices are actually just a really inefficient monolith. A lot of different "services" that are all completely inter-dependent, or all use one database, or use libraries of the other "services", or use the exact same patterns/tools/templates/build systems/frameworks, or hard-code configuration values from other "services", or are actually stateful. My favorite thing is when one team can't deploy a change because they're waiting on another team to deploy a change.
Microservices Architecture on Google Cloud
11–20 of 49 posts
Re: Microservices Architecture on Google Cloud
#12The comparison between microservices vs monolith was too simplistic and should have mentioned how much harder it is to deal with inconsistencies and distribution when working microservices. You want to be a certain company size before going all in on microservices.
I don't believe that company size has anything to do with whether microservices work. That's the line people are sold, but companies large and small both suck at implementing microservices, and companies large and small can both implement monoliths successfully. I think it really has to come down to the individual case of a given product/project. One product may work way better as one architecture versus another, regardless of how many parts it may involve, due to the context, customers, use cases, organizational model, support model, regulations, etc.
As a general rule, we tend to use the org chart to define our architectures (Conway's Law), but many org charts are just fucked up. We should absolutely fight an architectural design that is mimicking a poor organizational model.
Re: Microservices Architecture on Google Cloud
#13The more services you have, the higher the latency, to a point it is unbearable. So you know what the engineers do? They have to go back and make some services monolithic again. This is also applicable to microkernel model, where everything is almost processes intercommunicating either locally or remotely, but their performance is so bad they are either academically significant only or are simply abandoned. There are…
Consensus based systems aren’t wasting resources if data replication is desired and at least with raft and similar the replicas aren’t continuously trying to obtain the lock.
Re: Microservices Architecture on Google Cloud
#14A lot of the products I've seen built that attempt to be made of microservices are actually just a really inefficient monolith. A lot of different "services" that are all completely inter-dependent, or all use one database, or use libraries of the other "services", or use the exact same patterns/tools/templates/build systems/frameworks, or hard-code configuration values from other "services", or are actually stateful…
The "shared database microservices" antipattern is particularly pernicious. I've seen this a couple of times at enterprises where a mandate comes down from up high to microservice all the things, so they just split the frontend side of monolith into a couple of notionally separate apps but keep the old backend for all state. Ta-dah, microservices!
Re: Microservices Architecture on Google Cloud
#15The more services you have, the higher the latency, to a point it is unbearable. So you know what the engineers do? They have to go back and make some services monolithic again. This is also applicable to microkernel model, where everything is almost processes intercommunicating either locally or remotely, but their performance is so bad they are either academically significant only or are simply abandoned. There are…
> This is also applicable to microkernel model
This isn't a fair comparison. Microkernels can still be performant if done correctly. Syscalls have become slower over time as Spectre/Meltdown mitigations are added.
Re: Microservices Architecture on Google Cloud
#16Earlier quoted context omitted.
Can I find a better reading somewhere else on this?
Martin Fowler has some great comparisons about the two styles: https://www.martinfowler.com/articles/microservice-trade-off...
That's the microservice take; they should also read Monolith First: https://www.martinfowler.com/bliki/MonolithFirst.html
Re: Microservices Architecture on Google Cloud
#17I don't think you can have a serious conversation about microservices without talking about poison messages and ordering guarantees (both with respect to each other and not). What does Pub/Sub provider to deal with those?
(If you're interviewing somewhere and they say they have microservices, ask how they deal with poison messages. The answer can be telling).
Re: Microservices Architecture on Google Cloud
#18pet theory: microservices is a psyop by big tech to make deploying and maintaining software so insanely difficult that future potential competitors are too tied up trying to keep the cloud equivalent of "hello world" afloat to present any real threat
ever tried to scale monolithic development beyond 3 teams?
the point of micro services is simple: to make technical infrastructure resemble the human organization it is designed to support. that’s it.
Re: Microservices Architecture on Google Cloud
#19> It is extremely difficult to change a monolith’s technology or language or framework because all components are tightly coupled and dependent on each other. As a result, even relatively small changes can require lengthy development and deployment times.
I disagree with this so much. I have personally worked with Rails application monoliths and Node.js microservices and I can tell you that making changes on the monolith is muliple times easier mostly depending on the code structure. I would take a properly structured monolith any day. This not only includes code/features but also deployments. Adding more services introduces more complexity in the deployment architecture as well.
A good example of this is just by looking at the GitLab codebase https://gitlab.com/gitlab-org/gitlab, it's a monolith but has good abstractions/structure vs say the Google Microservices Demo app https://github.com/GoogleCloudPlatform/microservices-demo which is not tightly coupled but introduces more complexity from implementation to deployment.
Re: Microservices Architecture on Google Cloud
#20The more services you have, the higher the latency, to a point it is unbearable. So you know what the engineers do? They have to go back and make some services monolithic again. This is also applicable to microkernel model, where everything is almost processes intercommunicating either locally or remotely, but their performance is so bad they are either academically significant only or are simply abandoned. There are…
Microkernels are not a good example. The assertion that they have worse performance in a way that can be meaningfully measured is a rumor, especially since we now have Fuchsia, not even mentioning other microkernels like seL4 and QNX.