5 ms·

All of these articles against microservices are so annoying because I rarely see a good argument against microservices. Often the arguments are purely anecdotal

All of these articles against microservices are so annoying because I rarely see a good argument against microservices. Often the arguments are purely anecdotal and without substance. There are only two good arguments I can make against microservices. First, it's not the right architecture choice for all projects. Second, microservices don't magically solve the problem of complexity. But I can name countless benefits of a microservices architecture. Individual microservices are far less complex than monoliths, which allows even a single developer to work on a microservice, run and test it on their local machine, whereas monoliths may require dedicated test servers because they're too large and complex to run on a developer's machine. Microservices simply dependencies because each microservice has exactly the dependencies it needs, as opposed to a monolith that becomes a huge tangled mess of dependencies locked to specific versions, and incredibly complex environments to ensure all these dependencies don't interfere with one another, where any little change or misconfiguration will bring down the entire service. Microservices allow for more rapid development, since you're only rebuilding and testing a small part of the entire architecture, without interfering with others work, allowing many independent teams and individual developers to work in parallel. Without elaborating too much, I'll reiterate what is said many times over, microservices are generally easier to scale horizontally with less downtime. A common misconception I see is microservices have to be simple and tiny. But your database system can be considered a microservice, and that's hardly simple or tiny. The point is the database serves a single purpose in the overall architecture of the application, and it can be managed independently of all the other microservices. What you shouldn't do is, say, combine your database and message broker into a single microservice. Yes, microservices are hard, and there's so many ways to do it wrong. But you know what? Software Engineering is a hard problem in general, and it's unlikely there's ever going to be a great solution that magically solves all our problems, only incremental improvements that allow us to manage ever greater complexity.

JAlexoid 4y ago
The argument against microservices is simple - there should be a clear use case for a microservice. Don't go - "we do everything as a microservice". Almost 20 years ago we had "we do everything using SOA"... Same thing. And your own comment shows that microservice advocacy are inconsistent: > Individual microservices are far less complex than monoliths, which allows even a single developer to work on a microservice, run and test it on their local machine > database system can be considered a microservice, and that's hardly simple or tiny DBMS is as much a microservice, as many other microservices are. You cannot just replace a DBMS with another transparently, just like in many cases you cannot just deploy a different version of a microservice without coordination.
dagss 4y ago
"Individual microservices are less complex than monoliths" ... but the sum of microservices is still as complex as the monolith. (But better hope you got your division of domains and services correct!) "A single developer and work and test it on their local machine" ... OK I've never encountered a monolith that couldn't be run and developed locally. I don't say it was never a problem, but that there must have been other solutions to it than microservices. Surely today's laptops can easily compile and run a million lines of code... And as the counterpint, I've encountered cases of having to orchestrate 15 different micro-services locally to do anything USEFUL and non-contrived. Something to help you gain some understanding of how the WHOLE system work, and not rely on other people with the full overview to tell you can evolve your small piece of it. "rapid development" -- fix your build and test caching "only ... testing a small part of the entire architecture" -- again, with a monolith surely you can focus on a single test function / sub-component and figure out how that works. With micro-services it gets a lot harder to do integration testing across the whole system, and people tend to not do it or argue why it "isn't needed". But keep in mind that also with monoliths it is entirely possible to simple delete/not write the system integration tests. It is just that people tend to want to have them (for good reasons), but with microservices there's a much higher investment needed to get them (and they don't execute any faster, but slower, if you invest in them). This comes down to an argument of "we make such perfect code we don't need tests..."... just because it is network calls and APIs, doesn't mean that noone ever messes up and does a backwards-incompatible change. Simply dropping system integration tests and discovering bugs like that in production is an option for monoliths too.

JAlexoid 4y ago

The argument against microservices is simple - there should be a clear use case for a microservice. Don't go - "we do everything as a microservice". Almost 20 years ago we had "we do everything using SOA"... Same thing. And your own comment shows that microservice advocacy are inconsistent: > Individual microservices are far less complex than monoliths, which allows even a single developer to work on a microservice, run and test it on their local machine > database system can be considered a microservice, and that's hardly simple or tiny DBMS is as much a microservice, as many other microservices are. You cannot just replace a DBMS with another transparently, just like in many cases you cannot just deploy a different version of a microservice without coordination.

dagss 4y ago

"Individual microservices are less complex than monoliths" ... but the sum of microservices is still as complex as the monolith. (But better hope you got your division of domains and services correct!) "A single developer and work and test it on their local machine" ... OK I've never encountered a monolith that couldn't be run and developed locally. I don't say it was never a problem, but that there must have been other solutions to it than microservices. Surely today's laptops can easily compile and run a million lines of code... And as the counterpint, I've encountered cases of having to orchestrate 15 different micro-services locally to do anything USEFUL and non-contrived. Something to help you gain some understanding of how the WHOLE system work, and not rely on other people with the full overview to tell you can evolve your small piece of it. "rapid development" -- fix your build and test caching "only ... testing a small part of the entire architecture" -- again, with a monolith surely you can focus on a single test function / sub-component and figure out how that works. With micro-services it gets a lot harder to do integration testing across the whole system, and people tend to not do it or argue why it "isn't needed". But keep in mind that also with monoliths it is entirely possible to simple delete/not write the system integration tests. It is just that people tend to want to have them (for good reasons), but with microservices there's a much higher investment needed to get them (and they don't execute any faster, but slower, if you invest in them). This comes down to an argument of "we make such perfect code we don't need tests..."... just because it is network calls and APIs, doesn't mean that noone ever messes up and does a backwards-incompatible change. Simply dropping system integration tests and discovering bugs like that in production is an option for monoliths too.