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

Starting with microservices

arnoldgalovics.com

Post reply on HN
Print view View original

91–100 of 139 posts

Re: Starting with microservices

#91

Post by truffdog »

mcv wrote: post #35
scanr wrote: post #10

I have a theory that auto-wired Dependency Injection in a single DI container is partly to blame for monolith spaghetti. Once an app reaches a certain size and anything can depend on anything else, reasoning about the whole can become difficult. I think there is value in wiring a monolith together in such a way that each course grained subcomponent exposes a constrained interface into the rest of the system (payments…

I notice there's a lot of comments here saying this exact same thing, and it's also what seems most sensible to me. Yet microservices are getting all the hype. Should be hype a thorough modular design more?

The nice thing about microservices is that you don't need iron discipline to maintain modular boundaries, instead its just how things work.

I like to analogize it to assembly vs structured programming languages, or C vs Java- you can write the same programs in either, you can write bugs in either, but there are whole classes of pitfalls that get erased by moving from one language to another.

Re: Starting with microservices

#93

Post by jdlshore »

rzzzt wrote: post #72
scanr wrote: post #10

I have a theory that auto-wired Dependency Injection in a single DI container is partly to blame for monolith spaghetti. Once an app reaches a certain size and anything can depend on anything else, reasoning about the whole can become difficult. I think there is value in wiring a monolith together in such a way that each course grained subcomponent exposes a constrained interface into the rest of the system (payments…

There was another article about building this structure into a single, self-contained executable and decide via command line arguments which piece(s) to use at startup. For some reason I remember "microlith", but it must be another clever word combination because I can not find any relevant HN posts, just one about archaeology... You can run a single copy of the resulting binary (eg. for testing) that spins up all su…

I’ve coined the term “microlith,” but I’m probably not the only one and it may not be what you’re thinking of. I wrote about it in the new edition of my book, and also discussed it here: https://www.jamesshore.com/v2/projects/lunch-and-learn/micro...

Re: Starting with microservices

#94

Post by BatteryMountain »

scanr wrote: post #10

I have a theory that auto-wired Dependency Injection in a single DI container is partly to blame for monolith spaghetti. Once an app reaches a certain size and anything can depend on anything else, reasoning about the whole can become difficult. I think there is value in wiring a monolith together in such a way that each course grained subcomponent exposes a constrained interface into the rest of the system (payments…

At that point it becomes useful to look at some indirection/decoupling patterns like the Mediator pattern.

Then instead of having a IService with 15 methods with a construction with 20 dependencies listed (multiply it with say 50 IServices in your project - mmmm spagheti project), you end up with a IHandler with a single method and a constructor that only has say 3 injected dependencies, only what it needs. The trade off is, you now have 100's of small Handler files, some people don't like that BUT you now have a pleasant git commit history per file and most of the code of a Handler file fits on one screen and it is easy to digest. You can also let a handler trigger other handlers if it needs to (via the same mediator). It also fits with SRP.

Auto-wiring 95% of your dependencies still stays intact as the above plumbing will need it to work.

Re: Starting with microservices

#95

Post by loziuu »

You know what's underrated and underused? Encapsulation and common sense. You can't just do microservices for sake of microservices, but if you see that one of domains in your monolith is growing faster than others it MIGHT be good idea to split it to microservices. Every decision has to be reasoned by something. If you "don't know" or you haven't done basic designing like event storming, then you should start with monolith because it's easier to take step back.

Choosing architecture has to be conscious not based on trends or beliefs. Even small app can be easy to mantain and develop in miroservices manner if you know WHY you decided to split it up. Don't do (or don't stop doing this) because you read some comments on hacker news or reddit :)

Re: Starting with microservices

#96

Post by jamesfinlayson »

doctor_eval wrote: post #67

I’m going to be the contrarian in this discussion. I think microservices are awesome and I’ve deployed architectures in anger in both Java and Go. 100% would (and will) do it again. Most of the problems people are talking about seem to be around using microservices inappropriately, without sufficient preparation, or when an application is not complex enough to benefit from it. Microservices are not a panacea any more…

I'm guessing more than a few here have seen and been burned by colleagues jumping on the microservice bandwagon: plenty of developers think microservices = good regardless of how the system is architected.

Re: Starting with microservices

#97

Post by dm3 »

jamesfinlayson wrote: post #86
crdrost wrote: post #70

Earlier quoted context omitted.

Yeah, the biggest problem that people get into with microservices is that they allow the communication structure to dictate the app structure. A monolith gives you some refactorability because you can run what would have been "integration" tests locally, as you massage your module boundaries to match the problem that you're solving. So a monolith can become a clean monolith, and then a clean monolith can maybe become…

A company I worked at went all in on option c - there was a random number service (that just wrapped a random number generation library), and sending an email was split across multiple services - one to pull the email request from the database, one to generate the email from the template, one to actually send the email and one to save the templated email to the database.

How did it work out? Very curious, as such granularity of deployable units seems absurd unless it's deployed into a single runtime...

Re: Starting with microservices

#98

Post by yakshaving_jgt »

jamesfinlayson wrote: post #86
crdrost wrote: post #70

Earlier quoted context omitted.

Yeah, the biggest problem that people get into with microservices is that they allow the communication structure to dictate the app structure. A monolith gives you some refactorability because you can run what would have been "integration" tests locally, as you massage your module boundaries to match the problem that you're solving. So a monolith can become a clean monolith, and then a clean monolith can maybe become…

A company I worked at went all in on option c - there was a random number service (that just wrapped a random number generation library), and sending an email was split across multiple services - one to pull the email request from the database, one to generate the email from the template, one to actually send the email and one to save the templated email to the database.

I’m imagining that whomever is running that company prefers to heat his home by throwing cash directly into his fireplace instead of burning wood.

Re: Starting with microservices

#99

Post by yakshaving_jgt »

truffdog wrote: post #91
mcv wrote: post #35

Earlier quoted context omitted.

I notice there's a lot of comments here saying this exact same thing, and it's also what seems most sensible to me. Yet microservices are getting all the hype. Should be hype a thorough modular design more?

The nice thing about microservices is that you don't need iron discipline to maintain modular boundaries, instead its just how things work. I like to analogize it to assembly vs structured programming languages, or C vs Java- you can write the same programs in either, you can write bugs in either, but there are whole classes of pitfalls that get erased by moving from one language to another.

That’s not true. People in industry commonly refer to the consequence of their misguided decision to embark on a microservices adventure as a “distributed monolith”.

Re: Starting with microservices

#100

Post by withinboredom »

blakehaswell wrote: post #77
withinboredom wrote: post #20

Earlier quoted context omitted.

Currently at my day job, we have a monolithic code base with multiple entry points. If you update a library, you have to update the client or keep the changes backwards compatible. I really prefer this over multiple micro services.

What exactly do you mean by multiple entry points? Do you have multiple processes which run independently but are co-located in the same repository or are you talking about something else?

You can have more than one Main function, just pick which one to use when you compile. In our case it’s PHP, so the API entry point uses a different index than jobs, for example. They can be deployed differently and scaled differently, but operationally it’s just deploying the same code/configuration everywhere and the only difference is routing. When you are writing code, you very, very rarely have to worry about which context you are writing for.
Post reply on HN