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

Don't start with microservices – monoliths are your friend

arnoldgalovics.com

Post reply on HN
Print view View original

81–90 of 468 posts

Re: Don't start with microservices – monoliths are your friend

#81

Post by dagss »

In some companies teams are not divided in a way that follow technical faultlines, but rather after "product owners" so that the only valid divison lines are exteral facing superficial aspects.

E.g. think a car company where you are not organized as "engine team" and "transmission team", but rather "sedan team" and "SUV team", and the engine and transmission just need to happen somehow.

The microservices fad and "every team own their own services" fad combined can really get performance to a halt in such a setting.

Product owners are suddenly the unwilling and unwitting chief architects.

At least with a monolith, everything is reasonably standardized and people from different teams can be expected to contribute to larger parts of it..

Re: Don't start with microservices – monoliths are your friend

#82

Post by florinutz »

usrbinbash wrote: post #56

All ideas that are good in principle, become absurd the moment they are elevated to a kind of dogma, applied to every problem, no matter if it makes sense to do so or no. Microservices are no exception from that rule, and often repeat the same mistake as OOP did with its promise of "reusable code". Does it sometimes make sense to break some larger services up in smaller ones? Yes. Does it make sense to "factor out" e…

true, but I hope this clickbait dude committed career suicide with the article

Re: Don't start with microservices – monoliths are your friend

#83

Post by baash05 »

woutr_be wrote: post #66

Doesn’t this highly depend on your use case? For example, right now I’m building a system that will take in a URL, crawls the webpage, and does some processing on the data. The whole process takes a good 10 seconds. I designed this as a micro service, simply because I know URLs will need to be queued up. Should this have been done as a monolith? Or am I right that micro services was actually the right approach?

In rails this would be an activejob (part of the mono), and spinning up workers would be trivial. The "workers" would pull off a redis queue, and you could add different jobs to the queue easy-peasy.

Re: Don't start with microservices – monoliths are your friend

#84

Post by vbezhenar »

sdevonoes wrote: post #40
jhoelzel wrote: post #9

There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either. maybe we are getting caught up in sematics because its christmas, but "monorepo/monolith/microservices/etc" is -just- the way you organize your code. Developing a montolith for years but now you have written a 15 line golang ht…

> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. But the 15 lines of Golang are not just 15 lines of Golang in production. You need: - auth? Who can talk to your service? Perhaps ip whitelisting? - monitoring? How do you know if you service is up and running? If it's down…

Kek.

Auth: nobody knows IP address of our server anyway, don't bother with that. And for extra security we have secret port number.

Monitoring? Well, we have our clients for that. They'll call us if something happens.

Deploy? Copy .war file and restart tomcat. Rollback? What's rollback?

Outdated packages? We call those stable packages.

I wish I would work in a miracle world you describe.

Re: Don't start with microservices – monoliths are your friend

#85

Post by Philip-J-Fry »

mark254 wrote: post #73
Philip-J-Fry wrote: post #67

The only issue I have with microservices is when you're dealing with atomic things. Like in a monolith you'd probably just stick it all in a database transaction. But I can't find any good reads about how to deal with this in a distributed fashion. There's always caveats and ultimately the advice "just try not to do it" but at some point you will probably have an atomic action and you don't want to break your existin…

Well, a simple solution is to only have one middleware that uses database connections, and have all other things around it be purely functional. (Though that may mean using their own databases, of course).

What do you mean by that? What if I have 2 services, each with their own databases, but the action is supposed to be atomic. E.g. there's a foreign key that links the data.

They're both gonna do their own database functions.

Re: Don't start with microservices – monoliths are your friend

#87

Post by barrkel »

Pamar wrote: post #28
jhoelzel wrote: post #9

There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either. maybe we are getting caught up in sematics because its christmas, but "monorepo/monolith/microservices/etc" is -just- the way you organize your code. Developing a montolith for years but now you have written a 15 line golang ht…

Maybe it is just me, but I always understood that properly designed microservices have their own specific datastore , which is not shared with other microservices even if these all collaborate to the same process. If this is actually (still) true, that means that "the way you organize your code" is a bit simplistic. Your example of an "http api that converts pdfs to ..." is surely a valid example of a microservice, b…

