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

101–110 of 468 posts

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

#101

Post by zaptheimpaler »

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…

lol this is how it works at a startup -

1. auth? probably an internal service, so don't expose it to the outside network.

2. monitoring? if the service is being used anywhere at all, the client will throw some sort of exception if its unreachable.

memory problem? it should take 3. deployment? if its a go service, literally a bash script to scp over the binary and an upstart daemon to monitor/restart the binary.

rollback? ok, checkout previous version on git, recompile, redeploy. maybe the whole process is wrapped in a bash script or assisted by a CI/CD build job.

4. security? well ok, PDFs can be vulnerable to parser attacks. so lock down the permissions and network rules on the service.

Overall this setup would work perfectly fine in a small/medium company and take 5-10x less time than doing everything the FAANG way. i don't think we should jump to calling these best practices without understanding the context in which the service lives.

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

#102

Post by qxmat »

Aldipower wrote: post #48

I am just using services with my medium sized application. They are not "micro", but they separate the domains and different concerns pretty well. I have the deployment setup more or less like a monolith, but still having separation of concerns with my services. And stateless service runners.. Fair enough I have the state in a single (mirrored) database. But this works perfectly fine for the medium sized app. Not sur…

I've felt SOA is the easiest to grow because it encourages you to swap out concrete implementations as requirements change. For example, IUserService can start off with a "local" UserService implementation that makes direct calls to a database. Once you signup with an IdP this might become UserServiceAzureAD/Okta/Auth0. Unlike microservices, I keep my compile-time guarantees that IUser continues to have the properties I require without any tooling.

Given the rhetoric here I worry that I'm the only person who's genuinely swapped out their implementation. The ol' "N-tier is stupid - you're never going to change the database" comment couldn't be more wrong.

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

#103

Post by rich_sasha »

jhoelzel wrote: post #65
sdevonoes wrote: post #40

Earlier quoted context omitted.

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

no why? The task of the Microservice is to convert the pdf to stardust and to return it to its sender. so no auth. Furthermore its most likely only reachable through the local network, or at least should be if you want some stranger not to be able to also make stardust from pdfs. Monitoring: are you trying to say that its a lot esaier to pick up one logfile thant lets say 15? because they should be aggregated somewhe…

A microservice runs as some (somewhat) privileged user, you may want some auth. Can everyone internally create sales tickets? Or can everyone just query them? If a team provides a library to run, and you run it, you still only run as whatever user you have access to.

Monitoring: it's easier to look at a stack trace, including some other team's external library, than a HTTP error code 500.

Deployment is certainly easier when you're just shipping code and a build. You don't have to faff around with the previous instance running, maybe having some active connections/transactions/whatever, needing to launch a new one. Maybe it's not hard overall, but less fun.

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

#104

Post by KronisLV »

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 of horizontally scaled instances with a few particular feature flags enabled (e.g. multiple web API instances) and maybe some others as vertically scaled monoliths (e.g. scheduled report instance).

I wrote more about that approach on my blog, as one of the first articles, "Moduliths: because we need to scale, but we also cannot afford microservices": https://blog.kronis.dev/articles/modulith-because-we-need-to...

In my eyes, the good part is that you can work with one codebase and do refactoring easily across all of it, have better scalability than just a monolith without all of the ops complexity from the outset, while also not having to worry as much about shared code, or perhaps approach the issue gently, by being able to extract code packages at first.

The only serious negatives is that this approach is still more limited than microservices, for example, compilation times in static languages would suffer and depending on how big your project is, there will just be a bit of overhead everywhere, and not every framework supports that approach easily.

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

#105

Post by LaGrange »

paul_f wrote: post #97
vbezhenar wrote: post #84

Earlier quoted context omitted.

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.

I cannot tell if this is satire or not. Entering Poe's Law territory

The answer is "both." This is very funny, very dumb, and how it's done, at the same time.

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

#106

Post by marginalia_nu »

Joeri wrote: post #98
marginalia_nu wrote: post #68

Earlier quoted context omitted.

I've seen organizations that have hundreds of developers organized in 5-10 man teams, each managing their microservice. I think it tends to happen when a large organization decides to get down with the kids and start to do microservices. Conway's law enters into it in a lot of ways. Because of the way the people are organized into tiny isolated teams, the code shares that shape too. There is an event horizon one team…

Going for microservices without a central director role is indeed madness and leads to inefficiency. My employer has a landscape like that, hundreds of microservices each managed by a different team (some teams manage multiple). However, we have an enterprise architecture group whose job it is to keep an overview and make sure every microservice is meaningful and fulfills a clear role for the organization. Every proj…

> However, I still wouldn’t recommend microservices to a new team / org starting from scratch. IMHO microservices only make sense when the system grows so vast it cannot be understood in its entirety by a single person.

I wouldn't go that far. The problem is prescribing a stock design solution to every problem without even considering the problem domain or what benefits it will bring.

There are domains where this style of programming is an absolute benefit, even at smaller scales, and it's really nothing new either. A lot of the patterns in microservice design rhyme rather well with what Erlang has done for decades.

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

#107

Post by solididiot »

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…

DevOps is a sad story both for devs and for ops. It was supposed to treat operations as a SW problem thus take away the toll and draw devs in. In reality for most places it either means that devs also do pipelines and operations or that operations were rebranded and are using "DevOps" tooling to do operations.

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

#108

Post by gwbas1c »

bspammer wrote: post #93
deniska wrote: post #26

Unless you have a strong technical or organizational reason to use microservices, using microservices is just more work to achieve the same results. Organizational reason would be multiple people/teams who don't want or can't talk much to each other, so they develop pieces of a larger system as relatively independent projects, with clear API and responsibility boundaries. Frontend/backend style web development is an…

> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “d…

That's a fallicy. You've optimized for one use case, but you've made everything else more complicated as a consequence.

Deploying a single monolith is faster than deploying 10 microservices, especially if you find yourself in the model where your microservices share code, you've ended up with a distributed monolith instead of microservices.

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

#109

Post by usrbinbash »

marginalia_nu wrote: post #68
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've seen organizations that have hundreds of developers organized in 5-10 man teams, each managing their microservice. I think it tends to happen when a large organization decides to get down with the kids and start to do microservices. Conway's law enters into it in a lot of ways. Because of the way the people are organized into tiny isolated teams, the code shares that shape too. There is an event horizon one team…

> It's a lot of code, but it's not a lot of logic.

The exact reason why I compare microservices to OOP ;-)

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

#110

Post by jhoelzel »

barrkel wrote: post #87
Pamar wrote: post #28

Earlier quoted context omitted.

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. st…

Thank you for this as this is exactly how its implemented in a recent project of mine.

I didn't want to put unneeded information in the first post but here i have some space ;)

What I ended up doing was:

  - two sqs queues, one for processing one for failures after 3 tries

  - the go backend reads from its queue and the message contains a json object with all the information needed for pdf generation

  - the backend posts the file back to the "internal api" of the application, which saves it in s3 and also sets processing to true which means the user can go and download it.
This results in:

  - my pdf generated the way i want it (sorry i dont actually make stardust)

  - the queues are only reachable through the assosiated iam roles

  - if a job failes it will be added to the failed queue, which sends me an email

  - if i recieve an email by the failed queue, 90% of the time i have found another edge case 

  - since the message already contains everything that i need to build the pdf, my edge case has just defined itself

  - for the postback i supply an api token that is only valid for that one file
All this means my client has total flexibility in deployment.
Post reply on HN