My favorite is seeing developers directly reach out to a DB of another microservice because “it’s just easier to pull the data from there”. One of the few times I’ve literally said “bruh”
Even more often the monolith bits are pulled out but continue to share the same monolithic database. The horizontal scanning is void, because while you can make any number of stateless service instances their operations performance is mostly databound and the (relational) database cannot horizontally scale.
A properly architected and implemented microservice architecture optimizes work throughput while minimizing risk. In practice its architecting in such a way that no part can take down the whole individually - the very opposite of a monolith where everything is inseparably interdependent at some level.
Problem is, most organizations don’t know how to properly architect for and integrate microservice architectures into their environments and work process. Most think that a crew of former sysadmins can just spin up a few saas services, slap some autoscaling on it if they’re feeling spicy, segment along traditional monolith “frontend/backend” lines for “security,” and call it a day. They then spend time and money learning and/or fighting this system, only to see minimal (if any) improvement in work capacity/quality and instead end up with an outsized cloud bill.
Problem is, most organizations don’t know how to properly architect for and integrate microservice architectures into their environments and work process.
Which is exactly the same thing said about OOP, or structured programming, or Agile, or a number of other paradigms. Organizations aren’t doing it right, but it works if it’s “properly architected”. Yet, this “proper architecture” doesn’t seem to exist anywhere in the real world.
In fact, I’ve argued before that if OOP is fundamentally about objects ending messages to each other, then microarchitectures are just an approach to OOP where the communication channel is over network sockets.
If you understand things like encapsulation and message passing, then the difference doesn’t come down to microarchitecture vs monolith. It’s self-contained components vs not, and the method of passing messages is only important from a feasibility and performance standpoint.
The reality is, that hardly any projects actually need or benefit from micro services.
Most applications would scale just fine as a monolith, micro services seem to be rather an organizational tool to separate modules, because you can’t come up with a proper architecture.
The problem is, most organizations don’t actually need the very specific benefits that come with microservices and are also in no way equipped to deal with the tremendous increase in complexity that comes along with distributed systems.
This is why I take my job as sales engineer very seriously. If a customer isn’t right for the system they’re far more likely to churn, so I’m going to come out and say it regardless of how it makes sales feel.
At what point does a collection of microservices become a monolith that uses http instead of a bus 🤔
My favorite is seeing developers directly reach out to a DB of another microservice because “it’s just easier to pull the data from there”. One of the few times I’ve literally said “bruh”
Even more often the monolith bits are pulled out but continue to share the same monolithic database. The horizontal scanning is void, because while you can make any number of stateless service instances their operations performance is mostly databound and the (relational) database cannot horizontally scale.
Oh wow, yikes. Yeah, that’s misguided.
A properly architected and implemented microservice architecture optimizes work throughput while minimizing risk. In practice its architecting in such a way that no part can take down the whole individually - the very opposite of a monolith where everything is inseparably interdependent at some level.
Problem is, most organizations don’t know how to properly architect for and integrate microservice architectures into their environments and work process. Most think that a crew of former sysadmins can just spin up a few saas services, slap some autoscaling on it if they’re feeling spicy, segment along traditional monolith “frontend/backend” lines for “security,” and call it a day. They then spend time and money learning and/or fighting this system, only to see minimal (if any) improvement in work capacity/quality and instead end up with an outsized cloud bill.
Which is exactly the same thing said about OOP, or structured programming, or Agile, or a number of other paradigms. Organizations aren’t doing it right, but it works if it’s “properly architected”. Yet, this “proper architecture” doesn’t seem to exist anywhere in the real world.
In fact, I’ve argued before that if OOP is fundamentally about objects ending messages to each other, then microarchitectures are just an approach to OOP where the communication channel is over network sockets.
If you understand things like encapsulation and message passing, then the difference doesn’t come down to microarchitecture vs monolith. It’s self-contained components vs not, and the method of passing messages is only important from a feasibility and performance standpoint.
Laughs in CORBA.
All fair points.
The reality is, that hardly any projects actually need or benefit from micro services.
Most applications would scale just fine as a monolith, micro services seem to be rather an organizational tool to separate modules, because you can’t come up with a proper architecture.
The problem is, most organizations don’t actually need the very specific benefits that come with microservices and are also in no way equipped to deal with the tremendous increase in complexity that comes along with distributed systems.
Worst of both worlds 👍
We only have ten logins a day, but what if UserBirthdayEmailer suddenly needs to go Web scale?
100% agreed. But sales people gotta sell so you end up with “solutions” that create the problem they’re claiming to solve in the first place
This is why I take my job as sales engineer very seriously. If a customer isn’t right for the system they’re far more likely to churn, so I’m going to come out and say it regardless of how it makes sales feel.
INSTANTLY