5 ms·

Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them.

Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. We had a monolith, and it devolved into a mess--managers would insist on people taking dependencies on stuff they didn't own in the name of expedience ("yeah, we'll totally circle back and do it the right way lol"). Microservices kept things neat by making dumb things hard. We were also able to deploy individual services much more frequently without needing to coordinate with a bunch of other teams, and builds, tests, etc were much faster helping shorten our iteration loops. Local development environments were a bit more tedious in certain cases, but that was the only issue I recall.

willcipriano 4y ago
Microservices suck when you need to make a process faster, so you run a profiler and figure out that 90% of the workload is handling the http requests between the services.
- bb88 4y ago
  I feel like HTTP is too heavyweight for microservices. For monoliths, it's great. And the only way to proceed in your case is to convert microservices into mini-monoliths. Particularly the authentication side, which needs to be revalidated with every request. gRPC might be better, but supposedly so was SOAP, CORBA, DCOM, XMLRPC, and finally REST.
  - throwaway894345 4y ago
    How does gRPC make authentication lighter-weight? Presumably you still have a token in either case which needs to be validated? There aren't many places where parsing HTTP requests is really a significant bottleneck, and I'd guess the majority of the remainder are an architectural problem (someone using a "get" endpoint in a tight loop instead of a "list" endpoint or some such).
    - bb88 4y ago
      Technically you could auth the connection using say, a custom SSL cert, and the connection isn't made unless the SSL cert is recognized. There are other ways to do it as well where the socket connection is only authed once.
arinlen 4y ago
> Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. Likewise. When I see people complaining about microservices, more often what I see is actually poorly thought-through strawmen aimed at distributed systems, which boil down to "having to do network requests is bad". I wonder why attacking the "microservices" buzzword gets these people on rage mode but the sight of a web app calling a dozen APIs somehow doesn't make them bat an eye.
- jnash 4y ago
  That sounds like a "True Scotsman" argument. The fact is that microservices are inherently and objectively more complex than Monoliths. So if you can't build a well engineered Monolith then you are pretty much guaranteed to build an even worse Microservices system (because you now have the added encoding/decoding, network hops, latency and timing issues, no guaranteed data consistency, no global commit guarantees etc. etc. etc.)
  - throwaway894345 4y ago
    I can believe that monoliths have a lower theoretical complexity floor than microservice architectures, but I don't think any shops are coming close to that theoretical complexity floor irrespective of their architecture, so we need to think about the actual, practical complexity of applications in each architecture. Specifically, I think the strong boundaries between components better facilitates maintainability--as with dynamic typing, the absence of rails allows people to more easily make bad decisions. In the case of monoliths, this usually looks like an inexperienced developer (especially at the bequest of an unscrupulous manager who swears that we will definitely not do this again and will fix in a subsequent release) taking a dependency on another system's private internals. In other words, I assert that given a good architect and an average team, a microservice architecture will be less complex than a monolith despite marshaling data over a network. In order to have a well-engineered monolith, you need good architects and a good team (no unscrupulous managers who are empowered to compromise the architecture in the name of expedience). > no guaranteed data consistency, no global commit guarantees You don't get these for free with monoliths either. I've seen a lot of monoliths choc full of race conditions which don't manifest during development (small contrived test cases running on unburdened systems). Paradoxically, because microservices have to marshal data over a network, these consistency issues are more likely to appear. Moreover, people who work on microservices are more likely to think about race conditions precisely because the system is distributed (indeed, the architects think about this stuff when they lay out the interfaces).
