3 ms·

> Some people might take it at face value and end up with dozens if not hundreds of services You're worried that someone junior enough to run with random advic

> Some people might take it at face value and end up with dozens if not hundreds of services You're worried that someone junior enough to run with random advice is going to be able to rearchitect their entire codebase into hundreds of microservices and deploy it to production without testing its performance/stability/etc? I think they should try. It's a great way to learn why, and why not. > many people out there would probably agree with the claim that some general advice can definitely be dangerous. It's just mouth noises which aren't dangerous. We need to be able to hear other people's opinions (advice is just an opinion after all) without immediately adopting it.

KronisLV 4y ago
> You're worried that someone junior enough to run with random advice is going to be able to rearchitect their entire codebase into hundreds of microservices and deploy it to production without testing its performance/stability/etc? No, I'm worried that someone senior will do that, because they want microservices on their CV. This has happened in the past and will continue happening in the industry with every new technology or approach - as I'm sure many have seen projects get burned due to being an early adopter of Kubernetes or Kafka, or even microservices in general. As for how much testing should be done vs how much actually is done, you'd be surprised. While some orgs absolutely do things right, for a large part of them out there it's basically the Wild West - ship stuff and hope it works well enough. The entire e-health system of my country is a good example of this (though I cannot comment on the architecture itself): https://www-lsm-lv.translate.goog/raksts/zinas/zinu-analize/e-veselibu-radis-no-jauna-izmaksas-meramas-miljonos.a396672/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp https://www-lsm-lv.translate.goog/raksts/zinas/zinu-analize/... Some excerpts: In December, the availability of e-health was disrupted for seven days (with one exception - on weekdays), but it actually did not work for five more weekdays. For example, on December 7, none of the e-health services were available for more than four hours (4 h 13 min) during the working day. January looks a little better - there are disruptions on six working days, while in February e-health is disrupted for three days, but for four days it can be said that the system does not work. "If there are three, four interruptions for more than 10-15 minutes during an hour, then of course the user can be lucky to hit during the time when the system is working, but there are users who can only hit during the times when the system is not working, so I also marked red," explains Edgars Goba, deputy director of the National Health Service for information and communication technologies. One of the users of the system, family doctor Ingars Burlaks says: "I have been working with e-health from the very beginning, since it appeared. Unfortunately, those problems that were there from the beginning, those chronic problems, like the system hanging up or getting kicked out of the system when you get a screen with an exclamation mark, those problems persist." I've brought it up before, because it's one of the locally more well known examples. Furthermore, you'd think that it'd be the kind of system that should work: it's supposed to help with national healthcare, with millions spent on developing it, for the population of a small country. And yet, that's not the case. > I think they should try. It's a great way to learn why, and why not. This is something I can get behind for internal pilot projects, side projects, or hackathons and such. This is not something that I can get behind for projects with potential contractual penalties. > It's just mouth noises which aren't dangerous. We need to be able to hear other people's opinions (advice is just an opinion after all) without immediately adopting it. As long as no adopting advice at face value and no cargo culting follows, sure.
- LawTalkingGuy 4y ago
  > As long as no adopting advice at face value and no cargo culting follows, sure. I advise you to take all advice with a grain of salt. :) It's just what someone else thinks, it's not something magic. > I'm worried that someone senior will do that, because they want microservices on their CV Heh. I was going to say that the only way this advice is "dangerous" is if a point-haired boss hears about it. Someone padding a resume is the danger though, not the technology they choose. > This is something I can get behind for internal pilot projects, side projects, or hackathons and such. This is not something that I can get behind for projects with potential contractual penalties. Just don't merge it into the main branch. > The entire e-health system of my country is a good example of this [...] I'll check it out. Thanks.
  - KronisLV 4y ago
    > I advise you to take all advice with a grain of salt. :) It's just what someone else thinks, it's not something magic. Agreed, of course. Or maybe even suggestions that have some caution codified into them, such as "innovation tokens" from: https://boringtechnology.club/ https://boringtechnology.club/ Moderation in all things and so on. > Heh. I was going to say that the only way this advice is "dangerous" is if a point-haired boss hears about it. This is also true. I would definitely suggest that there are industry wide trends that urge people to rush towards "the next big thing" or sometimes adopt certain technologies or approaches because "others are doing it, so clearly we also have to". Perhaps a lot of it can simply be summed up by hype cycles: https://en.wikipedia.org/wiki/Gartner_hype_cycle https://en.wikipedia.org/wiki/Gartner_hype_cycle > Just don't merge it into the main branch. The problem the way I see it, is that people don't just experiment with new architectures within the confines of an existing system. Typically they give in to the "second system effect" in regards to their former tech choices when starting a new project, which can have long term implications and choices that are really hard to change down the line: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect But hey, at the opposite end of that spectrum, maybe I shout at the cloud too much; exploring new stuff is certainly desirable - there were certainly benefits to being an early adopter of something like Docker or 12 Factor App principles, even though not without seeing what works and what doesn't in non-prod projects first.

