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

111–120 of 468 posts

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

#111

Post by Ma8ee »

vbezhenar wrote: post #84
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…

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 really can’t tell how serious you are. I’m too aware that what you describe often is exactly how it works in practice. It’s just that very few admit it in public. :)

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

#112

Post by Pamar »

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…

Caveat: I am really not qualified to discuss the nuances (because I have never used microservices so the little I know is based on reading a bit on those here and on other online forums).

"Single writer multiple readers", yes, this is what I would probably use, but yet again, wasn't the "promise" of Microservices being able to work in total isolation?

If I have one table (e.g. "Customer") which is written by one specific microservice and read by a dozen or more... what happens when I decide that I have to change the schema because the current representation of "Zip Code" is not adequate anymore because, I dunno, we started dealing with UK customers now?

Lo and behold, I have to change code in 13 Microservices - the one actually writing to it, and the 12 more that only need to get the data to show or print or convert to JSON or whatever... ¯\_(ツ)_/¯

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

#113

Post by 3np »

baash05 wrote: post #77
verinus wrote: post #29

Earlier quoted context omitted.

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

Just like the preceding question, it depends on context.

In a huge organisation, it can work well to be very specialized.

In, for example, a smaller growing business with an engineering team of < 10, having a proper understanding of the context in which your code will run is a game-changer.

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

#114

Post by bayesian_horse »

I agree.

The only addition: Often it is useful to design with microservices because it means you don't have to create and maintain them yourself. Even a database is a microservice. PhPMyAdmin (and similar) is a microservice, so are other Open Source projects I like: Celery, Sentry, Mailhog, Jupyter, Nextcloud even Caddy or Nginx. All could be considered microservices. Integrating them into your platform often makes a lot of sense.

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

#115

Post by 3pt14159 »

zaptheimpaler wrote: post #101
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…

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

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

Haha. You're a bit of an optimist, eh?

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

#117

Post by Pamar »

pibi wrote: post #38
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…

Well, it's all about the data responsibility: who is the owner of the data, how others can access the data. Once you have defined these, you see that you can "share the access" with other microservices (for example read only mode on a view), as long as the ownership and the access rules are preserved.

Yes, a view would be exactly how I would address the problem I described in my other answer above ("What happens if I need to change zip code representation in a data source that is read by multiple microservices?").

But this also means that we are now back into "YesSQL" territory, and specifically that we have to use a RDBMS which allows us to create Views. Goodbye NoSQL, goodbye Key+Valus datastore. (Or maybe you will just create an extra "newZipCode" and mantain it in parallel with "ZipCode" allowing every other consumer to adapt at their leisure...?).

So it is another step back to "more traditional ways" to design a system... or a recipe for a disaster as soon as you start dealing with significant quantities of "state".

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

#118

Post by bayesian_horse »

gmueckl wrote: post #52
armanm wrote: post #31

Monolith and Micro-services at different times during the progression of a business can have their places. I have experienced the pains of having to work with both within the same company over 9+ years and here is what I think are forces that can pull you in either direction. A monolith makes developing initially a lot easier. Over 15 years though, you are bound to have developers of various calibre leave their mark…

In some languages, you can enforce boundaries within a monolith nicely using the build system. The key is to break the build up into a hierarchically structured set of libraries somehow where each library only gets to use those libraries it is allowed to depend on architecturally. Independent bits of business logic would need to go into libraries that cannot "see" each other when they are compiled. Everything would s…

I think you didn't quite get the point of engineers of different levels of quality, talent and opinions working on the same monoliths.

Eventually they tear down any boundary, even those in the build system.

Developer discipline is something that eludes many companies for lack of enough high quality engineers and awareness for the problem in upper management. It's easier to quibble over formatting guidelines.

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

#119

Post by galangalalgol »

gwbas1c wrote: post #108
bspammer wrote: post #93

Earlier quoted context omitted.

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

Don't forget serdes costs for microservices. They kill runtime speeds even with nice toys like flatbuffers.

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

#120

Post by daitangio »

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.

Post reply on HN