[dead]
The costs of microservices (2020)
41–50 of 410 posts
Re: The costs of microservices (2020)
#42In the robotics world it's pretty common to have something that looks a lot like microservices as an organizing principle. ROS[1] would probably the robotics framework that everybody cuts their teeth on and in that you have a number of processes communicating over a pub/sub network. Some of the reasons for organizing this way would be familiar to someone doing websites, but you also have factors like vendors for sensors you need providing libraries that will occasionally segfault, and needing to be able to recover from that.
Re: The costs of microservices (2020)
#43Earlier quoted context omitted.
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 5…
> Team realizes their table wont scale, but their data is provided via API. They plan and execute the migration next sprint. ... followed by howls of anguish from the rest of the business when it turns out they were relying on reports generated from a data warehouse which incorporated a copy of that MySQL database and was being populated by an undocumented, not-in-version-control cron script running on a PC under a l…
This was why the "if you breach the service boundary you're fired" Amazon memo was issued.
Re: The costs of microservices (2020)
#44Earlier quoted context omitted.
_Services_ are obviously a good idea (nobody is arguing something like PostgreSQL or Redis or DNS or what have you should all run in the same process as the web server). _Microservices_ attract the criticism. It seems to assume something about the optimal size of services ("micro") that probably isn't optimal for all kinds of service you can think of.
That may be true, but the article describes a services architecture and labels it microservices, indeed goes onto to say: > The term micro can be misleading, though - there doesn’t have to be anything micro about the services
Yes, but the "widespread meme" as I see it is about microservices, not services in general.
Re: The costs of microservices (2020)
#45Earlier quoted context omitted.
_Services_ are obviously a good idea (nobody is arguing something like PostgreSQL or Redis or DNS or what have you should all run in the same process as the web server). _Microservices_ attract the criticism. It seems to assume something about the optimal size of services ("micro") that probably isn't optimal for all kinds of service you can think of.
It's funny because the term "microservices" picked up in popularity because previously, most "service-oriented architecture" (the old term) implementations in large companies had services that were worked on by dozens or hundreds of developers, at least in my experience. So going from that to services that were worked on by a single development team of ~10 people was indeed a "microservice" relatively speaking. Now,…
I can understand wanting to split things off so that one team handles one service, roughly.
There was a recent thread here where someone mentioned he personally was responsible for about four of their microservices...
Re: The costs of microservices (2020)
#46The 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…
> Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, And yet we do this all the time. Your CI/CD blocking your PRs until tests pass? That's a costly technical solution to solve an issue of organizational discipline.
That's technical, and not architectural. I'm _all about_ technical solutions to lack of discipline, and in fact I think technical and process solutions are the only immediate way to create cultural solutions (which are the long-term ones). I'd even consider minor increases to architectural complexity for that purpose justifiable - it's a real problem, and trading to solve it is reasonable.
But architectural complexity has outsized long-term cost, and service-orientation in particular has a _lot_ of it. And in this particular case, it doesn't actually solve the problem, since you _can't_ successfully enforce those domain boundaries unless you already have them well-defined.
Re: The costs of microservices (2020)
#47Earlier quoted context omitted.
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 5…
> Team realizes their table wont scale, but their data is provided via API. They plan and execute the migration next sprint. ... followed by howls of anguish from the rest of the business when it turns out they were relying on reports generated from a data warehouse which incorporated a copy of that MySQL database and was being populated by an undocumented, not-in-version-control cron script running on a PC under a l…
> they were relying on reports generated from a data warehouse which incorporated a copy of that MySQL database and was being populated by an undocumented, not-in-version-control cron script running on a PC under a long-departed team member's desk.
This definitely happens but at some point someone with authority needs to show technical leadership and say "you cannot do this no matter how desperately you need those reports." If you don't have anyone in your org who can do that, you're screwed regardless.
Re: The costs of microservices (2020)
#48In my experience, if a piece of code is stateful and is called from several different services, then it should be its own service. Otherwise it is usually better off as a library.
Re: The costs of microservices (2020)
#49eventual consistency
A bit of tangent but one must admire the optimistic attitude reflected by this name.
"Most of the time inconsistent" says the same thing but is not great for marketing.
Re: The costs of microservices (2020)
#50Earlier quoted context omitted.
> Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, And yet we do this all the time. Your CI/CD blocking your PRs until tests pass? That's a costly technical solution to solve an issue of organizational discipline.
That's technical, and not architectural. I'm _all about_ technical solutions to lack of discipline, and in fact I think technical and process solutions are the only immediate way to create cultural solutions (which are the long-term ones). I'd even consider minor increases to architectural complexity for that purpose justifiable - it's a real problem, and trading to solve it is reasonable. But architectural complexit…
Agreed. isn't that why strongly typed languages made a comeback?