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

81–90 of 139 posts

Re: Starting with microservices

#81

Post by pphysch »

wmichelin wrote: post #74
pphysch wrote: post #58

Earlier quoted context omitted.

I'm involved in a (greenfield) project right now where the lead insists on gluing a bunch of Google Sheets/Forms/Docs/whatnot together with triggers and custom APIs (roadmap TBD) instead of just building a simple website in $framework. Fingers crossed he doesn't discover k8s...

Do you feel those hosted solutions are worse than rolling your own website? Why stand up your own website and architecture if you can use off the shelf solutions? I am genuinely curious.

Yes. The project has a (dynamic) website as one of the requirements so we will be building one anyways. And if the lead gets his way, a multiple additional APIs to interface with the Google apps.

Re: Starting with microservices

#82

Post by iamcreasy »

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…

> simple path of direct method invocation

Does it mean calling a method of a class?

Re: Starting with microservices

#83

Post by mbrodersen »

If you don’t know how to manage the complexity of a monolith (by using modules/libraries/clean interfaces) then you will have even more problems managing the complexity of micro-services. Since micro-services include all the complexity of the monolith with added networking and deployment complexity.

Re: Starting with microservices

#84

Post by JamesSwift »

aflag wrote: post #33
JamesSwift wrote: post #25

Earlier quoted context omitted.

It seems over time some nuance has been lost in translation on this. Microservices weren't 'more scalable' than monoliths, they were 'more appropriately scalable'. In other words, you could scale parts independently and shape your infrastructure more effectively for your workload. e.g. If your bottleneck is logins, you scale the LoginService and don't need extra copies of the AppointmentService running to keep up.

Sure, but I think the point is that it's unlikely the bottleneck will be in the web server, but in whatever database you're using for your logins. Just because you have a single program, it doesn't mean it is required to use a single database. But even if the webserver is the problem, it feels unlikely that you'll end up saving much in infrastructure cost by scaling just the login service rather than just deploying m…

Im not arguing for or against (I'm pretty against micro services), I'm just explaining what the arguments are

Re: Starting with microservices

#85

Post by jamesfinlayson »

brundolf wrote: post #34
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…

You could even have a mono-repo that holds services which run as separate processes, if you need that. That way you still get the benefits of sharing code, types, version numbers, build processes, etc, which seem like the main headaches with the usual approach.

I've inherited a project like this - lots of common code in a shared library that gets used by multiple services. Doesn't work too badly but things have been split out more than they need to be.

Re: Starting with microservices

#86

Post by jamesfinlayson »

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…

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.

Re: Starting with microservices

#87

Post by namelosw »

Microservices mix several different needs: scalability, function decomposition, and team structure. If you want them all you might want microservices, but there are better alternatives when you only want one or two of them.

People have different opinions on microservices because microservices is great when done right, but can easily screw things up if people don't split the bounded contexts carefully. It's also more expensive to correct these mistakes because there are APIs between them instead of just code, so many projects would live on with them painfully forever.

Re: Starting with microservices

#89

Post by Orou »

jayceedenton wrote: post #63

The example given, of adding new instances of a session service that consumes from a Kafka topic, is completely wrong. Kafka producers use a partition key of your choice, so the UserLoggedInEvent and UserActivityEvent that relate to the same userId will always be written to same partition. This is how horizontal scaling of Kafka consumers works, without ordering problems. Anyone that isn't aware of this has very limi…

> This cycle of having a few years where the costs of an approach aren't acknowledged, to a few years where the benefits aren't acknowledged, is very lame.

Well said. I do sympathize with some of the criticisms but only insofar as people who didn't have experience with microservices get sold on a lot of hype, the tradeoffs aren't made clear, and they get burned. The cycle seems to be "This is the silver bullet for programming complexity!" for a few years, followed by a few years of "This isn't a silver bullet!" before the Next Big Thing (TM) comes along and the cycle starts over.

Re: Starting with microservices

#90

Post by pas »

marcosdumay wrote: post #52
pas wrote: post #27

Earlier quoted context omitted.

Monolith becomes a problem when it becomes too big to build/test/deploy/debug in a sane fashion. And when you have alternatives, great. But for example game devs don't. Or operating system devs. Though of course these are all active areas of ongoing research (for decades!). If the problem/subject were that easy we would have already solved it and it wouldn't be a hot topic. And since it's likely a nonlinear problem i…

Building, ok, but for testing or debugging microservices aren't really an alternative. Just like scalability, they add no new capability here. The most they can do is adapt better to some set of procedures than a monolith. For deploying they are nothing but a very large hindrance.

Is it not better to debug one microservice than the whole monolith? Easy to run locally, easy to reproduce errors, etc. (My last two weeks was working in such an environment hunting a production bug. Debugging it was a pleasure. Clear interfaces, etc. Of course when a small feature requires changing 3-4 microservices the pleasure is definitely less :D)

It's much easier to test them in separation also. Deployments are low risk, not much need for coordination with other teams, etc.

There are components that have a heavier load, so we run more of those. Not really a big difference compared to simply running a few more monoliths and configuring them to only handle certain requests... but that's already a given here.

I don't have strong opinions either way. Teams/companies should do what works for them, and they should spend some time on improving it so they can be more effective. (Because most people/teams/companies have a "good enough" complacency inertia/bias.) And most solutions work in both setups. (Eg. making builds fast requires a divide and conquer strategy anyway. Do you build modules/packages separately and link them in the end? Do you build containers separately? Same thing. Do whatever works.)

Post reply on HN