4 ms·

The problem is that there are so many developers now who have never had any experience of anything that isn't some botched attempt at microservices. The idea th

by ris 5y ago

The problem is that there are so many developers now who have never had any experience of anything that isn't some botched attempt at microservices. The idea that it's possible to encapsulate code and separate concerns in any other way is foreign to them, and an "API" to them is 100% synonymous with a rest/grpc interface. So there's nothing for them to revert to and they are doomed to repeat this pattern, clearly with the impression that this is what app development is. Meanwhile a lot of the industry is trying to tell them that their problem is they haven't separated things enough and should be using lambdas for everything.

bob1029 5y ago
> So there's nothing for them to revert to and they are doomed to repeat this pattern, clearly with the impression that this is what app development is The only practical solution I have found for this: Carefully select a Padawan and guide them gently away from the forces of evil until they have gained enough situational awareness to spot these patterns and defend themselves. Not everyone can be saved, and at this point I fear that it is a majority. If someone goes too far into cloud insanity, there is (in my experience) very little you can do to bring them back down to reality. At least, not on time frames the business owners seemed interested in when looking at new hires. I have had a much easier time taking in someone totally green and getting them happy/productive on monolithic software than I have with uService/AWS-certified 'experts' (et. al.).
- dhzhzjsbevs 5y ago
  I tried that for a while but now my reviews are basically: "No, stop, don't." https://youtu.be/uVdDXeYM4ss https://youtu.be/uVdDXeYM4ss It's like I'm talking to children, they think I'm just old and stuck in my ways and that I just don't understand. Eventually my prediction comes true but none of them have ever said anything, they just go implement what I suggested and act like they solved the world's greatest mystery. I guess it's easy to forget my comments from months earlier, it's almost as if I've seen their code before and know how it ends.
  - stavros 5y ago
    Ah yes, the curse of Cassandra. https://en.wikipedia.org/wiki/Cassandra_(metaphor) https://en.wikipedia.org/wiki/Cassandra_(metaphor)
wallfacer120 5y ago
This is happening to me, its driving me nuts. Any advice on how to get out of it?
- abakker 5y ago
  My advice would be to carefully construct an explanations of the scenarios when microservices do apply, and then explain why you are not currently in that situation. the best microservice examples I've ever found were for the addition of features to legacy systems, the ability to write minor additional things in alternate languages, and most critically, when the original code base couldn't be changed or was lost, and yet more functionality was required. There are valid reasons to add a microservice there are probably not good reasons to take a normal code base made by a modern company and completely shift to only microservices.
  - throwaway6532 5y ago
    >My advice would be to carefully construct an explanations of the scenarios when microservices do apply, and then explain why you are not currently in that situation. I tried that once. Didn't work. End result was just pure pain.
- bob1029 5y ago
  One thing that has periodically worked for me is the application of some fun infographic-tier latency figures to really drive home the argument for why distributed anything generally sucks ass. I.e. Would you rather that customer transaction either be: 1) A direct method invocation resolved within the same L1 cache contents. or 2) One quick network hop just 5 milliseconds away? Assuming worst case processing semantics (global total order), you would be able to process ~10 million times more customer transactions per unit time with option 1 vs option 2. This is seven orders of magnitude. In my experience, not a whole lot is truly worst case, but most complicated & important business systems (banking/finance/inventory/logistics/crm/etc.) are pretty close if you don't want to be chasing temporal rabbits around all day.
  - willcipriano 5y ago

by ris 5y ago

bob1029 5y ago

> So there's nothing for them to revert to and they are doomed to repeat this pattern, clearly with the impression that this is what app development is The only practical solution I have found for this: Carefully select a Padawan and guide them gently away from the forces of evil until they have gained enough situational awareness to spot these patterns and defend themselves. Not everyone can be saved, and at this point I fear that it is a majority. If someone goes too far into cloud insanity, there is (in my experience) very little you can do to bring them back down to reality. At least, not on time frames the business owners seemed interested in when looking at new hires. I have had a much easier time taking in someone totally green and getting them happy/productive on monolithic software than I have with uService/AWS-certified 'experts' (et. al.).

dhzhzjsbevs 5y ago
I tried that for a while but now my reviews are basically: "No, stop, don't." https://youtu.be/uVdDXeYM4ss https://youtu.be/uVdDXeYM4ss It's like I'm talking to children, they think I'm just old and stuck in my ways and that I just don't understand. Eventually my prediction comes true but none of them have ever said anything, they just go implement what I suggested and act like they solved the world's greatest mystery. I guess it's easy to forget my comments from months earlier, it's almost as if I've seen their code before and know how it ends.
- stavros 5y ago
  Ah yes, the curse of Cassandra. https://en.wikipedia.org/wiki/Cassandra_(metaphor) https://en.wikipedia.org/wiki/Cassandra_(metaphor)

wallfacer120 5y ago

This is happening to me, its driving me nuts. Any advice on how to get out of it?

abakker 5y ago
My advice would be to carefully construct an explanations of the scenarios when microservices do apply, and then explain why you are not currently in that situation. the best microservice examples I've ever found were for the addition of features to legacy systems, the ability to write minor additional things in alternate languages, and most critically, when the original code base couldn't be changed or was lost, and yet more functionality was required. There are valid reasons to add a microservice there are probably not good reasons to take a normal code base made by a modern company and completely shift to only microservices.
- throwaway6532 5y ago
  >My advice would be to carefully construct an explanations of the scenarios when microservices do apply, and then explain why you are not currently in that situation. I tried that once. Didn't work. End result was just pure pain.
bob1029 5y ago
One thing that has periodically worked for me is the application of some fun infographic-tier latency figures to really drive home the argument for why distributed anything generally sucks ass. I.e. Would you rather that customer transaction either be: 1) A direct method invocation resolved within the same L1 cache contents. or 2) One quick network hop just 5 milliseconds away? Assuming worst case processing semantics (global total order), you would be able to process ~10 million times more customer transactions per unit time with option 1 vs option 2. This is seven orders of magnitude. In my experience, not a whole lot is truly worst case, but most complicated & important business systems (banking/finance/inventory/logistics/crm/etc.) are pretty close if you don't want to be chasing temporal rabbits around all day.
- willcipriano 5y ago