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

121–130 of 468 posts

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

#121

Post by Philip-J-Fry »

dagss wrote: post #88
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 ha…

Yes, this sort of explains my situation. A requirement appears down the line that just completely breaks the service boundaries.

An example being something like an online gun store, you have a perfect service that handles orders. It's completely isolated and works fine. But now, 2 years later some local government has asked you "whenever someone buys a gun, you need to call into our webservice the moment the order is placed so we know a gun was sold, and you need to successfully do it, or you can't sell the item"

Now you've got a situation where you need an atomic operation, place the order and call the web service, or don't do it at all. You could say just place the order, do the web service call asynchronously and then delete the order afterwards. But you might not have that choice depending on what the regulations say. You can't do it before you place the order because what if payment fails?

The order service should not have any idea about blocking orders in specific scenarios. And now the architecture has broken down. Do you add this to the order service and break it's single responsibility? Will this be a bigger problem in the future and do you need to completely rearchitect your solution?

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

#122

Post by bayesian_horse »

kulikalov wrote: post #2

Nice article! Although I think you are overdramatizing microservices complexity a little. - Kubernetes is rather a harder way to build microservices. - DB is not an obligatory part of microservices. - Kafka isn't as well. It's a specific solution for specific cases when you need part of your system to be based on an events stream. - Jenkins is not necessary, you can still deploy stuff with a local bash script and you…

I think even with a monolith, especially a distributed one you can need logging, CI and a DB.

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

#125

Post by niros_valtos »

It depends on the age of the company and the size of the products. A typical startup company can kick the tires with a monolithic architecture just to deliver a prototype quickly, but a more stable company that builds a products to scale will need to separate some of the services. They may have a big monolith chunk with a bunch of other “new” micro services.

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

#126

Post by andy_ppp »

KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

This is one of the things I love about Elixir and OTP+The Beam that underpin it all. It's really great that you can just slowly (as is sensible) move your system over to message passing across many VMs (and machines) before you need to move to a more bespoke service oriented architecture.

With Umbrella apps this can already be setup from the start and you can break off bits of your app into new distinct message-able components (micro services you could say) as you like while still being able to share code/modules as needed.

The other thing I'd say is you can introspect how these "services" are running in realtime with IEX and it feels like magic being able to run functions in your application like some sort of realtime interactive debugger. One of the biggest issues I had with micro-services is figuring out what the hell is going wrong with them (in dev or prod) without the layers of extra work you need to add in terms of granular logging, service mesh and introspection etc.

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

#127

Post by Lhiw »

marginalia_nu wrote: post #20
kulikalov wrote: post #2

Nice article! Although I think you are overdramatizing microservices complexity a little. - Kubernetes is rather a harder way to build microservices. - DB is not an obligatory part of microservices. - Kafka isn't as well. It's a specific solution for specific cases when you need part of your system to be based on an events stream. - Jenkins is not necessary, you can still deploy stuff with a local bash script and you…

I originally had my search engine running on a kubernetes-style setup off mk8s. The code is a microservice-esque architecture. Some of the services are a bit chonky, but overall it's roughly along those lines, besides the search engine I've got a lot of random small services doing a lot of things for personal use, scraping weather forecasts and aggregating podcasts and running a reddit frontend I built. I'd gone for…

This is why PHP wound up dominating the world. You get all the benefits of a monolith, and if designed well, you get a highly modular system that can be deployed without restarting every single server.

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

#128

Post by dagss »

Philip-J-Fry wrote: post #121
dagss wrote: post #88

Earlier quoted context omitted.

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 ha…

Yes, this sort of explains my situation. A requirement appears down the line that just completely breaks the service boundaries. An example being something like an online gun store, you have a perfect service that handles orders. It's completely isolated and works fine. But now, 2 years later some local government has asked you "whenever someone buys a gun, you need to call into our webservice the moment the order is…

I would say this is another problem. If an external call to a web service is involved, then you can NEVER have an atomic call in the first place. One always needs to just have a state machine to navigate these cases.

Even with a monolith, what if you have a power-off at the wrong moment?

What you are describing here is to me pretty much the job description of a backend programmer to me -- think through and prepare for what happens if power disappears between code line N and code line N+1 in all situations.

In your specific example one would probably use a reserve/capture flow with the payment services provider; first get a reservation for the amount, then do the external webservice call, then finally to a capture call.

In our code we pretty much always write "I am about to call external webservice" to our database in one DB transaction (as an event), then call the external webservice, and finally if we get a response, write "I am done calling external webservice" as an event. And then there's a background worker that sits and monitors for cases of "about-to-call events without matching completed-events within 5 minutes", and does according required actions to clean up.

If a monolith "solves" this problem then I would say the monolith is buggy. A monolith should also be able to always have a sudden power-off without misbehaving.

A power-off between line N and N+1 in a monolith is pretty much the same as a call between two microservices failing at the wrong moment. Not a qualitative difference only a quantitive one (in that power-off MAY be more rare than network errors).

Where the difference is is in the things that an ACID database allows you to commit atomically (changes to your internal data either all happening or none happening).

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

#129

Post by KronisLV »

daitangio wrote: post #120
KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

Thank you for sharing, and I agree with you- In my humble opinion microservices are "hot" because in theory you can scale a lot with them if you are able to do cloud provisioning. Microservices needs DevOps+Orchestration Service. A good example of microservices architecture is how K8s is designed: I think it is an overkill for most average needs, so think twice before entering in microservice trip tunnel.

Well in my eyes equating microservices with Kubernetes is a problem in of itself. I actually wrote about Docker Swarm as a simpler and more usable alternative to it (for smaller/simpler deployments), though some other folks also enjoy Hashicorp Nomad which is also nice (another article on my blog, won't link here not to be spammy myself).

If you evaluate your circumstances and find that microservices could be good for you, then there are certainly options to do them more easily. In my eyes some of the ideas that have popped up, like 12 Factor Apps https://12factor.net/ can be immensely useful for both microservices and even monoliths.

So i guess it's all very situational and a lot of the effort is finding out what's suitable for your particular circumstances. For example, i made the page over at https://apturicovid.lv/#en When the app was released and the page was getting hundreds of thousands of views due to all of the news coverage, scaling out to something like 8 instances was a really simple and adequate fix to not break under the load.

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

#130

Post by austincheney »

These arguments are always full of assumptions, and typically revolve around some web middleware application connecting to a DB.

This noise makes me hopeful that a decentralized model will come along to replace these generic boilerplate concerns with real problems to solve.

Post reply on HN