6 ms·

Lessons Learned While Building Microservices

60 points by sundip 10y ago

socmag 10y ago
Yup, and even better when you aren't even tied to any language.
Bahamut 10y ago
My current company learned this a couple of years ago - on their first Node project after deciding to move away from .Net, it ended up a giant monolith, and so 4 years ago or so they decided to move towards microservices. The burden of trying to upgrade a monolith is colossal, and it is where microservices shine.
ChemicalWarfare 10y ago
So while I'm not anti-microservices, from the developer's perspective sometimes there's just way too many moving parts. one code change+one test change back in the "monolith" days (and if the change broke the existing tests you know right away) now becomes an ordeal. Tracking down the client services/altering their code + tests+ simulators (not to mention that you now have to check the code out from bazillions of repos, run it locally etc) and then waiting for their respective build plans to pass, wait for the integration tests to pass etc.
- throwanem 10y ago
  I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult than it has to be. It sounds like you may be having problems not because the architecture is designed the way it is per se, but because it's poorly documented and hard to discover. There's nothing about the monolithic style which prevents that, or even makes it less likely to occur.
  - StavrosK 10y ago
    As I see it (and I haven't been convinced otherwise), the only advantage microservices have over monoliths is that they can scale horizontally more easily, and a slight advantage is that they pressure you to write cleaner interfaces. There's nothing preventing a monolith from being as modular as a microservices architecture, only without all the headaches that come with monitoring tens of services and sticking a network between them. There is NOT just as much complexity in a monolith, because you have no network of services to monitor, there's only one service. Sure, your business logic is going to be the same in either approach, but you're comparing badly written monoliths to well-written microservices. There's nothing that says microservices can't be a mess (and I've seen multiple people completely botch it and have all the services talk to the same database).
    - throwanem 10y ago
      Well, I've seen a lot of badly written monoliths. Whether or not that's coincidental is a point worth considering.
    - lcarlson 10y ago
      Polyglot can be nice too.
      - StavrosK 10y ago
        Ah, true, that's a nice benefit, agreed.
  - Retric 10y ago
    Microservces enforce some separation of concerns, but Monoliths can use the same approach without nearly as much complexity. Overall, I find microservices to add a huge range of new failure modes for little net gain. The sweet spot seems to be services where large chunks of the application operate independently. 10 services are manageable, 100 are not.
    - throwanem 10y ago
- dominotw 10y ago
  your comment reminds me of this tweet https://twitter.com/honest_update/status/651897353889259520 https://twitter.com/honest_update/status/651897353889259520 We replaced our monolith with micro services so that every outage could be more like a murder mystery.
erikcw 10y ago
Does anyone know of a good resource for learning microservices best practices? We're at a stage at my company where it makes sense to consider the transition from a monolith -- but would love to do the right homework first to avoid some of the pitfalls.
- vkjv 10y ago
  I highly recommend reading Martin Fowler. http://martinfowler.com/articles/microservices.html http://martinfowler.com/articles/microservices.html http://martinfowler.com/eaaDev/EventSourcing.html http://martinfowler.com/eaaDev/EventSourcing.html
- berlam 10y ago
  If you prefer books, than I can recommend "Building Microservices" from Sam Newman [1]. You get some basic information and pitfalls you should avoid when building microservices. [1] http://shop.oreilly.com/product/0636920033158.do http://shop.oreilly.com/product/0636920033158.do
- austingunter 10y ago
  We put together a number of talks on microservices.com/talks that you can check out. This one from Uber about their scaling is a good place to start: https://www.microservices.com/talks/scaling-uber-from-1-to-100s-of-services/ https://www.microservices.com/talks/scaling-uber-from-1-to-1... And this one from Ben Christensen of Netflix and Facebook talks about some of the pitfalls https://www.microservices.com/talks/dont-build-a-distributed-monolith/ https://www.microservices.com/talks/dont-build-a-distributed...
derrekl 10y ago
One of the stated lessons learned is: we'd still be on node 0.10 if we weren't using microservices. I've worked a lot on huge monoliths and microservices. Being "stuck" on a version has less to do with monoliths/microservices than it does consistent update practice. If you are using FOSS and schedule periodic updates of the core language and the apps dependencies you'll prevent yourself from getting stuck on old versions. If you run across some dependency that isn't working on version X of the core language you can open tickets against it and/or schedule updating the dependency yourself (this doesn't go away with microservices). Opening tickets against dependencies as the core language updates helps both you and the dependency owner by helping them test and get out ahead. Not only will you prevent from getting stuck on old versions but you'll also have the latest security updates. Note: you don't have to be on the bleeding edge but you should strive to be, in my opinion, no more than 6 months or so from the edge.
- Jtsummers 10y ago
  > If you run across some dependency that isn't working on version X of the core language you can open tickets against it and/or schedule updating the dependency yourself (this doesn't go away with microservices). What does go away with microservices (or, in my case, a suite of applications since my stuff doesn't run online), is that each portion only deals with its dependencies. If I have two applications or services X and Y. X depends on D depends on language/library version N. Y has no such dependency, Y can migrate to N+1 while the issues with D are worked out (changing the dependency, fixing the depency, removing the dependency). In a monolithic application, this is more difficult or impossible. You gain a lot with a monolith, but you lose the flexibility to maintain components as individual components.

60 points by sundip 10y ago

Yup, and even better when you aren't even tied to any language.

My current company learned this a couple of years ago - on their first Node project after deciding to move away from .Net, it ended up a giant monolith, and so 4 years ago or so they decided to move towards microservices. The burden of trying to upgrade a monolith is colossal, and it is where microservices shine.

ChemicalWarfare 10y ago

So while I'm not anti-microservices, from the developer's perspective sometimes there's just way too many moving parts. one code change+one test change back in the "monolith" days (and if the change broke the existing tests you know right away) now becomes an ordeal. Tracking down the client services/altering their code + tests+ simulators (not to mention that you now have to check the code out from bazillions of repos, run it locally etc) and then waiting for their respective build plans to pass, wait for the integration tests to pass etc.

throwanem 10y ago
I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult than it has to be. It sounds like you may be having problems not because the architecture is designed the way it is per se, but because it's poorly documented and hard to discover. There's nothing about the monolithic style which prevents that, or even makes it less likely to occur.
- StavrosK 10y ago
  As I see it (and I haven't been convinced otherwise), the only advantage microservices have over monoliths is that they can scale horizontally more easily, and a slight advantage is that they pressure you to write cleaner interfaces. There's nothing preventing a monolith from being as modular as a microservices architecture, only without all the headaches that come with monitoring tens of services and sticking a network between them. There is NOT just as much complexity in a monolith, because you have no network of services to monitor, there's only one service. Sure, your business logic is going to be the same in either approach, but you're comparing badly written monoliths to well-written microservices. There's nothing that says microservices can't be a mess (and I've seen multiple people completely botch it and have all the services talk to the same database).
  - throwanem 10y ago
    Well, I've seen a lot of badly written monoliths. Whether or not that's coincidental is a point worth considering.
  - lcarlson 10y ago
    Polyglot can be nice too.
    - StavrosK 10y ago
      Ah, true, that's a nice benefit, agreed.
- Retric 10y ago
  Microservces enforce some separation of concerns, but Monoliths can use the same approach without nearly as much complexity. Overall, I find microservices to add a huge range of new failure modes for little net gain. The sweet spot seems to be services where large chunks of the application operate independently. 10 services are manageable, 100 are not.
  - throwanem 10y ago
dominotw 10y ago
your comment reminds me of this tweet https://twitter.com/honest_update/status/651897353889259520 https://twitter.com/honest_update/status/651897353889259520 We replaced our monolith with micro services so that every outage could be more like a murder mystery.

erikcw 10y ago

Does anyone know of a good resource for learning microservices best practices? We're at a stage at my company where it makes sense to consider the transition from a monolith -- but would love to do the right homework first to avoid some of the pitfalls.

vkjv 10y ago
I highly recommend reading Martin Fowler. http://martinfowler.com/articles/microservices.html http://martinfowler.com/articles/microservices.html http://martinfowler.com/eaaDev/EventSourcing.html http://martinfowler.com/eaaDev/EventSourcing.html
berlam 10y ago
If you prefer books, than I can recommend "Building Microservices" from Sam Newman [1]. You get some basic information and pitfalls you should avoid when building microservices. [1] http://shop.oreilly.com/product/0636920033158.do http://shop.oreilly.com/product/0636920033158.do
austingunter 10y ago
We put together a number of talks on microservices.com/talks that you can check out. This one from Uber about their scaling is a good place to start: https://www.microservices.com/talks/scaling-uber-from-1-to-100s-of-services/ https://www.microservices.com/talks/scaling-uber-from-1-to-1... And this one from Ben Christensen of Netflix and Facebook talks about some of the pitfalls https://www.microservices.com/talks/dont-build-a-distributed-monolith/ https://www.microservices.com/talks/dont-build-a-distributed...

derrekl 10y ago

One of the stated lessons learned is: we'd still be on node 0.10 if we weren't using microservices. I've worked a lot on huge monoliths and microservices. Being "stuck" on a version has less to do with monoliths/microservices than it does consistent update practice. If you are using FOSS and schedule periodic updates of the core language and the apps dependencies you'll prevent yourself from getting stuck on old versions. If you run across some dependency that isn't working on version X of the core language you can open tickets against it and/or schedule updating the dependency yourself (this doesn't go away with microservices). Opening tickets against dependencies as the core language updates helps both you and the dependency owner by helping them test and get out ahead. Not only will you prevent from getting stuck on old versions but you'll also have the latest security updates. Note: you don't have to be on the bleeding edge but you should strive to be, in my opinion, no more than 6 months or so from the edge.

Jtsummers 10y ago
> If you run across some dependency that isn't working on version X of the core language you can open tickets against it and/or schedule updating the dependency yourself (this doesn't go away with microservices). What does go away with microservices (or, in my case, a suite of applications since my stuff doesn't run online), is that each portion only deals with its dependencies. If I have two applications or services X and Y. X depends on D depends on language/library version N. Y has no such dependency, Y can migrate to N+1 while the issues with D are worked out (changing the dependency, fixing the depency, removing the dependency). In a monolithic application, this is more difficult or impossible. You gain a lot with a monolith, but you lose the flexibility to maintain components as individual components.