6 ms·

> So naturally, branching, building and testing across all these different microservices is difficult. Imagine having to roll back a commit, then having to find

by merb 8y ago

> So naturally, branching, building and testing across all these different microservices is difficult. Imagine having to roll back a commit, then having to find the equivalent commit in the two other parent services, then rolling back the horizontal services to the equivalent commit that should not happen. if it does you don't have a microservice architecture, you have a spaghetti service architecture.

tabtab 8y ago
How does one know if X is the wrong solution or if X is the right solution but the shop is "doing X wrong"? This also applies to monoliths: maybe they can scale, but one is doing them wrong. Changing from doing monoliths wrong to doing microservices wrong is obviously not progress. The same issue appeared when OOP was fairly new: people started using it heavily and ended up making messes. They were then told that they were "doing it wrong". OOP was initially sold as magic reusable Lego blocks that automatically create nice modularity. There was even an OOP magazine cover showing just that: a coder using magic Legos that farted kaleidoscopic glitter. Microservices is making similar promises. It took a while to learn where and how to use OOP and also when not to: it sucks at some things.
- freedomben 8y ago
  If you want to learn "the right way" I highly recommend "Building Microservices: Designing Fine-Grained Systems" by Sam Newman[1] [1] https://smile.amazon.com/Building-Microservices-Designing-Fine-Grained-Systems/dp/1491950358/ref=sr_1_3 https://smile.amazon.com/Building-Microservices-Designing-Fi...
- notyourday 8y ago
  I have posted about this before. OP is describing nano-services, not micro-services. Nano-service is micro-service that provides leftpad via JSON api. You have an auth.yourapp.com and api.yourapp.com and maybe tracer.yourapp.com and those three things are not a single app that behaves like auth, api or tracer depending on setting of a NODE_ENV variable? If so, you have micro services.
- taneq 8y ago
  Simple: If X is a technology I don't like, and it's not working for you, then it's the wrong solution. If X is a technology I don't like, and it is working for you, then you simply haven't scaled enough to understand its limitations. If X is a technology I like, but it's not working for you, then your shop is "doing X wrong". If X is a technology I like, and it's working for you, then it's the right solution and we're both very clever.
  - staticassertion 8y ago
    edit: See below
    - taneq 8y ago
      Uh, my post was snark towards engineers' general tendency to champion and defend their own favourite architecture over competing approaches rather than focusing on the most suitable architecture for the circumstance, in response to this question: > How does one know if X is the wrong solution or if X is the right solution but the shop is "doing X wrong"? Edit: And a civil conversation ensued. :)
      - staticassertion 8y ago
        Sorry, I just misread your post as being more of an attack. As I had said, I dislike the constant "hype means something is bad" posts that I've been seeing for years - I think it's really unfortunate.
        taneq 8y ago
        No worries, I can see how it might have been read that way in the wider context of the conversation. And I totally hear you on the "hype equals bad" thing. If something's popular, it's popular for a reason. That reason MIGHT just be trendoids jumping on a hype train, but it might also be because the thing is good.
mirkules 8y ago
Heh, I like that “Spaghetti Microservices”. You are right. It should not happen. It is difficult to see these pitfalls when unwinding an unwieldy monolith, and, as an organization all you’ve ever done are unwieldy monoliths, that have a gazillion dependencies, interfaces and factories. We learned from it, and we move on - hopefully, it serves as a warning to others.
- tcbasche 8y ago
  I've heard the term 'Distributed Monolith'
- james_s_tayler 8y ago
  MicroPasta
  - cestith 8y ago
    Tangled angelhair.
- c3534l 8y ago
  I think we should call it angel-hair pasta code. You know, because it's very small spaghetti.
- smnplk 8y ago
  No, it's ravioli oriented architecture