KronisLV 4y ago

> You're worried that someone junior enough to run with random advice is going to be able to rearchitect their entire codebase into hundreds of microservices and deploy it to production without testing its performance/stability/etc? No, I'm worried that someone senior will do that, because they want microservices on their CV. This has happened in the past and will continue happening in the industry with every new technology or approach - as I'm sure many have seen projects get burned due to being an early adopter of Kubernetes or Kafka, or even microservices in general. As for how much testing should be done vs how much actually is done, you'd be surprised. While some orgs absolutely do things right, for a large part of them out there it's basically the Wild West - ship stuff and hope it works well enough. The entire e-health system of my country is a good example of this (though I cannot comment on the architecture itself): https://www-lsm-lv.translate.goog/raksts/zinas/zinu-analize/e-veselibu-radis-no-jauna-izmaksas-meramas-miljonos.a396672/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp https://www-lsm-lv.translate.goog/raksts/zinas/zinu-analize/... Some excerpts: In December, the availability of e-health was disrupted for seven days (with one exception - on weekdays), but it actually did not work for five more weekdays. For example, on December 7, none of the e-health services were available for more than four hours (4 h 13 min) during the working day. January looks a little better - there are disruptions on six working days, while in February e-health is disrupted for three days, but for four days it can be said that the system does not work. "If there are three, four interruptions for more than 10-15 minutes during an hour, then of course the user can be lucky to hit during the time when the system is working, but there are users who can only hit during the times when the system is not working, so I also marked red," explains Edgars Goba, deputy director of the National Health Service for information and communication technologies. One of the users of the system, family doctor Ingars Burlaks says: "I have been working with e-health from the very beginning, since it appeared. Unfortunately, those problems that were there from the beginning, those chronic problems, like the system hanging up or getting kicked out of the system when you get a screen with an exclamation mark, those problems persist." I've brought it up before, because it's one of the locally more well known examples. Furthermore, you'd think that it'd be the kind of system that should work: it's supposed to help with national healthcare, with millions spent on developing it, for the population of a small country. And yet, that's not the case. > I think they should try. It's a great way to learn why, and why not. This is something I can get behind for internal pilot projects, side projects, or hackathons and such. This is not something that I can get behind for projects with potential contractual penalties. > It's just mouth noises which aren't dangerous. We need to be able to hear other people's opinions (advice is just an opinion after all) without immediately adopting it. As long as no adopting advice at face value and no cargo culting follows, sure.

LawTalkingGuy 4y ago
> As long as no adopting advice at face value and no cargo culting follows, sure. I advise you to take all advice with a grain of salt. :) It's just what someone else thinks, it's not something magic. > I'm worried that someone senior will do that, because they want microservices on their CV Heh. I was going to say that the only way this advice is "dangerous" is if a point-haired boss hears about it. Someone padding a resume is the danger though, not the technology they choose. > This is something I can get behind for internal pilot projects, side projects, or hackathons and such. This is not something that I can get behind for projects with potential contractual penalties. Just don't merge it into the main branch. > The entire e-health system of my country is a good example of this [...] I'll check it out. Thanks.
- KronisLV 4y ago
  > I advise you to take all advice with a grain of salt. :) It's just what someone else thinks, it's not something magic. Agreed, of course. Or maybe even suggestions that have some caution codified into them, such as "innovation tokens" from: https://boringtechnology.club/ https://boringtechnology.club/ Moderation in all things and so on. > Heh. I was going to say that the only way this advice is "dangerous" is if a point-haired boss hears about it. This is also true. I would definitely suggest that there are industry wide trends that urge people to rush towards "the next big thing" or sometimes adopt certain technologies or approaches because "others are doing it, so clearly we also have to". Perhaps a lot of it can simply be summed up by hype cycles: https://en.wikipedia.org/wiki/Gartner_hype_cycle https://en.wikipedia.org/wiki/Gartner_hype_cycle > Just don't merge it into the main branch. The problem the way I see it, is that people don't just experiment with new architectures within the confines of an existing system. Typically they give in to the "second system effect" in regards to their former tech choices when starting a new project, which can have long term implications and choices that are really hard to change down the line: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect But hey, at the opposite end of that spectrum, maybe I shout at the cloud too much; exploring new stuff is certainly desirable - there were certainly benefits to being an early adopter of something like Docker or 12 Factor App principles, even though not without seeing what works and what doesn't in non-prod projects first.