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

You Don't Need Microservices

medium.com

Post reply on HN
Print view View original

91–100 of 169 posts

Re: You Don't Need Microservices

#91

Post by blowski »

tomlin wrote: post #89
blowski wrote: post #87

Earlier quoted context omitted.

Check out my comment history and you’ll see that I agree with the points too! But the bar for a good Hacker News post is “interesting”. Opinions that are widely agreed with on here, and have been for years, don’t meet that for me personally. That’s my say on the matter, you of course are welcome to yours. For what it’s worth, I live in the UK, and have never been to the US.

I implore you to watch the incessant, and regular posts on HN claiming that microservices are the future for everyone and everything, and then be there to tell them you've seen this before. My guess is you won't be as lead-footed in those cases. The idea that if you write an article or an opinion, and have to do an hour of research to see if its been covered before is a high level of micromanagement that you just are…

Sure. It’s also super-unrealistic to expect me not to criticise the article for being boring.

Re: You Don't Need Microservices

#92

Post by tomlin »

blowski wrote: post #91
tomlin wrote: post #89

Earlier quoted context omitted.

I implore you to watch the incessant, and regular posts on HN claiming that microservices are the future for everyone and everything, and then be there to tell them you've seen this before. My guess is you won't be as lead-footed in those cases. The idea that if you write an article or an opinion, and have to do an hour of research to see if its been covered before is a high level of micromanagement that you just are…

Sure. It’s also super-unrealistic to expect me not to criticise the article for being boring.

> "where you can get a whole bunch of likes by saying “microservices bad amirite?!”

Okay.

Re: You Don't Need Microservices

#93

Post by declnz »

> Odds are it is easier to resolve performance issues and bottlenecks in your monolith than it is to transition to a new architecture pattern.

I dunno but when I see odds are $X I read unproved and perhaps unprovably, my opinion is $X

Re: You Don't Need Microservices

#95

Post by jacquesm »

dkarl wrote: post #82
foobarian wrote: post #32

Earlier quoted context omitted.

I find it pretty entertaining how the word "microservices" got to mean what we used to mean by "services" or "web services." It has not referred to size in the npm "left-pad" sense at all for a long time now. I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."

I think there's a lot of historical accident involved. Personally, my experience of the two terms was that I heard about "services" aka "SOA" first, and it meant a top-down global architecture where the pieces were composed in elaborate, cumbersome ways: service buses, orchestrators, complicated XML-based technologies, service discovery, remote transactions, all that fancy stuff that many people tried and few people…

This kind of thing happens a lot in IT. You could see the same thing around 'Agile', '4th generation languages', 'mindfullness' and a whole raft of other terms that momentarily become the fuel for the incomestream of certain consultants.

Re: You Don't Need Microservices

#96

Post by atleta »

blowski wrote: post #37

I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”

Which is a good thing, since microservices were way overhyped from the beginning. Now bashing too hard wouldn't be good either, but fortunately, the organizations that need it will be technologically mature enough to be able to ignore the current hype.

Whereas when microservices were overhyped, they were introduced into orgs/companies that didn't have the brain power/experience to implement these properly or just to be able to say an informed no.

Re: You Don't Need Microservices

#97

Post by jacquesm »

foobarian wrote: post #65
jacquesm wrote: post #41

Earlier quoted context omitted.

When I see a service around every single table in a database with an absolutely ridiculous spaghetti of inter-process communication to tie it all together it usually is because someone took the 'services' pattern a bit too far and in that case 'microservices' is a proper moniker. And for Erlang based systems it usually is also appropriate. If there are fewer than 10 or so services usually they are not 'microservices'…

> a service around every single table in a database with an absolutely ridiculous spaghetti of inter-process communication to tie it all together For what it's worth, I suddenly feel a lot better about my employer's architecture. :-) But we still call them microservices because language.

There was this fantastic cartoon in a dutch newspaper long ago, it was a really long train about to leave the station and lots of people were trying to get on it, by hook or by crook, people hanging on to windows, sitting on the buffers etc. A reporter with a microphone approaches one of the people trying to get on the train. "Sir, why are you trying to board the train, where are you going?". The answer "I have no idea but I really don't want to miss it.".

