3 ms·

Yeah, I read this post as a dig at "cargo cult" programmers who read up on google-scale programming and best practice and unthinkingly apply those constructs to

Yeah, I read this post as a dig at "cargo cult" programmers who read up on google-scale programming and best practice and unthinkingly apply those constructs to their own Bob's-Restaurant-scale task at hand where they are often at best an unneeded time and complexity overhead.

Cthulhu_ 3y ago
I've worked in a number of projects where they decided to move to microservices for reasons they wish they had, while not fully understanding microservices or applying basic litmus tests to where to split off services. So we ended up with great puzzles like how to link an order service with an inventory service to check if there's enough inventory to fulfill an order, all through a central event bus. Then of course the order service has to update the inventory if the order is confirmed. But of course, the order service also has to talk to the pricing service, and since the price of products varies by day, they'd have to remember the price at the time the order was made. Whose responsibility is that? No idea, that's someone else's service.
- collyw 3y ago
  We had a dev in my last work pushing to microservice everything (small company, only a few developers). I could tell that it was going to cause more pain than it was going to solve. Plus, every service that you add makes setting up a development machine even more difficult.
  - beezlewax 3y ago
    Not to mention testing all of this. Its an absolute nightmare.
    - collyw 3y ago
      Replacing function calls with network calls is only going to make things more difficult.
- robofanatic 3y ago
  There is a youtube video for that https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
- deleted 3y ago
  [deleted]
