The costs of microservices (2020)
robertovitillo.com
The costs of microservices (2020)
1–10 of 410 posts
Re: The costs of microservices (2020)
#2 Microservices
grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
seem very confusing to grug
Re: The costs of microservices (2020)
#3The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so.
Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going to go well_.
Re: The costs of microservices (2020)
#4Interesting article.
Although one point I'd like to contest is the first "pro" which is you can use a different language for each service. We tried this approach and it failed fantastically. You're right about the cons, it becomes un-maintable.
We had 3 microservices that we maintained on our team, one in Java, one in Ruby and one in Node. We very quickly realized we needed to stick to one, in order to share code, stop the context switching, logging issues, etc.
The communication piece is something that solid monoliths should practice as well (as is it touched on in the article). Calling an 3rd party API without a timeout is not a great idea (to be it lightly), monolith or microservice.
Thought-provoking nevertheless, thank you for sharing.
Re: The costs of microservices (2020)
#5The article sees to take for granted that your development org is completely broken and out of control. They can't decide what to work on during sprints, they furtively introduce third party libraries and unknown languages, they silently ship incompatible changes to prod, etc. I guess microservices are easier if your developers aren't bozos.
Re: The costs of microservices (2020)
#6> Once the monolith is well matured and growing pains start to rise, then you can start to peel off one microservice at a time from it.
Curious what is considered a growing pain of the monolith vs tech debt that hasn't been tackled. If the issue is the monolith can't scale in performance then a services oriented architecture doesn't necessarily give you that automatically unless you know where the bottleneck of your monolith is.
Re: The costs of microservices (2020)
#7Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug https://grugbrain.dev/#grug-on-microservices
grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores.
"We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 59 teams are directly accessing the FOO_TABLE or directly accessing private methods on our classes. Due to competing priorities, those teams cannot do the work to move to using our FOO_SERVICE and they can't change their query method to use a sharded table. To scale our FOO_TABLE will now be a multi-quarter effort providing the ability for teams to slow roll their update. After a year or two, we should be able to retire the old method that is on fire right now. In the meanwhile, enjoy oncall."
Compare this to a microservice: Team realizes their table wont scale, but their data is provided via API. They plan and execute the migration next sprint. Users of the API report that it is now much faster.
Re: The costs of microservices (2020)
#8The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going…
Sounds like a SISP (solution in search of a problem). Or throwing a solution at a problem not understanding the root issue of it.
Re: The costs of microservices (2020)
#9The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going…
I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. I think everyone recognizes that it makes sense that domain name resolution is performed by an external service, and very few people are out there integrating a recursive DNS resolver and cache into their monolith. And yet, this long-standing division of responsibility never seems to count as an example.
Re: The costs of microservices (2020)
#10My current job hasn't been a great experience with microservices. It's a industry where I've worked with a monolith that did a lot more but having everything split between like 17 different services makes managing anything not so fun. The other big blocker is small team and only one of us met the original staff who designed this.