4 ms·

So... you worked on something terrible that people called a "microservice architecture"? Once a pattern gets popular, people start writing nasty code in the sty

by pkulak 5y ago

So... you worked on something terrible that people called a "microservice architecture"? Once a pattern gets popular, people start writing nasty code in the style, and then the pattern takes the reputation hit and people move on to the next thing (or just back to the last thing). Rinse, repeat. My company uses microservices; deploys restart one service and PRs are one repo at a time. There's a shared library, but it's versioned and there's nothing compelling you to keep on the bleeding edge.

jmchuster 5y ago
Is this something a lot of people are missing with their microservice implementation? You need to be able to deploy each microservice independently of everyone else. If you have a change that's spread across multiple services, you should be able to just do them one-by-one in order. If you want to rollout a shared library, you should be able to just update your services one-by-one. If a coordinated rollout is required, then doesn't that kind of defeat the whole point of doing microservices?
- dragonwriter 5y ago
  > If a coordinated rollout is required, then doesn't that kind of defeat the whole point of doing microservices? If a coordinated rollout is requires for anything but a change of service API (and then only the service and it's direct clients should be impacted, and even then a decent deprecation policy should eliminate the need for close coordination), you aren't doing microservices, because loose coupling is part of the definition of the pattern.
- Gigachad 5y ago
  Its a big anti pattern I have seen that a change requires simultaneous merges on multiple repos and there is basically no way to avoid possible outages/broken systems in the middle period while its deploying.
dragonwriter 5y ago
> Once a pattern gets popular, people start writing nasty code in the style, Once it gets popular, people start “implementing the pattern” based on rumor, bad descriptions from unqualified (and sometimes ill-motivated) intermediaries, and some boss and/or tech lead’s fever dreams, and blaming it on the pattern. (If the pattern is useful enough, it will be later invented under a new name to escape from the accumulated cruft, which will briefly succeed only to succumb to the same process until another cycle passes.)
- throwaway6532 5y ago
  It there some sort of technical name for this phenomenon? Maybe like "pattern decay" or "technical decay"? From what I have observed in all throughout my career this happens to every pattern eventually. People that come up with it obviously understand it themselves, but they have to serialize their understanding into some format like a conference talk or a book, which is inherently lossy as it's not an implementation, people in the wider community then deserialize the original understanding and (try) build an implementation out of it thus providing a myriad of serialized (but wrong) understandings out in the wild that are then encountered by subsequent waves of engineers who then take the pattern to have a new definition than the originally intended one.
  - drwiggly 5y ago
    Its just cargo culting. A lot of programming advice/processes are fuzzy in a wider context. Generally they came to be in a specific context. Relating that context is hard. Eventually its picked up as a fad and spread around, just like a game of telephone we lose nuance and context. Pair this with imposter syndrome and low confidence, everyone tries to cover their ass and do what the current hype in the industry is doing. What if I suggested an architecture where every 5th call had the overhead of serialization and network time. Also the reliability and concern issues that go with multi machine calls. Data syncing issues and network partition concerns. Pretty sure most people couldn't reason about this system. They'd suggest instead of having network calls on every 5th call, lets really look at our use case and only insert them where we may have load issues and have to scale. Data state becomes a big concern, make sure we know where our data is at all times and is only passed when needed to be correct and not over pass it to be efficient.

by pkulak 5y ago

jmchuster 5y ago

Is this something a lot of people are missing with their microservice implementation? You need to be able to deploy each microservice independently of everyone else. If you have a change that's spread across multiple services, you should be able to just do them one-by-one in order. If you want to rollout a shared library, you should be able to just update your services one-by-one. If a coordinated rollout is required, then doesn't that kind of defeat the whole point of doing microservices?

dragonwriter 5y ago
> If a coordinated rollout is required, then doesn't that kind of defeat the whole point of doing microservices? If a coordinated rollout is requires for anything but a change of service API (and then only the service and it's direct clients should be impacted, and even then a decent deprecation policy should eliminate the need for close coordination), you aren't doing microservices, because loose coupling is part of the definition of the pattern.
Gigachad 5y ago
Its a big anti pattern I have seen that a change requires simultaneous merges on multiple repos and there is basically no way to avoid possible outages/broken systems in the middle period while its deploying.

dragonwriter 5y ago

> Once a pattern gets popular, people start writing nasty code in the style, Once it gets popular, people start “implementing the pattern” based on rumor, bad descriptions from unqualified (and sometimes ill-motivated) intermediaries, and some boss and/or tech lead’s fever dreams, and blaming it on the pattern. (If the pattern is useful enough, it will be later invented under a new name to escape from the accumulated cruft, which will briefly succeed only to succumb to the same process until another cycle passes.)

throwaway6532 5y ago
It there some sort of technical name for this phenomenon? Maybe like "pattern decay" or "technical decay"? From what I have observed in all throughout my career this happens to every pattern eventually. People that come up with it obviously understand it themselves, but they have to serialize their understanding into some format like a conference talk or a book, which is inherently lossy as it's not an implementation, people in the wider community then deserialize the original understanding and (try) build an implementation out of it thus providing a myriad of serialized (but wrong) understandings out in the wild that are then encountered by subsequent waves of engineers who then take the pattern to have a new definition than the originally intended one.
- drwiggly 5y ago
  Its just cargo culting. A lot of programming advice/processes are fuzzy in a wider context. Generally they came to be in a specific context. Relating that context is hard. Eventually its picked up as a fad and spread around, just like a game of telephone we lose nuance and context. Pair this with imposter syndrome and low confidence, everyone tries to cover their ass and do what the current hype in the industry is doing. What if I suggested an architecture where every 5th call had the overhead of serialization and network time. Also the reliability and concern issues that go with multi machine calls. Data syncing issues and network partition concerns. Pretty sure most people couldn't reason about this system. They'd suggest instead of having network calls on every 5th call, lets really look at our use case and only insert them where we may have load issues and have to scale. Data state becomes a big concern, make sure we know where our data is at all times and is only passed when needed to be correct and not over pass it to be efficient.