Someday hopefully some genius proposes "hyper-sidecar-ification" where you take microservices and package them together in a sophisticated way to avoid the limitations and latency of an http barrier. As long as it's new & complicated & buzzwordy (even if it's just monorepo again) it can catch on.
The difference between a function call and a network request is vast for even modern networks.
> That dumpster fire over there is not my problem
Without having to say:
> I want to rewrite the whole thing from scratch, you'll have to deal with it being down for a few months
IPC (networks, FIFO, pipes or whatever) decoupled services solve problems more on the ops side, from binary compatibility to resource segregation. They do very little on the dev side.
My point is that it's not a technology problem in the first place. It's a problem of clashing senses of style and taste. It's a culture problem. If you need to dress up your culture problem fix with a technology explanation, http is the way to go because it's widely understood and so boring that nobody is going to ask you to explain it in too great of detail.
Your language's module system is boring. An specialized web server is about as close to the opposite as a corporate structure will allow.
I agree it's suboptimal for performance. But it absolutely cannot be beat for business stability and flexibility. And your IPC costs generally do not dominate your request times anyway.
I want to make people do Bart Simpson style writing on the chalkboard “Microservices don’t make things easier” 200 times
If someone twist my arm and off and convinces me to do some consulting, I’ve seen thousands of services started by individual developers, where there is no accounting, so the ops people don’t know what needs to be kept up or what can be shut down.
Definitely separate regulatory differences (marketing vs credit card processing for example). Generally, separate out high velocity code changes from slow velocity code if possible.
I wouldn’t get in the habit of database migrations having anything to do with code pushes. Unless you have no users, I guess. Yikes. So much to say on that topic alone.
This is the fallacy. Splitting up tech has huge overhead.
There’s lots of good reasons to do it. But “operational efficiency” is not one of them, even though it’s oft cited as one.
What I am saying is that companies who break apart monoliths as a code organization tool are making a very bad decision. They’re getting all the downsides and none of the upsides of microservices.
1. Create protobuffers (or similar) messages that wrap the requests and responses. E.g. CheckSubscriptionPaidRequest and CheckSubscriptionPaidResponse.
2. Refactor your code so that the fields in the messages defined in #1 are your only mean to pass/retrieve information.
3. If need be, expose the service through GRPC or similar.
4. Repeat for each service/endpoint.
This way, you don't incur in any overhead apart from the negligible creation of the protobuffer messages instances.
Essentially you have:
Modules = Microservices
Wrapper = Terraform/Helm Charts
And practically they work the same way.
This is another thing that used to make sense but no longer does. Back in the day we had pets and not cattle. You couldn't just roll someone's servers and expect everything to be fine. But today we write stateless cattle that can be killed at any moment.
Or, in other words, you can't have teams cooperating without governance.
At small size of code, tooling for that may be off-the-shelf for monolith.
Are there any rewrite told that work cross repos though?
If your concern is code health, a compile-time dependency works great.
If your concern is resource management, then you need a runtime dependency.
The end of the article covers why they felt complete isolation was worth the network costs. Maybe this true for their organization.
From working on one of the largest ruby code base for the last 5+ years, I see the massive benefits of isolation without introducing the http barrier. Yes, service isolation can let you ship faster. In practice, the network barrier will make some kinds of rollbacks easier and other far more difficult.
The reliably of the whole system is a lot more costly with the added network failure modes.
Over time, the proliferation of services impose an ever growing maintenance tax to keep libraries up to date and mitigate security vulnerabilities across an organization.
Tl;dr there are no free lunches.
In this particular case it's worse due to how Rails works. Usually people deploy one Rails thread per core and that core is blocked by the thread.
If that's the case when Service A calls Service B, Service A is blocking a core and waiting until Service B completes. That's effectively doubling resource consumption during that call. You have one server waiting on another server to do work it could have done itself.