- 908B64B197 3y ago
  > I've worked in a number of projects where they decided to move to microservices for reasons they wish they had I've advised engineers to rewrite code before, mostly for resume building to help jumping ship to somewhere better. Basically, use the current job as a way to train on the stack the company you really want to work for is using. If a company doesn't have a stock-based comp and sticks to prevailing wages/CoL there's no incentive to help the company succeed. Especially with non-technical management, the best thing to do for ICs is often to aggressively rewrite (in the language that's trendy right now and that better companies use) and get promoted by showing off a significant output. Then jump to a better company having spent a year training on their stack at the previous company's expenses.
  - epups 3y ago
    This is a good point. The other side of the coin is that by not moving to a modern day stack, the company slowly finds it harder and harder to attract staff to maintain it. So, keeping up with trends is not just good for the ICs.
  - kartoshechka 3y ago
    this might come as incredibly cynic for some, but illustrates an important point - languages/frameworks/whole marketed stacks like ELK are merely tools for you to accomplish the task, which in the end is either to reduce costs or increase revenue so naturally it doesn't matter (in long term) what you should learn to get a first job, change jobs, change domains - prioritize ROI the tool would give you in future, a job market, and your sanity :)
  - smilliken 3y ago
    It's unprofessional to do this in conflict with your company's interests. Use your own hobby projects to learn instead of leaving a maintenance project for your coworkers. It also creates an invisible bias towards worse companies in your next position, because smart companies are wary about this kind of behavior, and will be savvy to filter out candidates that have displayed it.
    - 908B64B197 3y ago
- hbrn 3y ago
  Unfortunately it's not a popular belief anymore, but [asynchronous] central event bus is a terrible idea on it's own, and it goes against what [micro]services are about. If you want microservices to work you shouldn't have anything central in them, and you should avoid async as much as possible.
  - karmakaze 3y ago
    That's not at all what I learned from working with microservices. The worst thing you can do is make sync calls between services, then you end up with high aggregate failure rates, and/or large request latency from retries as well as low uptime due to dependency couplings. One-way async dataflows work much better. That way each microservice is up with all the (potentially delayed) data it needs to respond to requests.
    - hbrn 3y ago
      If you have services with lots of dependencies on other services, then you probably ended up the worst of two worlds - distributed monolith. Typically one-way or two-way is not a choice you can make as an engineer, most processes in your business require two-way, because they are initiated by a user and user wants a definitive response. The "potentially delayed" approach is very tempting for engineers, but it should be exception rather than the rule. It - dilutes responsibilities between services (who is responsible for delays? is service A producing too many messages or is service B too slow to process them?) - makes your SLA vague (message was processed 3 days later, do we treat it as downtime or not?) - requires more infrastructure & processes (every service has a queue, dead-letter queue, and a process to deal with dead letters) - requires a ton monitoring overhead (what delay is acceptable? how do we even measure delay? what if you have different SLA for different messages? we'll have a monitor per message type?) - introduces a lot of unnecessary complexity and rules (how do you deal with TOCTOU, e.g. admin deactivates a user, but by the time the message gets processed he's no longer an admin) - ruins user experience (we received your payment information, but we won't immediately tell you that it's wrong). Despite it's downsides, potentially delayed approach can be a fine tradeoff when it saves you 7-8 digits per year. Most companies never reach this phase.

Cthulhu_ 3y ago

I've worked in a number of projects where they decided to move to microservices for reasons they wish they had, while not fully understanding microservices or applying basic litmus tests to where to split off services. So we ended up with great puzzles like how to link an order service with an inventory service to check if there's enough inventory to fulfill an order, all through a central event bus. Then of course the order service has to update the inventory if the order is confirmed. But of course, the order service also has to talk to the pricing service, and since the price of products varies by day, they'd have to remember the price at the time the order was made. Whose responsibility is that? No idea, that's someone else's service.

collyw 3y ago
We had a dev in my last work pushing to microservice everything (small company, only a few developers). I could tell that it was going to cause more pain than it was going to solve. Plus, every service that you add makes setting up a development machine even more difficult.
- beezlewax 3y ago
  Not to mention testing all of this. Its an absolute nightmare.
  - collyw 3y ago
    Replacing function calls with network calls is only going to make things more difficult.
robofanatic 3y ago
There is a youtube video for that https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
deleted 3y ago
[deleted]
908B64B197 3y ago
> I've worked in a number of projects where they decided to move to microservices for reasons they wish they had I've advised engineers to rewrite code before, mostly for resume building to help jumping ship to somewhere better. Basically, use the current job as a way to train on the stack the company you really want to work for is using. If a company doesn't have a stock-based comp and sticks to prevailing wages/CoL there's no incentive to help the company succeed. Especially with non-technical management, the best thing to do for ICs is often to aggressively rewrite (in the language that's trendy right now and that better companies use) and get promoted by showing off a significant output. Then jump to a better company having spent a year training on their stack at the previous company's expenses.
- epups 3y ago
  This is a good point. The other side of the coin is that by not moving to a modern day stack, the company slowly finds it harder and harder to attract staff to maintain it. So, keeping up with trends is not just good for the ICs.
- kartoshechka 3y ago
  this might come as incredibly cynic for some, but illustrates an important point - languages/frameworks/whole marketed stacks like ELK are merely tools for you to accomplish the task, which in the end is either to reduce costs or increase revenue so naturally it doesn't matter (in long term) what you should learn to get a first job, change jobs, change domains - prioritize ROI the tool would give you in future, a job market, and your sanity :)
- smilliken 3y ago
  It's unprofessional to do this in conflict with your company's interests. Use your own hobby projects to learn instead of leaving a maintenance project for your coworkers. It also creates an invisible bias towards worse companies in your next position, because smart companies are wary about this kind of behavior, and will be savvy to filter out candidates that have displayed it.
  - 908B64B197 3y ago
hbrn 3y ago
Unfortunately it's not a popular belief anymore, but [asynchronous] central event bus is a terrible idea on it's own, and it goes against what [micro]services are about. If you want microservices to work you shouldn't have anything central in them, and you should avoid async as much as possible.
- karmakaze 3y ago
  That's not at all what I learned from working with microservices. The worst thing you can do is make sync calls between services, then you end up with high aggregate failure rates, and/or large request latency from retries as well as low uptime due to dependency couplings. One-way async dataflows work much better. That way each microservice is up with all the (potentially delayed) data it needs to respond to requests.
  - hbrn 3y ago
    If you have services with lots of dependencies on other services, then you probably ended up the worst of two worlds - distributed monolith. Typically one-way or two-way is not a choice you can make as an engineer, most processes in your business require two-way, because they are initiated by a user and user wants a definitive response. The "potentially delayed" approach is very tempting for engineers, but it should be exception rather than the rule. It - dilutes responsibilities between services (who is responsible for delays? is service A producing too many messages or is service B too slow to process them?) - makes your SLA vague (message was processed 3 days later, do we treat it as downtime or not?) - requires more infrastructure & processes (every service has a queue, dead-letter queue, and a process to deal with dead letters) - requires a ton monitoring overhead (what delay is acceptable? how do we even measure delay? what if you have different SLA for different messages? we'll have a monitor per message type?) - introduces a lot of unnecessary complexity and rules (how do you deal with TOCTOU, e.g. admin deactivates a user, but by the time the message gets processed he's no longer an admin) - ruins user experience (we received your payment information, but we won't immediately tell you that it's wrong). Despite it's downsides, potentially delayed approach can be a fine tradeoff when it saves you 7-8 digits per year. Most companies never reach this phase.