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

131–140 of 410 posts

Re: The costs of microservices (2020)

#131

Post by aleksiy123 »

manicennui wrote: post #108
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. Except that a single process usually involves multiple services and the failure of one service often makes entire sequences impossible.

But not all sequences. It depends on your dependencies. Some services are critical for some processes. In the monoloth design its a critical dependency for all processes.

Re: The costs of microservices (2020)

#132

Post by charcircuit »

sethammons wrote: post #7
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

grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores. "We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 5…

Other teams can access your data directly even if it's in your own separate database.

Re: The costs of microservices (2020)

#133

Post by esafak »

shadowgovt wrote: post #78
sethammons wrote: post #7

Earlier quoted context omitted.

grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores. "We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 5…

As with so many software solutions, the success of microservices is predicated upon having sufficient prognostication about how the system will be used to recognize where the cut-points are. When I hear success stories like that, I have to ask "Is there some inherent benefit to the abstraction or did you get lucky in picking your cleave-points?"

That comes with experience, but you can let time be the judge if you factor your monolith early enough. If the factorization proves stable, proceed with carving it into microservices.

Re: The costs of microservices (2020)

#134

Post by nevinera »

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…

With no customers, one of the purposes of code-review is removed, but it's the lesser one anyway. The primary goal of code-review should _not_ be to "catch mistakes" in a well-functioning engineering team - that's a thing that happens, but mostly your CI handles that. Code-review is about unifying approaches, cross-pollinating strategies and techniques, and helping each other to improve as engineers.

Your attitude towards code-review on the other hand is one I've seen before several times, and I was glad when each of those people were fired.

Re: The costs of microservices (2020)

#135

Post by mgkimsal »

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…

Then... the people responsible for this should have blocked PRs without a review. Or protected the target branch. Or... something. If it's sacrosanct to do what OP did, but the 'senior' folks didn't put in actual guardrails to prevent it... OP is not entirely at fault.

Re: The costs of microservices (2020)

#136

Post by esafak »

never_inline wrote: post #128
holoduke wrote: post #117

I think that chunking up your application layer into smaller parts is always a good idea. But when do you say its a microservice? When its completely isolated, with its own database etc. Are many small applications running as seperate binaries/processes/on different ports talking to one database endpoint also microservices?

> Are many small applications running as seperate binaries/processes/on different ports talking to one database endpoint also microservices? One database endpoint as in ? You can use different schemas and have no relations between tables used by different services, or on the other extreme have services which write to same table. I have read in a book that the most important criteria is independent deployability. I fo…

https://samnewman.io/books/building_microservices_2nd_editio... ?

Re: The costs of microservices (2020)

#137

Post by salvadormon »

js8 wrote: post #84

I think people get the modularity wrong. Modularity is important, but I came to conclusion there is another important architectural principle, which I call "single vortex principle". First, a vortex in a software system is any loop in a data flow. For example, if we send data somewhere, and then we get them back processed, or are in any way influenced by them, we have a vortex. A mutable variable is an example of a r…

I find this vortex concept interesting. Do you have any books or online sources that I could use to study this?

Re: The costs of microservices (2020)

#138

Post by charcircuit »

abound wrote: post #39

I'm as much of a "build a monolith until you can't" person as any, but one motivation for using microservices that I haven't seen mentioned here is differing resource/infra requirements + usage patterns. Throw the request/response-oriented API with bursty traffic on something serverless, run the big async background tasks on beefy VMs (maybe with GPUs!) and scale those down when you're done. Run the payments infra on…

A load balancer can make this work with a monolith. Requests for expensive services can be routed to a separate tier of servers for example.

Re: The costs of microservices (2020)

#139

Post by j45 »

lr4444lr wrote: post #27

Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it: 1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing 2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment…

There are many ways to architecture well that doesn’t mean prematurely introducing micro services.

I’m a fan of microservices btw.

Premature optimization and scaling is almost as bad of a form of technical debt as others when you have to optimize in a completely different manner and direction.

Re: The costs of microservices (2020)

#140

Post by mjr00 »

rmbyrro wrote: post #122
voxic11 wrote: post #76

Earlier quoted context omitted.

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.

Can't we just isolate these two services in containers, using different library versions? They don't need to be microservices in order to isolate dependencies, do they? In Python, for instance, you don't even need containers. Just different virtual environments running on separate processes.

If you have two separate processes running in two separate containers... those are two separate services. You need to solve the same problems that would come with running them on two different EC2 instances: what's the method for communicating with the other container? What happens if the other container I'm calling is down? If the other container is down or slow to respond to my API calls, am I dealing with backpressure gracefully or will the system start to experiencing a cascade of failures?
Post reply on HN