61–70 of 139 posts
Earlier quoted context omitted.
> When I call a function there is no chance it fails I like to print statements like this one and put them in a frame on the wall.
Fails because the function is unreachable. The second half of the sentence you quoted says exactly that, why did you cut it out?
Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call. I guess the benefit of microservices is the ability to independently scale different microservices, being able to choose different languages for different microservices and less conflicts in the repo as more people work on it, bu…
There’s a huge difference between http and function calls. When I call a function there is no chance it fails because the function ‘cannot be reached’. With services there are endless reasons why one service is unable to communicate with another. It’s a huge amount of overhead to build a system to handle inter-service communication and failure that doesn’t exist when only calling a function in the same binary.
One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.
The whole problem starts with calling them microservices. Just call it a service oriented architecture please. The whole micro thing is already an indication of the kind of trouble you are getting yourself into. More respect to the monolith please.
One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.
The whole problem starts with calling them microservices. Just call it a service oriented architecture please. The whole micro thing is already an indication of the kind of trouble you are getting yourself into. More respect to the monolith please.
"Uh... we had that back in the early 2000s at least, they called it SOA back then."
And yes we learned back then how painful and complex that kind of architecture was to reason about and support, compared to a simple monolith.
Monolith is truly king unless obviously you're at FAANG scales. 99%+ of shops are many orders of magnitude below that scale.
Earlier quoted context omitted.
Fails because the function is unreachable. The second half of the sentence you quoted says exactly that, why did you cut it out?
If execution of your binary is stopped some time between the call and return (with following restart), dealing with it is no simpler than dealing with network partitioning.
Earlier quoted context omitted.
I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.
Things like message queues and asynchronous events are available for your favorite programming language for in-executable use. You can then do things like running them on a thread pool that has the same number of threads as your machine has cores.
One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.
It seems like this is not coming up because the most common context of application is one or more teams working on a single large project probably forced to grow as fast as possible because of the funding structure involved. Increasingly, though, there are companies doing software development without the need for focus and scale that is so common to venture capital powered groups.
They're fine. But what's NOT fine are nanoservices. I did security on a project once where it seemed that every function was its own microservice. User registration, user login, and password resetting were each a separate microservice. It was an utter nightmare.
Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call. I guess the benefit of microservices is the ability to independently scale different microservices, being able to choose different languages for different microservices and less conflicts in the repo as more people work on it, bu…
The blast radius on deployments can be smaller.
You've already done the work to build up IPC/networked communication so you can make big decisions in a service (like using a better suited language for some feature) without worrying about integrating it with every other feature in your monolith.
You can tailor the instance type to the service. Say you need some kind of video ingestion (or something) that is low use but needs a high memory ceiling. Would you rather pay for that memory across all your monolith instances or just run a few instances of a high memory service?
There's a lot of differences you're not thinking about.