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

Microservices are hard

code-held.com

Post reply on HN
Print view View original

241–250 of 356 posts

Re: Microservices are hard

#241

Post by ranting-moth »

foepys wrote: post #136
ranting-moth wrote: post #54

Earlier quoted context omitted.

I've seen quite a few people use the argument that their system wouldn't cope otherwise when they reach the size of Google. If you are one of those, then I have news for you. 1. You are not going to reach the size of Google. Certainly not if you are engineering for it in your 2 person startup. But in case you do, see number 2. 2. Reaching Google scale means you'll have funding to hire good people to scale your softwa…

If you plan your architecture carefully and modularize a lot, there is very little that will prevent you from branching out modules of a monolith into microservices when the time comes. If you produce spaghetti code with tightly coupled components, well, then you are going to have a problem.

Especially in small startups, you need to make a sensible balance.

If you only have funding for 2 months, you need to hack together whatever you can get away with.

This is not against modularisation. By all means designs your system well. But don't lose sight of the goal.

Re: Microservices are hard

#242

Post by JAlexoid »

jameshart wrote: post #90
PaulHoule wrote: post #84

Earlier quoted context omitted.

I get the feeling he really misses the point. The most dangerous thing about microservices is that many people squee when they hear "You can write 45 different microservices in 35 different languages". Writing a new microservice? What a great opportunity to learn a new language! Now it is true that by decoupling the address spaces microservices do let you take advantage of different runtime systems: you might really…

Not having to upgrade in lockstep is great though - the downfall of many monoliths is the ‘forced death match to port to new version of the platform because we put this off so long it’s about to leave LTS’. Being able to use different stacks where appropriate is also great (but needs care). E.g. if you are a Java shop but you want to deploy an ML pipeline you should at least consider carving out a pathway for deployi…

I'm sorry, but as someone that actually works on ML pipelines - no ML is a microservice.

Data space doesn't work well with microservices.

Re: Microservices are hard

#243

Post by nostrebored »

esailija wrote: post #134
jerf wrote: post #78

No, they aren't. The entire point of the big ball of mud is that there are no meaningful divisions in the code. Everything uses everything willy-nilly, at the smallest possible level of abstraction. There is, metaphorically if not always entirely literally, not a single line of code in the system that you can change without fear of bringing something else down that you may not have even known they existed. Microservi…

> It may be the sloppiest, crappiest definition every, with dynamic types Funny you said that since a microservice API is always dynamically typed and its usage cannot be checked by compiler. And the more microservices you use the more dynamically typed the whole project gets overall. While you can opt into a free for all everything importing everything, all languages do also support creating modules which define API…

Schema contracts are common and can be baked into build if not compile.

Re: Microservices are hard

#244

Post by gfodor »

_ea1k wrote: post #208
gfodor wrote: post #80

Earlier quoted context omitted.

You could say this about any criticism of mainstream practice. This is not a rebuttal and contains no new information. Actually, I lied - this post is actually a strawman: it contains the information that you actually didn’t understand the point of the article. He is referring to people who have deployed microservices when they needed modules, not people who deployed microservices when they needed microservices.

TBH, his definition of "module" brings it awfully close to microservice.

I thought he was referring to typical in-process encapsulation. If you do that well, you can run those separately “for free” optionally, but I think his definition of module is nothing unique.

Re: Microservices are hard

#245

Post by JAlexoid »

hintymad wrote: post #231

> Large companies like Uber learned this the hard way: Uber is really not a good example. Many Uber engineers created services for the sake for claiming their territories or for sheer stupidity. On the other hand, managing services in Netflix was a non-event, and people really exercised their judgement carefully when it came to creating a new service. Yeah, I'm saying Uber's problem was cultural and organizational, n…

> Yeah, I'm saying Uber's problem was cultural and organizational, not technical.

That's the issue currently with microservice architecture zealots - microservices for the sake of microservices.

Re: Microservices are hard

#246

Post by JAlexoid »

speed_spread wrote: post #88
thatwasunusual wrote: post #24

Earlier quoted context omitted.

> Monoliths can also scale horizontally At a (potentially much) bigger cost.

Running costs or development costs? If you have a low-request / high complexity persistent application you may want to optimize for maintainability. Having all the code in one place _can_ make things easier to figure out in the long term.

> maintainability

Sir this is HN, half of the people here will quit their team well before maintainability is even uttered.

Re: Microservices are hard

#247

Post by jgust »

tasuki wrote: post #237
sisve wrote: post #158

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…

> Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. I might think that, depending on the context. Are you a multinational with thousands of monkeys at thousands of typewriters? Of course you shouldn't have everything in one system! Are you a five person startup, out of which only three write code? Knowing nothing else, I'd suggest everything in one system.

I think that's covered under "context".

Re: Microservices are hard

#248

Post by ch_sm »

sisve wrote: post #158

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…

> enough pieces so that; 1. your engineers … are not afraid of doing changes.

I don’t really understand that argument, and I don’t really feel safer making a change to a microservice inside a large system, as opposed to making a change to a monolith — the consequences of a mistake are equal in both cases (although harder to observe/debug in a microservice architecture) — am I missing something?

Re: Microservices are hard

#249

Post by mdaniel »

ricardobeat wrote: post #210
pier25 wrote: post #198

Use the best tool for the job. It's stupid to think of monoliths vs microservices. You can use both if the problem requires it. For example I'm currently working on an audio hosting service. The main app is a monolith where 90% of the code resides but there are a couple of ancillary services. Audio encoding (which is heavily CPU bound) is a serverless microservice that can scale up and down as needed. Users don't upl…

This argument is brought forth a lot, but it misses the point. Often people think microservices are the right tool for the job , but they vastly underestimate the complexity that it entails.

> Often people think microservices are the right tool for the job, but they vastly underestimate the complexity that it entails.

And that goes 10x if deploying, monitoring, or debugging said services is Someone Else's Problem ™ I'm also cognizant that such a situation is just as much an organizational/people problem as the rest of this debate, but I have a sore spot around people making decisions where they don't have to suffer the consequences from them

Re: Microservices are hard

#250

Post by username135 »

avip wrote: post #165
sisve wrote: post #158

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…

Like any other well reasoned, balanced and pragmatic POV, the problem with your boring approach is you can’t wrap it in a clickbaitable blog and no flame war can emerge from it.

lol
Post reply on HN