Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The costs of microservices (2020)

robertovitillo.com

Post reply on HN
Print view View original

91–100 of 410 posts

Re: The costs of microservices (2020)

#91

Post by insanitybit »

jacquesm wrote: post #65
vrosas wrote: post #40

Earlier quoted context omitted.

The other problem is that these self-imposed roadblocks are so engrained in the modern SDLC that developers literally cannot imagine a world where they do not exist. I got _reamed_ by some "senior" engineers for merging a small PR without an approval recently. And we're not some megacorp, we're a 12 person engineering startup! We can make our own rules! We don't even have any customers...

Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that. This could come back to haunt you later on when you by your lonesome decide to merge a 'small PR' with massive downtime as a result of not having your code reviewed. Ok, you say, I'm perfect. And I believe you. But now you have another problem: the other junior devs on your team who see vros…

> Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that

Why? Because it's a "good practice"? They have 12 people and no customers, they can almost certainly adopt a very aggressive developer cycle that optimizes almost exclusively for happy-path velocity. You'd never do that at 50+ engineers with customers but for 12 engineers who have no customers? It's fine, in fact it's ideal.

> with massive downtime as a result.

They have no customers, downtime literally does not exist for them. You are following a dogmatic practice that is optimizing for a situation that literally does not exist within their company.

Re: The costs of microservices (2020)

#92

Post by [deleted] »

insanitybit wrote: post #38
jihadjihad wrote: post #2

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug https://grugbrain.dev/#grug-on-microservices

Network calls are a powerful thing to introduce. It means that you have an impassable boundary, one that is actually physically enforced - your two services have to treat each other as if they are isolated. Isolation is not anything to scoff at, it's one of the most powerful features you can encode into your software. Isolation can improve performance, it can create fault boundaries, it can provide security boundarie…

[deleted]

Re: The costs of microservices (2020)

#93

Post by jacquesm »

vrosas wrote: post #83
jacquesm wrote: post #65

Earlier quoted context omitted.

Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that. This could come back to haunt you later on when you by your lonesome decide to merge a 'small PR' with massive downtime as a result of not having your code reviewed. Ok, you say, I'm perfect. And I believe you. But now you have another problem: the other junior devs on your team who see vros…

I'm challenging my team to actually think about that process, why it's in place, how it's helping (or actively hurting!) us. Comparing ourselves to companies that have regulatory requirements (spoiler: we don't and likely won't for a long, long time) just furthers my point that no one really thinks about these things. They just cargo cult how everyone else does it.

You can challenge them without actually violating established process. I wasn't comparing you to companies that have regulatory requirements, I was merely saying that all of the above will factor in much, much stronger still in a regulated industry.

But not being in a regulated industry doesn't mean there isn't a very good reason to have a code review in your process, assuming it is used effectively and not for nitpicking.

Not having a code review step is usually a bad idea, unless everybody on your team is of absolutely amazing quality and they never make silly mistakes. I've yet to come across a team like that, but maybe you are the exception to the rule.

Re: The costs of microservices (2020)

#94

Post by jeffbee »

Scarblac wrote: post #25
jeffbee wrote: post #9

Earlier quoted context omitted.

I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. I think everyone recognizes that it makes sense that domain name resolution is performed by an external service, and very few people are out there integrating a recursive DNS resolver and cache into their monolith. And yet, this long-standing division of responsibility never seems to count as an example…

_Services_ are obviously a good idea (nobody is arguing something like PostgreSQL or Redis or DNS or what have you should all run in the same process as the web server). _Microservices_ attract the criticism. It seems to assume something about the optimal size of services ("micro") that probably isn't optimal for all kinds of service you can think of.

This seems subjective. It's like putting "compatible with the character of the neighborhood" in a city's zoning codes.

Re: The costs of microservices (2020)

#95

Post by jacquesm »

insanitybit wrote: post #91
jacquesm wrote: post #65

Earlier quoted context omitted.

Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that. This could come back to haunt you later on when you by your lonesome decide to merge a 'small PR' with massive downtime as a result of not having your code reviewed. Ok, you say, I'm perfect. And I believe you. But now you have another problem: the other junior devs on your team who see vros…

> Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that Why? Because it's a "good practice"? They have 12 people and no customers, they can almost certainly adopt a very aggressive developer cycle that optimizes almost exclusively for happy-path velocity. You'd never do that at 50+ engineers with customers but for 12 engineers who have no custom…

