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

121–130 of 410 posts

Re: The costs of microservices (2020)

#121

Post by manicennui »

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

I just wanted to note that static typing isn't required for autocomplete. JetBrains has IDEs for languages like Ruby and Python that can do it. If you open the REPL in a recent version of Ruby you get much of what you expect from an IDE with a statically typed language (with regards to autocomplete and syntax checking).

Re: The costs of microservices (2020)

#122

Post by rmbyrro »

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.

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.

Re: The costs of microservices (2020)

#123

Post by wnolens »

If a monolith is well-factored, what is the difference between it and co-located microservices?

Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!)

What is the difference between distributed microservices v.s. co-located microservices?

Deployment is more complex, but you get to intelligently assign processes to more optimal hardware. Number of failure modes increases, but you get to be more fault tolerant.

There's no blanket answer here. If you need the benefits, you pay the costs. I think a lot of these microservice v.s. monolith arguments come from poor application of one pattern or the other, or using inadequate tooling to make your life easier, or mostly - if your software system is 10 years old and you haven't been refactoring and re-architecting as you go, it sucks to work on no matter the initial architecture.

Re: The costs of microservices (2020)

#124

Post by sally_glance »

insanitybit wrote: post #81
mjr00 wrote: post #51

Earlier quoted context omitted.

> It doesn't lack a definition, there's lots of people talking about this. In general you'll find something like "a small service that solves one problem within a single bounded context". How small is small? Even within this comment section there are people talking about a single developer being the sole maintainer of multiple microservices. I'm a strong advocate of (micro?)service architecture but I would never reco…

"Small" is a relative term, and not an ideal one, but what it generally means is "no larger than is needed" - that is, if you have one concrete solution within a bounded context, "small" is the code necessary to implement that solution. It's not a matter of LOC. > IMO having everything self-contained to one repository I highly recommend keeping all microservices in a single repository. It's even more important in a m…

A little off topic but there are even more sinister patterns than the shared database which some architects are actively advocating for, like

1. The "data service" layer, which (if done improperly) is basically just a worse SQL implemented on top of HTTP but still centralised. Though now you can claim it's a shared service instead of a DB.

2. The "fat cache" database - especially common in strongly event-based systems. Basically every service decides to store whatever it needs from events to have lower latency access for common data. Sounds great but in practice leads to (undocumented) duplicate data, which theoretically should be synchronised but since those service-local mirror DBs are usually introduced without central coordination it's bound to desync at some point.

Re: The costs of microservices (2020)

#125

Post by sethammons »

Pet_Ant wrote: post #106
sethammons wrote: post #19

Earlier quoted context omitted.

our team of 300 - we _can't_ enforce the clear abstractions. New dev gets hired, team feels pressured to deliver despite leadership saying to prioritize quality, they are not aware of all the access controls, they push a PR, it gets merged. We have an org wide push to get more linting and more checks in place. The damage is done and now we have a multi-quarter effort to re-organize all our code. This _can_ be enforce…

> we _can't_ enforce the clear abstractions Really, you can't? Then I struggle to see how'll get anything else right. I've done it by using separate build scripts. That way only the interfaces and domain objects are exposed in the libraries. Now you lock down at the repository level access to each sub-project to the team working on it. There you go: modularity, boundaries, all without network hops.

sure - if you do that from the start. Most don't. The codebase organically grows and then lines are blurred and then you have to come in and refactor. When this refactor affects several teams, it gets harder in combinatorial fashion.

With an HTTP API boundary, you don't get to reach into my code - it is literally impossible.

Re: The costs of microservices (2020)

#126

Post by sroussey »

rmbyrro wrote: post #120
eduction wrote: post #89

Earlier quoted context omitted.

Wouldn't this just be "having one or two services"? I don't think that's the same as "microservices". Correct me if I'm wrong, but isn't "microservices" when you make internal components into services by default , instead of defaulting to making a library or class?

Exactly my thoughts

Microservices is a newer term than SOA.

Re: The costs of microservices (2020)

#127

Post by [deleted] »

arzke wrote: post #14
nevinera wrote: post #3

The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going…

"The last responsible moment (LRM) is the strategy of delaying a decision until the moment when the cost of not making the decision is greater than the cost of making it." Quoted from: https://www.oreilly.com/library/view/software-architects-han...

[deleted]

Re: The costs of microservices (2020)

#128

Post by never_inline »

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 forget the name of the book.

Re: The costs of microservices (2020)

#129

Post by manicennui »

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

I just wanted to note that static typing isn't required for autocomplete. JetBrains has IDEs for languages like Ruby and Python that can do it. If you open the REPL in a recent version of Ruby you get much of what you expect from an IDE with a statically typed language (with regards to autocomplete and syntax checking).

Also, DRY is not about repeated code. This drives me crazy. Ruby developers love to make code worse by trying to "DRY it up".

Re: The costs of microservices (2020)

#130

Post by vrosas »

jacquesm wrote: post #111
insanitybit wrote: post #99

Earlier quoted context omitted.

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.

If it is dogmatic, then yes: but you have no knowledge of that and besides there are always people who believe there is too much process and there are people that there is too little. If you want to challenge the process you do that by talking about it not by breaking the process on purpose. That's an excellent way to get fired. I don't know the context and I don't know the particular business the OP is talking about…

Heh, both can be true. Process doesn't make good engineers any better. Bad code gets approved and merged every day. I'd rather have a team I could trust to merge and steward their code to production on their own instead of bureaucracy giving people a false sense of security.

> Case in point: the OP is still upset enough that he feels it necessary to vent about this in an online forum.

I apologize for the conversation starter.

Post reply on HN