3 ms·

I'm not convinced. If you're trying to debug a process, you should only operate on the messages and state. The messages you can log, and the state should ideall

I'm not convinced. If you're trying to debug a process, you should only operate on the messages and state. The messages you can log, and the state should ideally come only from messages, so you truly only need the messages. One of the strong points about this way of implementing interprocess communication, is that it allows you to have a new and old version of the same process working concurrently, with the new only running and comparing it's output with the old one. Once you're convinced they work the same, you can retire the old process. To fully leverage this, every message should be platform and implementation agnostic. Even if it's a monolithic system on a single server.

stareatgoats 9y ago
Well, all I can say is that I personally often find the full stack interesting when debugging exceptions, and might still try and implement passing stack info in my monolithic system (in spite of this discussion which might have been above my pay-grade honestly). In case it breaches some important CS principle that I don't fully grasp yet then it will surely come back and bite me - which has happened before ... :) . Anyway, thanks for your time.
- hvidgaard 9y ago
  You're welcome. I juggle those concepts and requirements daily, and I value explaining it to the developers. The "why are we doing it this way" is really important for their job satisfaction, and it happens that they have an aspect I didn't consider, or a better solution.
- edem 9y ago
  Your intuition is right. As a programmer your primary job is in most cases not mental masturbation and/or adhering to CS principles but shipping working software. We are all bound by the 80/20 rule and our job is do decide when to adhere to the principles and when to cut corners. In practice no one will care that you implemented a 100% pure microservice if you miss an important deadline, your company loses a $300M deal and your team ends up laid off. I'm not a business person, but a programmer. I also like writing beautiful code but we have to know the tradeoffs. If the tradeoff of having a beautiful service vs a nice service is 3 weeks of additional keyboard bashing it is not worth it. I once had a colleague who insisted on implementing all REST endpoints between microservices using HATEOAS/HAL because it will enable the consumption of such endpoints by programs and generated code. He spent a month refactoring our services and we ended up never using that feature, but modifying endpoints still carry that overhead he added.
edem 9y ago
This only makes sense if you work with different languages and/or a plugin architecture. I know that what you say is written in the books but in practice in 95% of the cases you will never write your new ser ice in language X and you will never switch from Hibernate to EclipseLink, etc. I'm not saying that abstractions are not useful. What I'm saying that over-architecting something on the possibly false premise that "at some time we might need to support X so let's do it by creating an additional abstraction" will waste time, money and will just end up as code clutter which you have to maintain.

stareatgoats 9y ago

Well, all I can say is that I personally often find the full stack interesting when debugging exceptions, and might still try and implement passing stack info in my monolithic system (in spite of this discussion which might have been above my pay-grade honestly). In case it breaches some important CS principle that I don't fully grasp yet then it will surely come back and bite me - which has happened before ... :) . Anyway, thanks for your time.

hvidgaard 9y ago
You're welcome. I juggle those concepts and requirements daily, and I value explaining it to the developers. The "why are we doing it this way" is really important for their job satisfaction, and it happens that they have an aspect I didn't consider, or a better solution.
edem 9y ago
Your intuition is right. As a programmer your primary job is in most cases not mental masturbation and/or adhering to CS principles but shipping working software. We are all bound by the 80/20 rule and our job is do decide when to adhere to the principles and when to cut corners. In practice no one will care that you implemented a 100% pure microservice if you miss an important deadline, your company loses a $300M deal and your team ends up laid off. I'm not a business person, but a programmer. I also like writing beautiful code but we have to know the tradeoffs. If the tradeoff of having a beautiful service vs a nice service is 3 weeks of additional keyboard bashing it is not worth it. I once had a colleague who insisted on implementing all REST endpoints between microservices using HATEOAS/HAL because it will enable the consumption of such endpoints by programs and generated code. He spent a month refactoring our services and we ended up never using that feature, but modifying endpoints still carry that overhead he added.

edem 9y ago

This only makes sense if you work with different languages and/or a plugin architecture. I know that what you say is written in the books but in practice in 95% of the cases you will never write your new ser ice in language X and you will never switch from Hibernate to EclipseLink, etc. I'm not saying that abstractions are not useful. What I'm saying that over-architecting something on the possibly false premise that "at some time we might need to support X so let's do it by creating an additional abstraction" will waste time, money and will just end up as code clutter which you have to maintain.