Earlier quoted context omitted.
No one says you can't have all of your microservices use the same language...
Absolutely. This is how we operated when we were at the peak of our tech showmanship phase. We had ~12 different services, all .NET 4.x the exact same way. This sounds like it could work, but then you start to wonder about how you'd get common code into those 12 services. Our answer at the time was nugets, but we operate in a sensitive domain with proprietary code, so public nuget services were a no go. So, we stood…
The costs of microservices (2020)
251–260 of 410 posts
Re: The costs of microservices (2020)
#252Relatedly, you can't really do joins. Like, let's say you have an organizations service and a people service. You might want to know what people are in which organizations, and paginate results. Welcome to a couple of unpalatable options:
- Make some real slow API calls to both services (also implement all the filters and ordering, etc).
- Pull all the data you need into this new 3rd service, and justify it by saying you're robust in the face of your dependency services failing, but also be aware you're adding yet another layer of eventual consistency here too.
This is the simplest this problem can be. Imagine needing data from 3 or 13 services. Imagine needing to to synchronize UUIDs from one service to 20 others. Imagine needing to also delete a user/organization from the 30 other services that have "cached" it. Etc etc.
I used to think microservices were an adaptation to Conway's law, but now I really think it's a response to the old days when we didn't have databases that scaled horizontally. But we do now (Cockroach, Big Query, etc) so we really should just move on.
Re: The costs of microservices (2020)
#253Earlier quoted context omitted.
> God forbid you find yourself with a need to rewrite one of these shitpiles. Actually, this is much easier with micro services as you have a clear interface you need to support and the code is not woven into the rest of the monolith like a French plat. The best code is the easiest to throw away and rewrite, because let's face it, the older the code is, the more hands it's been through, the worse it is, but more impo…
If the monolithic application is written in a language with sufficient encapsulation and good tooling around multi-module projects, then you can indeed have well known and encapsulated interfaces within the monolith. Within the monolith itself you can create a DAG of enforced interfaces and dependencies that is logically identical to a set of services from different codebases. There are well known design issues in mo…
Could you elaborate on this? I see how "separating data from logic" is a problem but what about the other two?
Re: The costs of microservices (2020)
#254Re: The costs of microservices (2020)
#255> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…
> God forbid you find yourself with a need to rewrite one of these shitpiles. Actually, this is much easier with micro services as you have a clear interface you need to support and the code is not woven into the rest of the monolith like a French plat. The best code is the easiest to throw away and rewrite, because let's face it, the older the code is, the more hands it's been through, the worse it is, but more impo…
Most substantial rewrites crosses module boundaries. In micro services changing the module boundary is harder than in a monolith, since it can be done in a single commit/deploy.
Re: The costs of microservices (2020)
#256> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…
> Wouldn't it be a hell of a lot easier if it was all in one place where each commit is globally consistent? I always find this sentence to be a bit of a laugh. It's so commonly said (by either group of people with a dog in this fight) but seemingly so uncommonly thought of from the other group's perspective. People that prefer microservices say it's easier to change/rewrite code in a microservice because you have a…
But if you need to change the contract the changes span the service and all of its clients.
Re: The costs of microservices (2020)
#257Earlier quoted context omitted.
DNS resolution is genuninely reusable, though. Perhaps that's the test: is this something that could concievably be used by others, as a product in itself, or is it tied very heavily to the business and the rest of the "microservices"? Remember this is how AWS was born, as a set of "microservices" which could start being sold to external customers, like "storage".
What about a mailer that's divided into the SMTP server and the local delivery agent?
Re: The costs of microservices (2020)
#258Earlier quoted context omitted.
"The last responsible moment (LRM) is the strategy of delaying a decision until the moment when the cost of not making the decision is greater than the cost of making it." Quoted from: https://www.oreilly.com/library/view/software-architects-han...
Still trying to unlearn that one. Turns out, most decisions are cheap to revert or backtrack on, while delaying them until Last Responsible Moment often ends in shooting past that moment.
My experience is that the new data available when postponing decisions can be very very valuable.
Re: The costs of microservices (2020)
#259> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…
I think this is a false dichotomy. Most places I've worked with microservices had 2 or 3 approved languages for this reason (and others) and exceptions could be made by leadership if a team could show they had no other options. Microservices doesn't need to mean it's the wild west and every team can act without considering the larger org. There can and should be rules to keep a certain level of consistency across tea…
Re: The costs of microservices (2020)
#260Earlier quoted context omitted.
That process sounds fine to me, especially in a context with either good integration coverage or low downtime cost. > to “ream” someone for merging without deploying is incredibly immature and uncreative. I'd agree, but I _highly_ doubt that description was an accurate one. Read through the other comments by the same person and you'll get a picture of their personality pretty quickly. It's likely that there was alrea…
I suggested it's possible to write, commit and own code without others' approval to increase productivity and people get _extremely_ defensive about it. It's so odd. It happened in real life and it's happening in this thread now, too. They even attack your character over it.
You want to get the team to a point where you can disagree and commit, no code will ever be perfect and there is no reason spending 3-4 rounds of change requests trying. I think the worst code review I ever had, ended with me saying, “if you’re going to be this nitpicky, why don’t you take the ticket?” (It was extremely complex and hard to read — and there wasn’t any getting around it, lots of math, bit shifting, and other shenanigans. The reviewer kept making suggestions that would result in bugs, and then make more suggestions…)
He came back the next day and approved my PR once he understood the problem I was trying to solve.
Even these days, where I work on a close team IRL, I’ve been known to say, “if there are no objections, I’m merging this unreviewed code.” And then I usually get a thumbs up from the team, or they say something like “oh, I wanted to take a look at that. Give me a few mins I got sidetracked!” And I’ve even heard, “I already reviewed it, I just forgot to push approve!”
Communication is key in a team. Often, if the team is taking a long time to review, give them the benefit of the doubt, but don’t let yourself get blocked by a review.