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

71–80 of 468 posts

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

#71

Post by yakshaving_jgt »

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…

> "monorepo/monolith/microservices/etc" is -just- the way you organize your code

I don't think this is true.

I think — at least as far as I've observed — microservices in practice means replacing various functions calls with slow and error-prone network requests.

This is a big and meaningful difference.

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

#72

Post by dagss »

adflux wrote: post #10

Microservices aren't implemented to solve technical problems, rather they are used to solve organizational problems. Having 10 developers working on a single monolith? Probably fine. 100? Good luck managing that. Yes they add technical complexity. But they reduce organizational complexity.

Except when the team division in the company does not map to any natural service API boundaries, yet it is insisted that each "team" own their services.

Then microservices increase organizational complexity too.

Suddenly product owners and middle management are chief architects without even knowing it.

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

#73

Post by mark254 »

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).

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

#74

Post by p2t2p »

Last five years I'm looking at how my colleagues are struggling to dismantle a king of monoliths to services to enable various teams to move at faster pace and scale different parts independently.

Those people couldn't be more wrong. Monoliths are not your friend. Deployment times will be longer, requirements for hosts where you deploy it will be bigger, you will end up with _huge_ instances to rent because some parts of you monolith want more RAM and some want more compute. You'll have to scale more than you really need to because some parts of your monolith are more scalable than another, etc, etc, etc.

You'll be unable to use different technologies to optimise that one particular use case, because it has to be deployed together with everything else and you totally don't have any infrastructure to call into another service. You'll be stuck with "one size fits all" technological choices for every component in your system.

Monolith is good basically only on PoC stage. Once you have business running, you need to dismantle it ASAP.

edit: grammar, spelling, formatting.

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

#75

Post by laputan_machine »

deepstack wrote: post #18
laputan_machine wrote: post #11

Earlier quoted context omitted.

DB isn't needed. Our microservices pipeline either uses MQ, EFS or S3 for the destination for another pipeline to pick up. Unless you count those 3 as DBs ;)

Yeah I would say those are key value document based DB. Just silicon valley hipster coming up with cool names to call something different so it is a bit easier for developer to use. Anything does permeant storage are DB.

You could argue S3 is a key-value store, however ActiveMQ is a message queue, and EFS is essentially NFS.

I certainly don't agree that 'anything that does permanent storage is a DB'. Not many people would call their hard drive a 'database'

I personally think that they all have a place and are very useful tools for certain situations, depending on the problem.

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

#76

Post by GrumpyNl »

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…

You need at least two teams for that.

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

#77

Post by baash05 »

verinus wrote: post #29
kkjjkgjjgg wrote: post #22

Maybe I'm too old, but I don't even want to have to worry about all that. I think in terms of functions and I don't care if they are being called remotely or local. That was the promise back in the day of J2EE, and it seems to me Microservices are just a rehash of that same promise. Which never really worked out with J2EE - it was mostly invented to sell big servers and expensive consultants, which is how Sun made mo…

I wholeheartedly agree on most parts, with DevOps being the exception. Devs only focusing on developing/writing source code is certainly not the way to produce sustainable, high quality software- at least in my opinion...

I am 100% not interested in ops. Deploying is handled by other way more qualified than I. I never expect a JS expert to build elixir, I don't expect an elixir expert to write bash, and I don't expect a bash expert to know about switches and cabling. I don't understand where you draw the line.. Should the designer who also crafts the css do ops too?

I think high quality comes from specialists. Sharp knives in the hands of pro's

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

#78

Post by Quekid5 »

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…

IME the only sane way to do this is to

a) redraw the transaction boundaries, aka. avoid it, or

b) don't do it (see below),

c) idempotency -- so you can just retry everything until you succeed.

You can do distributed transactions, but it's a huge pain operationally.

(b) is not always as far fetched as you might think. The vast majority of Real World (e.g. inventory, order fulfilment generally, etc.) systems are actually much more like Eventual Consistency in practice, so you don't gain anything by being transactional when your Source of Truth is a real world thing. Inventory is a great example. It doesn't matter if your DB says that an item is in stock if there simply isn't an item on the shelf when it comes time to fulfill an order for that item. Tracking such things is always imperfect and there already other systems overlaid which can handle the failure case, e.g. refund the order, place on backorder, have a CSR find a replacement item, etc. etc. (Of course you want reasonable approximate values for analytics, logistics, etc.)

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

#79

Post by mytailorisrich »

markmaglana wrote: post #59
mytailorisrich wrote: post #34

Earlier quoted context omitted.

Except that you do not need microservices to solve organisational problems. You need, as has always been done, to have well-defined modules with well-defined interfaces.

If there’s no organizational barrier (e.g. microservices architecture, separate repos with strict permissions) that will prevent devs from leaking abstractions across technical boundaries, those well-defined modules and interfaces will devolve into a big ball of mud. I say this with the assumption that the team is large and members regularly come and go.

Lack of discipline and incompetence will always lead to bad results one way or another...

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

#80

Post by jhoelzel »

GrumpyNl wrote: post #76
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…

You need at least two teams for that.

optimally yes.

The application dev does not need acces to production whatever and the devops person does not need to know how the application works.

But then again these to people also need to communicate ;)

Post reply on HN