dragonwriter 8y ago
> that should not happen. if it does you don't have a microservice architecture, you have a spaghetti service architecture. A "service" is not defined principally by a code repository or communications-channel boundary (though it should have the latter and may have the former), but by a coupling boundary. OTOH, maintaining a coupling boundary can have non-obvious pitfalls; e.g., supported message format versions can become a source of coupling--if you roll back a service to the version that can't send message format v3, but a consumer of the messages requires v3 and no longer supports consuming v2, then you have a problem.
- merb 8y ago
  you should never actually remove an api without a deprecation process. basically a message format is part of your api. actually in a microservice world your interfaces/api should be as stable as possible. if something gets changed, it needs to go trough a deprecation, that means not removing it until a certain amount of time.
  - NicoJuicy 8y ago
    The accept header could fix this easily if no third parties are involved
  - NicoJuicy 8y ago
    The accept header could fix this easily if no third parties are involved and if it's a rest like API protocol
    - dragonwriter 8y ago
      The accept header is a mechanism for communicating formats you support; it doesn't do anything to address the problem of managing change to supported versions, which is a dev process issue, not a technical issue.
      - geezerjay 8y ago
        > The accept header is a mechanism for communicating formats you support; it doesn't do anything to address the problem of managing change to supported versions That assertion is not true. Media type API versioning is a well established technique.
sequoia 8y ago
It sounds like you're paraphrasing the great Steven Jobs: "You're holding it wrong" Be that as it may, I believe mirkules's issue is not an uncommon one. Perhaps saying "building a microservice architecture 'the right way' is a complex and subtle challenge" would capture a bit of what both of you are saying. Something being complex and therefor easy to mess up does not mean it's a great system and the users are dumb, especially if there are other (less complicated, less easy to mess up) ways to complete the task.
- geezerjay 8y ago
  > Perhaps saying "building a microservice architecture 'the right way' is a complex and subtle challenge" would capture a bit of what both of you are saying. Supporting API versioning is not a complex or subtle challenge. It's actually a very basic requirement of a microservice architecture. It's like having to test null pointers: it requires additional work but it's still a very basic requirement if you don't want your app to blow up in your face.
jeffasinger 8y ago
I think a bigger thing here, is that each deploy should have a REALLY good reason to not be backwards compatible for some pretty long time period. If that requirement is painful for you, then you probably have two pretty tightly coupled services.
balp 8y ago
To handle deploys and especially rollbacks you need a working CI, or rather CD chain. Where eveything is automated. In there are dependencied in your architecture, all of that needs to be part of the same deploy so you can redo the deploy before that one. With a monolith, you get a simple deploy of all dependencies, as they are baked into one thing. There are down sides of everything baked into one thing. Having all your "micoro" servies deplyed as one package, would make the dependency you have act as before the monolith change. Seeing this kinds of dependency imho even in a monolith are an architechture problem, that in the monolith shows up at code changed and fixes can't be handles by localized fixes, but changed have to go into large parts of the code base.

by merb 8y ago

tabtab 8y ago

How does one know if X is the wrong solution or if X is the right solution but the shop is "doing X wrong"? This also applies to monoliths: maybe they can scale, but one is doing them wrong. Changing from doing monoliths wrong to doing microservices wrong is obviously not progress. The same issue appeared when OOP was fairly new: people started using it heavily and ended up making messes. They were then told that they were "doing it wrong". OOP was initially sold as magic reusable Lego blocks that automatically create nice modularity. There was even an OOP magazine cover showing just that: a coder using magic Legos that farted kaleidoscopic glitter. Microservices is making similar promises. It took a while to learn where and how to use OOP and also when not to: it sucks at some things.

freedomben 8y ago
If you want to learn "the right way" I highly recommend "Building Microservices: Designing Fine-Grained Systems" by Sam Newman[1] [1] https://smile.amazon.com/Building-Microservices-Designing-Fine-Grained-Systems/dp/1491950358/ref=sr_1_3 https://smile.amazon.com/Building-Microservices-Designing-Fi...
notyourday 8y ago
I have posted about this before. OP is describing nano-services, not micro-services. Nano-service is micro-service that provides leftpad via JSON api. You have an auth.yourapp.com and api.yourapp.com and maybe tracer.yourapp.com and those three things are not a single app that behaves like auth, api or tracer depending on setting of a NODE_ENV variable? If so, you have micro services.
taneq 8y ago
Simple: If X is a technology I don't like, and it's not working for you, then it's the wrong solution. If X is a technology I don't like, and it is working for you, then you simply haven't scaled enough to understand its limitations. If X is a technology I like, but it's not working for you, then your shop is "doing X wrong". If X is a technology I like, and it's working for you, then it's the right solution and we're both very clever.
- staticassertion 8y ago
  edit: See below
  - taneq 8y ago
    Uh, my post was snark towards engineers' general tendency to champion and defend their own favourite architecture over competing approaches rather than focusing on the most suitable architecture for the circumstance, in response to this question: > How does one know if X is the wrong solution or if X is the right solution but the shop is "doing X wrong"? Edit: And a civil conversation ensued. :)
    - staticassertion 8y ago
      Sorry, I just misread your post as being more of an attack. As I had said, I dislike the constant "hype means something is bad" posts that I've been seeing for years - I think it's really unfortunate.
      - taneq 8y ago
        No worries, I can see how it might have been read that way in the wider context of the conversation. And I totally hear you on the "hype equals bad" thing. If something's popular, it's popular for a reason. That reason MIGHT just be trendoids jumping on a hype train, but it might also be because the thing is good.