Single writer multiple readers, ideally with permissions to enforce, is a useful hybrid. Enforce going through the front door if you want side-effects. Reporting and ad-hoc data enrichment can be painful to materialize otherwise.

When you have multiple bits of code responsible for writing the same columns, maintaining global invariants becomes much harder.

I can still see rationale for exceptions to the rule, e.g. status fields for rows which logically represent some ongoing process or job, where a UI controller may set something to "processing" and the background job sets it to "processed" when it's complete. But there are ways to close the loop here. For example, implement the background job by having the job processing system invoke the same system which owns the field and sets it in response to the UI, like this:

    UI start  ---> Back End ---> status := processing
                   Back End ---> add job to job queue

    Job Queue ---> Back End does work
                   Back End ---> status := processed

Re: Don't start with microservices – monoliths are your friend

#88

Post by dagss »

Philip-J-Fry wrote: post #67

The only issue I have with microservices is when you're dealing with atomic things. Like in a monolith you'd probably just stick it all in a database transaction. But I can't find any good reads about how to deal with this in a distributed fashion. There's always caveats and ultimately the advice "just try not to do it" but at some point you will probably have an atomic action and you don't want to break your existin…

The need to do a cross-service atomic operation indicates that you chose the wrong service boundaries in your architecture.

And, since it's microservices, it's near impossible to refactor it, while it could have been a simple thing to reorganize some code in a monolith (where it is also a good idea to make sure that DB transactions don't span wildly different parts of the source code, but the refactor to make that happen is easier).

This is the big downside of microservices -- not the difficulty of doing atomic operations, but the difficulty of changing the architecture once you realize you drew the wrong service boundaries.

Microservices is great as long as you choose the perfect service boundaries when you start. To me, that's like saying you always write bug-free code the first time -- it's not doable in practice for large complex projects -- hence I'm not a fan of microservices...

Re: Don't start with microservices – monoliths are your friend

#89

Post by netcan »

usrbinbash wrote: post #56

All ideas that are good in principle, become absurd the moment they are elevated to a kind of dogma, applied to every problem, no matter if it makes sense to do so or no. Microservices are no exception from that rule, and often repeat the same mistake as OOP did with its promise of "reusable code". Does it sometimes make sense to break some larger services up in smaller ones? Yes. Does it make sense to "factor out" e…

I agree, but I think this kind of "ad absurdum" endpoint is principally an organisational problem.

Companies are hard. They have histories. Different people with opposing ideas. Dissonance between how the company operates and how it operates on paper. Conflicting personal interests, politics. Stories they tell...

They need some sort of rough-cut ideology, system or whatnot. A way of adjudicating right or wrong. That way arguments can be settled. People can be onboarded more easily. The company's decisions become more legible.

A simple requirement to report on important decisions, the choices available and reasoning behind the choice... stuff like this has consequences. An ethos is more flexible than a ruleset, and provides a way of navigating organisational issues.

People working on their own or in small autonomous groups don't tend to go overboard as easily.

Re: Don't start with microservices – monoliths are your friend

#90

Post by xyzzy123 »

Philip-J-Fry wrote: post #67

The only issue I have with microservices is when you're dealing with atomic things. Like in a monolith you'd probably just stick it all in a database transaction. But I can't find any good reads about how to deal with this in a distributed fashion. There's always caveats and ultimately the advice "just try not to do it" but at some point you will probably have an atomic action and you don't want to break your existin…

Most people give up and do orchestration instead at some point.

Fortunately there are not that many things in the world that need to be 100% atomic so you can get away with a lot.

For your own microservices you generally have at least the option of "fixing" the problem properly even if it's at great expense.

But then you hit external systems and the problem resurfaces.

You can go crazy thinking about this stuff, at a certain point most business logic starts to look like connectors keeping different weird databases in sync, often poorly.

Pure crud api? Oh that's a database where client is responsible for orchestration (create folder, upload document...) and some operations might be atomic but there are no transactions for you. Also, the atomicity of any particular operation is not actually guaranteed so it could change next week.

Sending an email or an SMS? You're committing to a far away "database" but actually you never know if the commit was successful or not.

Payments are a weird one. You can do this perfectly good distributed transaction and then it fails months after it succeeded!

Travel booking? runs away screaming so many databases.

etc.

Post reply on HN