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

411–420 of 468 posts

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

#411

Post by alkonaut »

cerved wrote: post #407
alkonaut wrote: post #359

Earlier quoted context omitted.

I know. Which is why I have architectural tests that scream if someone uses the wrong module from the wrong place (adds a dependency that isn't what we want). Of course, any dev could just remove the test, and by that tear down that boundary too. But that test being removed is much more obvious to the code reviewer who would not have noticed the dependency being snuck in. The architectural tests can also contain comm…

interesting, how do you implement such a test?

In .NET I do it om the binaries, I reflect over the assemblies and list the dependencies.

In the same run one can also validate that there are no incompatible transitive dependencies.

Within assemblies (between namespaces) is much harder unfortunately. That means assemblies have to be made to make module boundaries obvious, even though it’s a bit of an antipattern. There are tools such as nsdepcop that watch namespace dependencies, but it’s brittle and a lot of work.

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

#413

Post by smaudet »

eropple wrote: post #249
farias0 wrote: post #196

Earlier quoted context omitted.

In my experience with enterprise software one of the things that cause most trouble is premature modularization (sibling to the famous premature optimization). Just like I can't understand how people can come up with the right tests before the code in TDD, I can't understand how people can come up with the right microservices before they start developing the solution.

Perhaps a better way to think of "writing the tests first" in TDD approaches (or, more generally, test-first development , which is a term that has gone out of favor) is that you write test cases in that testing framework to express your intent and then from there can start to exercise them to ensure correctness. It's not a crime to change them later if you realize you have to tweak a return type. But writing them up…

The issue with most TDD or even BDD I have seen is that it is usually worthless...

You end up testing that numbers came out of a function or that some thing was called, but it doesn't actually solve the real issue which is to get your use cases correct. Instead it encourages you to break down the problem into a bunch of unrelated bits, it doesn't actually check that your approach is correct or what the customer wants, just that you wrote some bits of code which do things, whether those things are the right things...

As it is often practiced it is usually a failsafe for people who struggle to write code at all.

Acceptance tests are too happy pathy, integration tests are rarely done or deemed 'unnecessary', so the only place left to 'think about the problem' becomes actually writing/designing the code. And so tests tend to come last, because you already decided what works, and they check nonsense.

For truly difficult code, such as a mathematical algorithm which is difficult to break down, unit tests make sense, the majority of "when X is true do A, when X is false do B" of unit tests are utter garbage.

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

#414

Post by wruza »

drbojingle wrote: post #321

Guy who hates micro services here (worked at a startup that tried to adopt them because the CTO's consulting friend who works in enterprise convinced him of how great it was). From what I can tell, micro services are primarily a solution to an organizational problem and not a technical one and I think people trip over this. If you have 600 developers working on the same back-end then you can benefit from micro servic…

I’ve heard before that microservices deployment scheme solves one particular task: if you get traction, you’ll be ready for scaling. If you can’t do that you are already dead, cause being unable to get 10x more users with a click (when they come) means your competition will do that instead. Is that still true?

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

#415

Post by Pamar »

rvense wrote: post #245
Pamar wrote: post #112

Earlier quoted context omitted.

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

Microservices mean that different parts of your code are now communicating via (e.g.) HTTP instead of function calls. It changes the situation regarding deployment, but it does not miraculously absolve you from changing code when data formats change. How could it?

I know, thanks.

My point is precisely that: if you have to handle large quantity of state (e.g.: travel agency handling diverse item bookings to sell as a complete holiday packages - note that this includes having conflicts on inventory, like "cruise cabin categories" or "hotel rooms") microservices add latency by "replacing function calls with RPC", and gain you... an unspecified advantage in terms of... deployment? The possibility to have hundreds of developers working on the system in parallel?

I have always worked on medium-size monoliths during most of my career, and "ah, if we had 137 developers all working on this everything would be magically solved, but alas, we have a monolith" was a sentence I uttered (or heard) exactly 0 times so far.

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

#416

Post by randomswede »

stickfigure wrote: post #365
ozim wrote: post #229

Earlier quoted context omitted.

Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…

My theory is that microservices became vogue along with dynamically typed languages. Lack of static types means that code becomes unmanageable at a much lower level of complexity. So the complexity was "moved to the network", which looks like a clear win if you never look outside a single component.

The archetypical "microservice" ecosystem I am aware of is Google's production environment. It was, at that point, primarily written in C++ and Java, neither very famous for being dynamically typed.

But, it was a microservice architecture built primarily on RPCs and not very much on message buses. And RPCs that, basically, are statically typed (with code generation for client libs, and code generation for server-side stubbing, as it were). The open-source equivalent is gRPC.

Where "going microservice" is a potential saving is when different parts of your system have different scaling characteristics. Maybe your login system ends up scaling as O(log n), but one data-munging part of the system scales as O(n log n) and another as just O(n). And one annoying (but important) part scales as O(n * 2). With a monolith, you get LBs in place and you have to scale you monolith out as the part that has the worst scaling characteristic.

But, in an ideal microservice world (where you have an RPC-based mechanism taht can be load-balanced, rather than a shared message bus that is harder to much harder to scale), you simply dial up the scaling factor of each microservice on their own.

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

#417

Post by SergeAx »

matwood wrote: post #144
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…

I've argued for a long time that microservices should grow out of a monolith like an amoeba. The monolith grows until there is a clear section that can be carved off. Often the first section is security/auth, but from there it's going to be application specific. A modulith could be just another step in the carve up process. But, there is no right answer here. Application domain, team size, team experience, etc... all…

> from there it's going to be application specific

It is actually sensible to keep all the business logic layer(s) in the monolith while it is possible. Easier to grasp the domain for new team members, easier to bound context.

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

#418

Post by tpetry »

wruza wrote: post #414
drbojingle wrote: post #321

Guy who hates micro services here (worked at a startup that tried to adopt them because the CTO's consulting friend who works in enterprise convinced him of how great it was). From what I can tell, micro services are primarily a solution to an organizational problem and not a technical one and I think people trip over this. If you have 600 developers working on the same back-end then you can benefit from micro servic…

I’ve heard before that microservices deployment scheme solves one particular task: if you get traction, you’ll be ready for scaling. If you can’t do that you are already dead, cause being unable to get 10x more users with a click (when they come) means your competition will do that instead. Is that still true?

You can just start 10 more instances of your monolith. It‘s not a problem.

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

#419

Post by baalimago »

Seems, to me, that the author is poor at designing microservices. Using his example: the login, session and user services should be only one service (something like Keycloak), there's no advantage to splitting this up, so why would you? Analytics service should never be a dependency of another serivce, but rely on service discovery and a preset telemetry/analytics/rpc endpoint which each of the consumer-facing services implements.

Has anyone claimed that microservices will fend of poor design? There's never a silver bullet.

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

#420

Post by DeathArrow »

For me it highly depends on the size of software, the time to market, the time the software is supposed to work without major rewrites.

If I am doing a blog application or an website for one time event, I would pick a monolith.

If I start on ERP, a checkout solution I would pick microservices.

Also if the man power is low but I expect growth in the future, I might go for a monolith broken in separate projects with minimal dependencies between modules so it wouldn't be terribly difficult to break it into microservices when the need and man power arrives.

Post reply on HN