mirkules 8y ago

Heh, I like that “Spaghetti Microservices”. You are right. It should not happen. It is difficult to see these pitfalls when unwinding an unwieldy monolith, and, as an organization all you’ve ever done are unwieldy monoliths, that have a gazillion dependencies, interfaces and factories. We learned from it, and we move on - hopefully, it serves as a warning to others.

tcbasche 8y ago
I've heard the term 'Distributed Monolith'
james_s_tayler 8y ago
MicroPasta
- cestith 8y ago
  Tangled angelhair.
c3534l 8y ago
I think we should call it angel-hair pasta code. You know, because it's very small spaghetti.
smnplk 8y ago
No, it's ravioli oriented architecture

dragonwriter 8y ago

> that should not happen. if it does you don't have a microservice architecture, you have a spaghetti service architecture. A "service" is not defined principally by a code repository or communications-channel boundary (though it should have the latter and may have the former), but by a coupling boundary. OTOH, maintaining a coupling boundary can have non-obvious pitfalls; e.g., supported message format versions can become a source of coupling--if you roll back a service to the version that can't send message format v3, but a consumer of the messages requires v3 and no longer supports consuming v2, then you have a problem.

merb 8y ago
you should never actually remove an api without a deprecation process. basically a message format is part of your api. actually in a microservice world your interfaces/api should be as stable as possible. if something gets changed, it needs to go trough a deprecation, that means not removing it until a certain amount of time.
- NicoJuicy 8y ago
  The accept header could fix this easily if no third parties are involved
- NicoJuicy 8y ago
  The accept header could fix this easily if no third parties are involved and if it's a rest like API protocol
  - dragonwriter 8y ago
    The accept header is a mechanism for communicating formats you support; it doesn't do anything to address the problem of managing change to supported versions, which is a dev process issue, not a technical issue.
    - geezerjay 8y ago
      > The accept header is a mechanism for communicating formats you support; it doesn't do anything to address the problem of managing change to supported versions That assertion is not true. Media type API versioning is a well established technique.

sequoia 8y ago

It sounds like you're paraphrasing the great Steven Jobs: "You're holding it wrong" Be that as it may, I believe mirkules's issue is not an uncommon one. Perhaps saying "building a microservice architecture 'the right way' is a complex and subtle challenge" would capture a bit of what both of you are saying. Something being complex and therefor easy to mess up does not mean it's a great system and the users are dumb, especially if there are other (less complicated, less easy to mess up) ways to complete the task.

geezerjay 8y ago
> Perhaps saying "building a microservice architecture 'the right way' is a complex and subtle challenge" would capture a bit of what both of you are saying. Supporting API versioning is not a complex or subtle challenge. It's actually a very basic requirement of a microservice architecture. It's like having to test null pointers: it requires additional work but it's still a very basic requirement if you don't want your app to blow up in your face.

jeffasinger 8y ago

I think a bigger thing here, is that each deploy should have a REALLY good reason to not be backwards compatible for some pretty long time period. If that requirement is painful for you, then you probably have two pretty tightly coupled services.

balp 8y ago

To handle deploys and especially rollbacks you need a working CI, or rather CD chain. Where eveything is automated. In there are dependencied in your architecture, all of that needs to be part of the same deploy so you can redo the deploy before that one. With a monolith, you get a simple deploy of all dependencies, as they are baked into one thing. There are down sides of everything baked into one thing. Having all your "micoro" servies deplyed as one package, would make the dependency you have act as before the monolith change. Seeing this kinds of dependency imho even in a monolith are an architechture problem, that in the monolith shows up at code changed and fixes can't be handles by localized fixes, but changed have to go into large parts of the code base.