The banner on the train was 'The Internet', the cartoon was published in 1995, right when the dot com bubble started its proper inflationary phase.

These hype-trains occur over and over again around a specific theme, the funny thing is that 'the internet' eventually became at least as revolutionary as those that were trying to board that train hoped it would be. But the bulk of those hyped things are usually not going to make such a huge difference and then, instead of adopting the item and incorporating it we move on.

You can usually get an idea after a year or two when a technology is introduced which way it will go, and a good sign that the life is out of it is when the consultants and writers of books move on to greener pastures.

See also: blockchain, the semantic web, etc, etc...

Re: You Don't Need Microservices

#98

Post by bb88 »

willcipriano wrote: post #88
throwaway894345 wrote: post #66

Earlier quoted context omitted.

Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. We had a monolith, and it devolved into a mess--managers would insist on people taking dependencies on stuff they didn't own in the name of expedience ("yeah, we'll totally circle back and do it the right way lol"). Microservices kept things neat by making du…

Microservices suck when you need to make a process faster, so you run a profiler and figure out that 90% of the workload is handling the http requests between the services.

I feel like HTTP is too heavyweight for microservices. For monoliths, it's great. And the only way to proceed in your case is to convert microservices into mini-monoliths. Particularly the authentication side, which needs to be revalidated with every request.

gRPC might be better, but supposedly so was SOAP, CORBA, DCOM, XMLRPC, and finally REST.

Re: You Don't Need Microservices

#99

Post by johnthescott »

kristopolous wrote: post #81

Some people will make an incoherent mess out of anything. A garbled knot of interdependent microservices with timing issues, bad extensibility, and unpredictable flow. An ornate matroyshka set of wrapper functions calling each other spreading over multiple directories making any modification a large error prone effort. Event systems, probably multiple, without any real difference between just a function call other th…

bravo

Re: You Don't Need Microservices

#100

Post by atleta »

DoneWithAllThat wrote: post #34

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

It still depends on the organization size (or the size of the user base, or the complexity of the product). So you may only have experience with services where it was the right choice.

I did see two instances where it wasn't. (I mainly work with/for small companies, startups.) In one instance I was called in as a tech lead/expert for a small startup having a kind of a product/software crisis. They've been working on their service for a year or too (yes, way too long) and 2-3 months before the planned release at some random conference (Slush, TNW or whatnot) one of the developers figured out that the whole codebase was a piece of shit and there was no way they could be ready in time, but they should rewrite it as a collection of node microservices and that could work. The monolith they had was PHP, just to add to the fun, so switching over would mean switching languages too.

The guy, he was a smart and motivated chap, even started implementing one service in his free time, the user registration/user handling I think (the least important and least complex one, of course) which somehow screwed up the monotlith and made it start crashing. (Or so they said, I don't know what was up with that.)

Obviously, it was a 100% stupid idea and we went on with fixing their development process (starting to do scrum and teaching the stakeholders that they need to stop phoning the developers directly and asking for features, fixes, introducing automated testing, etc.) Oh, and it was a team of 2-2.5 people. (With the group manager doing some backend work too, but also managing another, totally unrelated project for another client.)

The other one was a bit different story, where I just shared my insights over a call. A guy I've known took over a project that was built by a small team (2-5 people, can't remember) for a startup and wanted some external opinion for himself and the founder. That one was built as a set of microservices but they did have all kinds of stability issues. The idea was that it had to be very-very-super scalable. Because, you know you launch and they will come and there's nothing worse than not being able to handle the load. Except, there is: they had been building the thing for over 2 years back then.

It was an online medical consultation solution (you describe your problem, pick a doctor, do a f2f call and pay by the time). The funny thing is that I've built a very similar system, as a startup cofounder, 3-4 years earlier for psychology consultation with the help of 2 other guys, who didn't even work full time (one of them came after the first one quit). The MVP was up in, I think, 2 maybe 3 months. Ours was a monolith-ish thing and theirs definitely looked better, maybe scaled better and would have been cheaper to operate at scale (we used an external service for the video calls). But ours was a lot cheaper to build and launch and we could test (validate) our solution a lot earlier with real customers.

If it worked out, we could have started breaking it down into multiple services as/if/when needed.

Post reply on HN