deterministic 4y ago
If you don’t have the skills to implement a well structured and easy to maintain monolith then you most definitely don’t have the skills to implement a distributed more complex implementation of the same system.
- throwaway894345 4y ago
  On the contrary. An experienced architect defines the boundaries and then the microservice architecture enforced them in a way that a monolithic architecture cannot.
  - deterministic 4y ago
    On the contrary. Using libraries with clearly defined interfaces makes it easier to combine those libraries into a single executable, reducing deployment and debugging complexity. It also dramatically improves performance given the lack of intermediate encoding/decoding protocol code and TCP/UDP hops. Experienced seasoned Architects knows this and work hard to remove unnecessary distributed complexity from systems they design. While “beginner experts” always pick the most complex “solution” for the job at hand. The worst spaghetti code I have ever seen in my 30+ year career is a 20+ years old Microservices architecture. So I can’t wait to read the future “We had a problem so we chose micro-services. Now we have N distributed problems + K impossible to debug obscure timing issues” articles.
  - barking_biscuit 4y ago
    My 2c is that an experience architect would know that it would be ideal if they could do this and be right, but in practice they aren't likely to get those boundaries correct up-front and it takes time and experience working in the domain to see what those boundaries truly ought to be. Also, it's perfectly possible for monolithic applications to enforce boundaries as strict as microservices do via a "modular monolith" approach where the domain contracts are marked as public, but all the domain logic is marked as internal, and a framework of sorts enforces that each module only has access to either it's own schema in a shared database, or it's own separate database. These days I think that's actually where everything should start off. With a good implementation of this you can transition relatively painlessly to a distributed system, and in the initial phases the simplicity of the build/test/deploy cycle massively lowers the overhead compared to a microservices approach while the strong isolation of domain logic gives you the ability to reason about changes to your domain not affecting other areas of the system. Having worked in both small companies with terrible monoliths, small companies with terrible microservices, big companies with terrible monoliths and big companies with semi-decent microservices, and then implementing a modular monolith myself, I've seen enough to know that it's a solid, solid starting point. Most companies are pretty small, and the difference between an engineering org of 40 engineers trying microservices vs an engineering org of 4000 engineers doing microservices is on such a different level that people who haven't experienced both likely can't appreciate the data point that they're missing. I love the strong isolation that microservices provide, and they can be super beneficial, but done at the wrong scale, the wrong level of technical maturity, or the wrong time and they're a huge drag. By the same token a monolith that grows too large for too long is equally a drag, but it's one that's exponentially more tolerable in an engineering org of 40 engineers than it is an engineering org of 4000 engineers. The key thing isn't which architecture you pick, it's the ability to be able to transition and adapt at the right point in time. Modular monoliths buy you this opportunity at a fraction of the price and for much less risk.
anonymoushn 4y ago
At a multibillion dollar company, local development is impossible, staging doesn't exist, most stack traces from production are truncated because the log aggregator cannot handle log entries as large as java stack traces, and most of the work involves migrating from talking to the database to talking to a microservice that exposes a single table of the database. What are joins? At another company that was acquired by Amazon, the "user service" team (so again this is a microservice that exposes a single table of a database, this time with a two-pizza team dedicated entirely to that microservice) told us that we couldn't just query the user service when we wanted to render a page containing a username given a user id, because that was too many queries. Product demands from a VP dictated that we didn't have time to set up our own caching layer for their service (is this the responsibility of every team other than theirs?), so we shipped the feature with the usernames saved in our own DB, and now when users change their usernames the old name will appear in the pages for our feature, depending on when the pages were created.
- barking_biscuit 4y ago
  Obligatory repost: https://www.youtube.com/watch?v=y8OnoxKotPQ&ab_channel=KRAZAM https://www.youtube.com/watch?v=y8OnoxKotPQ&ab_channel=KRAZA...

willcipriano 4y ago

Microservices suck when you need to make a process faster, so you run a profiler and figure out that 90% of the workload is handling the http requests between the services.

bb88 4y ago
I feel like HTTP is too heavyweight for microservices. For monoliths, it's great. And the only way to proceed in your case is to convert microservices into mini-monoliths. Particularly the authentication side, which needs to be revalidated with every request. gRPC might be better, but supposedly so was SOAP, CORBA, DCOM, XMLRPC, and finally REST.
- throwaway894345 4y ago
  How does gRPC make authentication lighter-weight? Presumably you still have a token in either case which needs to be validated? There aren't many places where parsing HTTP requests is really a significant bottleneck, and I'd guess the majority of the remainder are an architectural problem (someone using a "get" endpoint in a tight loop instead of a "list" endpoint or some such).
  - bb88 4y ago
    Technically you could auth the connection using say, a custom SSL cert, and the connection isn't made unless the SSL cert is recognized. There are other ways to do it as well where the socket connection is only authed once.

arinlen 4y ago

> Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. Likewise. When I see people complaining about microservices, more often what I see is actually poorly thought-through strawmen aimed at distributed systems, which boil down to "having to do network requests is bad". I wonder why attacking the "microservices" buzzword gets these people on rage mode but the sight of a web app calling a dozen APIs somehow doesn't make them bat an eye.