You establish a process before you need it, and code review, especially when starting up is a fantastic way to make sure that everybody is on the same page and that you don't end up with a bunch of latent issues further down the line. The fact that they have no customers today doesn't mean that they won't have any in the future and mistakes made today can cause downtime further down the line.

If you're wondering why software is crap: it is because every new generation of coders insists on making all the same mistakes all over again. Learn from the past, understand that 'good practice' has been established over many years of very expensive mistakes. 12 engineers is already a nice little recipe for pulling in 12 directions at once and even if they're all perfect they can still learn from looking at each others code and it will ensure that there are no critical dependencies on single individuals (which can bite you hard if one of them decides to leave, not unheard of in a startup) and that if need be labor can be re-divided without too much hassle.

Re: The costs of microservices (2020)

#96

Post by nightowl_games »

I tried to use an eBPF sampling profiler to produce a flame graph/marker chart of our c/c++ desktop application. I struggled to get it going, seems like the existing tools are for kernel level profiling and more complicated stuff.

Anyone recommend a simple technique to produce a quality profiler report for profiling a desktop application? Honestly the chrome/firefox profiler is so great that I do wasm builds and use those. Ideally Id like a native profiler that can output .json that chrome/ff can open in it's profile analyzer.

Re: The costs of microservices (2020)

#97

Post by aleksiy123 »

tazard wrote: post #87
aleksiy123 wrote: post #80

I recently had some discussions and did some research on this topic and I feel like there is a lot people don't talk about in these articles. Here are some more considerations between micro services and monolothic tradeoffs. Its also important to consider these two things as a scale and not a binary decision. 1. Isolation. Failure in on service doesn't fail the whole system. Smaller services have better isolation. 2.…

1. Isolation With a well built monolith, a failure on a service won't fail the whole system. For poorly built microservices, a failure on a service absolutely does being down the whole system. Not sure I am convinced that by adopting microservices, your code automatically gets better isolation

Its not automatic but it has the potential for more isolation by definition.

If your service has memory leak, crash it only takes down the service. It is still up to your system to handle such a failure gracefully. If such a service is a critical dependency then your system fails. But if it is not then your service can still partially function.

If your monolith has memory leak, or crash it takes down the whole monolith.

Re: The costs of microservices (2020)

#98

Post by codesnik »

lcfcjs wrote: post #4

Interesting article. Although one point I'd like to contest is the first "pro" which is you can use a different language for each service. We tried this approach and it failed fantastically. You're right about the cons, it becomes un-maintable. We had 3 microservices that we maintained on our team, one in Java, one in Ruby and one in Node. We very quickly realized we needed to stick to one, in order to share code, st…

lemme guess, you all converged to Java?

Re: The costs of microservices (2020)

#99

Post by insanitybit »

jacquesm wrote: post #95
insanitybit wrote: post #91

Earlier quoted context omitted.

> Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that Why? Because it's a "good practice"? They have 12 people and no customers, they can almost certainly adopt a very aggressive developer cycle that optimizes almost exclusively for happy-path velocity. You'd never do that at 50+ engineers with customers but for 12 engineers who have no custom…

You establish a process before you need it, and code review, especially when starting up is a fantastic way to make sure that everybody is on the same page and that you don't end up with a bunch of latent issues further down the line. The fact that they have no customers today doesn't mean that they won't have any in the future and mistakes made today can cause downtime further down the line. If you're wondering why…

I'm not advocating for having no processes, I'm advocating for a process that matches their situation. A company with no customers should not be worrying about causing a production outage, they should be worried about getting a demoable product out.

Dogmatic adherence to a process that limits developer velocity and optimizes for correct code is very likely the wrong call when you have no customers.

Re: The costs of microservices (2020)

#100

Post by furstenheim »

voxic11 wrote: post #76
eterevsky wrote: post #58

Earlier quoted context omitted.

1) Why is it better than wrapping it in an interface with a clear API without extracting it into a separate service?

Because of dependency issues like he mentioned. If I am using Library A which depends on version 1 of Library C and I need to start using Library B which depends on version 2 of Library C then I have a clear problem because most popular programming languages don't support referencing multiple different versions of the same library.

This node got it just right. You only get this issue for big stateful libraries, like frameworks
Post reply on HN