Starting with microservices • Hacker News Board

Re: Starting with microservices

#101

Post by kavalg » Thu, Jan 20, 2022, 8:49 AM UTC

steve_taylor wrote: post #55

rapind wrote: post #53

Earlier quoted context omitted.

Pretty sure microservices will be remembered as a horribly convoluted stop gap once we have better language modularization. They encourage modular patterns which is usually good, but all that plumbing will eventually become unnecessary. I can’t help but remember building 6 versions of each class in the old ejb days whenever I hear microservices hype.

OSGi was supposed to solve this problem. You could start by running all bundles together in the same JVM, then split them across a cluster later if required. But it never quite took off beyond an implementation detail of various application servers.

OSGi was a horrible dev experience. Lots of quirks and legacy. Nobody wants to maintain that code anymore.

Re: Starting with microservices

#102

Post by diordiderot » Thu, Jan 20, 2022, 8:53 AM UTC

trixie_ wrote: post #80

throwaway1777 wrote: post #56

Earlier quoted context omitted.

Example of better language modularization? Who is working on this?

PHP, hear me out, each file is basically an independent hot swappable 'service'. I wish more languages/compilers/runtimes had a similar capability.

Could you explain this more??

Re: Starting with microservices

#103

Post by marcus_holmes » Thu, Jan 20, 2022, 8:54 AM UTC

yawnxyz wrote: post #2

I don't understand why people treat microservices or monoliths as either or. If I find my various projects using the same functionality over and over, then I'll split that off as a microservice to serve my monolith projects of various sizes. It's like functions: don't turn code into a function until you need it in three different places.

Or you could have it as a module/library that you import into all your monoliths, and save the communication overhead.

But then, I'm firmly in the old-skool "don't split the monolith until you absolutely have to" camp.

Re: Starting with microservices

#104

Post by davedx » Thu, Jan 20, 2022, 9:09 AM UTC

Znafon wrote: post #65

throwaway1777 wrote: post #56

Earlier quoted context omitted.

Example of better language modularization? Who is working on this?

Perhaps some idea and abstractions from Erlang could be interesting to explore in more mainstream languages?

Yeah erlang is great

Re: Starting with microservices

#105

Post by ceesharp » Thu, Jan 20, 2022, 9:10 AM UTC

BatteryMountain wrote: post #94

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…

If your IService has 15 methods and your ctor has 20 dependencies injected, then you have other issues. :)

Re: Starting with microservices

#106

Post by bvm » Thu, Jan 20, 2022, 9:19 AM UTC

withinboredom wrote: post #100

blakehaswell wrote: post #77

Earlier quoted context omitted.

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

I've done this before, it felt like a bit of a hack tbh, but I'm glad to hear someone else is doing it!

Re: Starting with microservices

#107

Post by tacone » Thu, Jan 20, 2022, 9:20 AM UTC

crdrost wrote: post #70

bob1029 wrote: post #19

I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…

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…

"Gut-feeling microservices" is a fantastic definition, thanks for that.

Re: Starting with microservices

#108

Post by tmstieff » Thu, Jan 20, 2022, 9:33 AM UTC

bob1029 wrote: post #42

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…

> Once an app reaches a certain size and anything can depend on anything else, reasoning about the whole can become difficult. I have experienced this pain so many times and in so many different varieties. Often, you cannot meaningfully subdivide the problem space without ruining the logical semantics per the business (i.e. bowl of spaghetti). An alternative is to embrace the reality that circular dependencies are ac…

I think I agree with you as well. Although it is hard for me to picture exactly how you've structured your dependency graph. In any case, extracting the business logic into some sort of static method / class has definitely been one of the only useful things I can carry across projects that works in nearly all use cases. It also makes unit testing the actual business logic extremely easy. That said, you can end up with a static method that takes 20 parameters, which is always fun. But, in those cases, you are lefty dealing with complexity that is intrinsic to the business, rather than complexity introduced through some bad architectural decision, so at least it is isolated.

Re: Starting with microservices

#109

Post by twic » Thu, Jan 20, 2022, 9:38 AM UTC

withinboredom wrote: post #100

blakehaswell wrote: post #77

Earlier quoted context omitted.

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

I have done this several times, with various small variations, and find it works well. I don't have a good name for it.

I think it's a variety of cookie-cutter scaling:

https://paulhammant.com/2011/11/29/cookie-cutter-scaling/

But there's nothing in that about using different entrypoints or routing.

FWIW, variations on the theme:

1. A single binary with a single entrypoint, which can play multiple roles simultaneously (UI, API, scheduled jobs), but where different kinds of request are routed to different pools of instances

2. A single binary with multiple embedded configurations, selecting via command line arguments etc, each for a single different role (UI, admin console, data ingestion)

3. A single (Java) binary with multiple entrypoints (main methods), each playing a different role (live calculations, batch calculations, data recording)

4. A single (C++) codebase building multiple binaries (via CMake add_executable), each playing a different role (calculating prices for potatoes, calculating prices for oranges)

5. A single repository with multiple completely separate applications, with some shared submodules, each built separately, playing a different role (receiving transactions, validating transactions, reporting transactions)

That last one is probably not an example of what you are talking about, but it's closer to the one before than to the first in the list. There is a sort of "ring species" [1] shape to this variation.

[1] https://en.wikipedia.org/wiki/Ring_species

Re: Starting with microservices

#110

Post by twic » Thu, Jan 20, 2022, 9:42 AM UTC

crdrost wrote: post #70

bob1029 wrote: post #19

I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…

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…

> Gut-feeling microservices

I'm in this comment and i don't like it.

My current team has this pattern. I think we've ended up with two core services, with a fairly thin channel between them, but a constellation of tightly-coupled peripheral services around each core.

To be honest, it works pretty well. It wasn't intentional, and it grew in exactly the haphazard way you describe. But it's not a disaster, or at least doesn't feel like one.

Maybe we should rebrand this as "natural microservices"?