jnash 4y ago
That sounds like a "True Scotsman" argument. The fact is that microservices are inherently and objectively more complex than Monoliths. So if you can't build a well engineered Monolith then you are pretty much guaranteed to build an even worse Microservices system (because you now have the added encoding/decoding, network hops, latency and timing issues, no guaranteed data consistency, no global commit guarantees etc. etc. etc.)
- throwaway894345 4y ago
  I can believe that monoliths have a lower theoretical complexity floor than microservice architectures, but I don't think any shops are coming close to that theoretical complexity floor irrespective of their architecture, so we need to think about the actual, practical complexity of applications in each architecture. Specifically, I think the strong boundaries between components better facilitates maintainability--as with dynamic typing, the absence of rails allows people to more easily make bad decisions. In the case of monoliths, this usually looks like an inexperienced developer (especially at the bequest of an unscrupulous manager who swears that we will definitely not do this again and will fix in a subsequent release) taking a dependency on another system's private internals. In other words, I assert that given a good architect and an average team, a microservice architecture will be less complex than a monolith despite marshaling data over a network. In order to have a well-engineered monolith, you need good architects and a good team (no unscrupulous managers who are empowered to compromise the architecture in the name of expedience). > no guaranteed data consistency, no global commit guarantees You don't get these for free with monoliths either. I've seen a lot of monoliths choc full of race conditions which don't manifest during development (small contrived test cases running on unburdened systems). Paradoxically, because microservices have to marshal data over a network, these consistency issues are more likely to appear. Moreover, people who work on microservices are more likely to think about race conditions precisely because the system is distributed (indeed, the architects think about this stuff when they lay out the interfaces).

deterministic 4y ago

If you don’t have the skills to implement a well structured and easy to maintain monolith then you most definitely don’t have the skills to implement a distributed more complex implementation of the same system.

throwaway894345 4y ago
On the contrary. An experienced architect defines the boundaries and then the microservice architecture enforced them in a way that a monolithic architecture cannot.
- deterministic 4y ago
  On the contrary. Using libraries with clearly defined interfaces makes it easier to combine those libraries into a single executable, reducing deployment and debugging complexity. It also dramatically improves performance given the lack of intermediate encoding/decoding protocol code and TCP/UDP hops. Experienced seasoned Architects knows this and work hard to remove unnecessary distributed complexity from systems they design. While “beginner experts” always pick the most complex “solution” for the job at hand. The worst spaghetti code I have ever seen in my 30+ year career is a 20+ years old Microservices architecture. So I can’t wait to read the future “We had a problem so we chose micro-services. Now we have N distributed problems + K impossible to debug obscure timing issues” articles.
- barking_biscuit 4y ago
  My 2c is that an experience architect would know that it would be ideal if they could do this and be right, but in practice they aren't likely to get those boundaries correct up-front and it takes time and experience working in the domain to see what those boundaries truly ought to be. Also, it's perfectly possible for monolithic applications to enforce boundaries as strict as microservices do via a "modular monolith" approach where the domain contracts are marked as public, but all the domain logic is marked as internal, and a framework of sorts enforces that each module only has access to either it's own schema in a shared database, or it's own separate database. These days I think that's actually where everything should start off. With a good implementation of this you can transition relatively painlessly to a distributed system, and in the initial phases the simplicity of the build/test/deploy cycle massively lowers the overhead compared to a microservices approach while the strong isolation of domain logic gives you the ability to reason about changes to your domain not affecting other areas of the system. Having worked in both small companies with terrible monoliths, small companies with terrible microservices, big companies with terrible monoliths and big companies with semi-decent microservices, and then implementing a modular monolith myself, I've seen enough to know that it's a solid, solid starting point. Most companies are pretty small, and the difference between an engineering org of 40 engineers trying microservices vs an engineering org of 4000 engineers doing microservices is on such a different level that people who haven't experienced both likely can't appreciate the data point that they're missing. I love the strong isolation that microservices provide, and they can be super beneficial, but done at the wrong scale, the wrong level of technical maturity, or the wrong time and they're a huge drag. By the same token a monolith that grows too large for too long is equally a drag, but it's one that's exponentially more tolerable in an engineering org of 40 engineers than it is an engineering org of 4000 engineers. The key thing isn't which architecture you pick, it's the ability to be able to transition and adapt at the right point in time. Modular monoliths buy you this opportunity at a fraction of the price and for much less risk.

anonymoushn 4y ago

At a multibillion dollar company, local development is impossible, staging doesn't exist, most stack traces from production are truncated because the log aggregator cannot handle log entries as large as java stack traces, and most of the work involves migrating from talking to the database to talking to a microservice that exposes a single table of the database. What are joins? At another company that was acquired by Amazon, the "user service" team (so again this is a microservice that exposes a single table of a database, this time with a two-pizza team dedicated entirely to that microservice) told us that we couldn't just query the user service when we wanted to render a page containing a username given a user id, because that was too many queries. Product demands from a VP dictated that we didn't have time to set up our own caching layer for their service (is this the responsibility of every team other than theirs?), so we shipped the feature with the usernames saved in our own DB, and now when users change their usernames the old name will appear in the pages for our feature, depending on when the pages were created.

barking_biscuit 4y ago
Obligatory repost: https://www.youtube.com/watch?v=y8OnoxKotPQ&ab_channel=KRAZAM https://www.youtube.com/watch?v=y8OnoxKotPQ&ab_channel=KRAZA...