The Death of Microservice Madness in 2018 • Hacker News Board

Re: The Death of Microservice Madness in 2018

#361

Post by michaelcampbell » Mon, Jan 22, 2018, 2:03 PM UTC

z3t4 wrote: post #43

nemothekid wrote: post #33

Earlier quoted context omitted.

Once when starting a new gig I inherited a "microservices" architecture. They were having performance problems and "needed" to migrate to microservices. They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. Of course if you were using microservices, you needed docker as well, so they had also developed a giant docker container containing all 12 microservices which they de…

You don't always have to know why but it's somewhat frightening that so many "engineers" don't have a clue why they are doing something (because Google does it). And I'm of course guilty of it myself jumping on the hype-train or uncritically taking advice from domain experts only to find out years later that much of it was BS. Most of the time though, you will not reach enlightenment. I guess it's in our nature to fo…

> it's somewhat frightening that so many "engineers" don't have a clue why they are doing something (because Google does it).

This doesn't stop at engineering; open offices, teaser/trick based interviewing, OKR's, ... Even GOOGLE doesn't do some of those things anymore, but the follower sheep still do.

Re: The Death of Microservice Madness in 2018

#362

Post by sokoloff » Mon, Jan 22, 2018, 2:06 PM UTC

McP wrote: post #294

ivan_gammel wrote: post #290

Earlier quoted context omitted.

It's much harder to deploy a library fix to production (producing a new build of integrated app in large team is a big deal), than a microservice.

It shouldn't be a big deal. https://en.wikipedia.org/wiki/Continuous_delivery

It shouldn't, but in practice sometimes is. It's not the pushing of bits that's hard; it's the ensuring that the library got everywhere it needed to go and that the new release of the other users of that library didn't introduce any bugs.

Imagine you have a library that implements the serialization and deserialization of something in your system (or anything else where the library implements two "halves" of some functionality). You might (or might not, depending on the change) need to push out that library to other apps to effect the fix you're working on. That new proposed library change may be in a queue behind another pending change that's in development, etc.

Re: The Death of Microservice Madness in 2018

#363

Post by tboyd47 » Mon, Jan 22, 2018, 2:25 PM UTC

shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

That's absolutely true, but it's not specific to microservices. The pendulum could very well swing back the other way

I've come to view microservices in the context of Conway's Law. If you have a team of developers working on a project who don't like to communicate or work with each other, do not understand version control, and all have different programming styles and technology choices, the only feasible architecture is one service per person.

I have no trouble believing that this is what's really behind Netflix's adoption of microservices. From what I've heard it's a sociopathogenic work culture, and if I worked there I would probably want to just disappear from everybody too.

Re: The Death of Microservice Madness in 2018

#364

Post by klodolph » Mon, Jan 22, 2018, 2:26 PM UTC

bpicolo wrote: post #358

klodolph wrote: post #152

Background… I’ve been on good and bad projects that used microservices, and good and bad monolithic projects. The madness is going away but the microservices are staying. There are some rationales for microservices that are conspicuously missing. 1. Fault isolation. Transcoder stuck in a crash loop? Upload service using too much RAM? With microservices, you don't even really have to figure out what's going on, you ca…

> Better scheduling. A service made of microservices is easier to schedule using bin packing. Low priority components can be deprioritized by the scheduler very easily. This is important for services with large resource footprints. That's harder scheduling, not easier. With a monolith you just give it all the resources and threads will use resources as is necessary. After that it's a matter of load balancing appropri…

> That's harder scheduling, not easier. With a monolith you just give it all the resources and threads will use resources as is necessary. After that it's a matter of load balancing appropriately.

The key was "with bin packing". If you "just give it all the resources" then you're not bin packing and you're barely scheduling. At that point, your scheduler is only capable of scheduling based on CPU and IO usage, and not (for example) based on RAM. That last one is tricky, because most runtime environments won't return memory to the operating system (e.g. free() won't munmap()), and we're currently in the middle of a RAM shortage. Your machines will almost always have a different shape from your processes, it's just something you have to live with.

A bin packing scheduler is not useful for all companies and all services. It depends on the size of your resource footprint, with very large services benefiting the most.

So, microservices give you better scheduling in the sense that you can use fewer machines to run the same set of services. However, this is not important to everyone.

This stuff is built into e.g. Kubernetes so it is actually quite easy. You just can't do it with monoliths.

Re: The Death of Microservice Madness in 2018

#365

Post by artimaeis » Mon, Jan 22, 2018, 2:37 PM UTC

stult wrote: post #333

simias wrote: post #268

Earlier quoted context omitted.

The #1 thing they should teach in any engineering school (or maybe any school period ) is "you shouldn't remove/replace/change something until you've understood why it was done that way in the first place". Or maybe a somewhat equivalent version: "you're not as clever as you think you are and the people who came before you were not as dumb as you think they were".

>"you shouldn't remove/replace/change something until you've understood why it was done that way in the first place". That only works until you encounter something for which there was no rational reason in the first place.

I've yet to encounter anything erected for no reason at all. But there are plenty of projects where rationality didn't have much a role in their choice of creation. Examples like that can usually be tied to a previous dev/engineer wanting to pad their resume with a new project, maybe with a new framework. Or a manager who wanted their team to have more completed work to look better on some miscalculated performance metric. Failing those options - it could be a bored employee who just wanted to make _something_.

That is to say - most people are acting rationally, but their context to an outsider may not appear rational. Maybe there's something to be said for a general relativity of rationality?

Re: The Death of Microservice Madness in 2018

#366

Post by corpMaverick » Mon, Jan 22, 2018, 2:42 PM UTC

tboyd47 wrote: post #363

shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

That's absolutely true, but it's not specific to microservices. The pendulum could very well swing back the other way I've come to view microservices in the context of Conway's Law. If you have a team of developers working on a project who don't like to communicate or work with each other, do not understand version control, and all have different programming styles and technology choices, the only feasible architectu…

You do have to use Conway's Law to your advantage. At least be very aware of its effects.

Re: The Death of Microservice Madness in 2018

#367

Post by justinwp » Mon, Jan 22, 2018, 2:49 PM UTC

Appears to be hip to bash microservices now. We have some very clear reasons that keep us on the service oriented path.

- scaling based on very disparate resource requirements across our api

- security isolation of critical backend infrastructure

- language requirements and dependency management

- accommodating different skills and groups of skills across our organization

Re: The Death of Microservice Madness in 2018

#368

Post by jlg23 » Mon, Jan 22, 2018, 2:49 PM UTC

shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

I don't think microservices are loved by developers so much because they are technically superior but because they allow for quicker/safer decision-making on management level - just like "agile development" imho only helps trainee-devs but shines in providing clear communication strategies between management and developers (read: keeps mgmt off dev's back for at leat 6h a day).

Abstractly spoken, I don't care whether you call f(x) directly, via IPC, RPC or as a microservice. In my preferred programming languages there is not much of a difference anyway.

Re: The Death of Microservice Madness in 2018

#369

Post by throwawayfpq8 » Mon, Jan 22, 2018, 2:52 PM UTC

SOLAR_FIELDS wrote: post #315

brisance wrote: post #212

Earlier quoted context omitted.

This is Parkinson's Law of Triviality. https://en.wikipedia.org/wiki/Law_of_triviality

It is frightening to see bikeshedding in practice. I used to work for a regional transportation authority that would administer hundreds of millions of dollars in federal/state/local road projects. Local leaders would monthly come in and sit at a huge round table (40-50 cities/counties/regional leaders) and vote on projects. 800 million dollar projects would sail through with almost no questions in the first five min…

Gee, kinda sounds like Hacker News...

Re: The Death of Microservice Madness in 2018

#370

Post by ska » Mon, Jan 22, 2018, 2:53 PM UTC

danieltillett wrote: post #299

dreamcompiler wrote: post #175

Earlier quoted context omitted.

I call this the painting problem. Painting the walls of a room seems easy to an amateur: You just buy a few gallons at Home Depot and slap it on. But a professional knows that prep, trim, and cleanup are 80% of the job and they take skill. Anybody can slap paint onto the middle of a wall. What's difficult and time-consuming are making the edges sharp and keeping paint off the damn carpet.

My experience is a careful amateur painter is 1000% better than an average professional. Professionals are certainly a lot faster, but if you look carefully at their work it is in the main very shoddy. If you want a good result don’t skimp on the tools. Buy good quality brushes, rollers, filler, throws and paint. Also buy an edger to cut in the walls and ceilings. One final tip buy some of the disposable plastic line…

I think there are two things at work here.

1 - there are very good professionals, but they aren't cheap and have all the work they need

2 - an amateur can always decide to take economically irrational amounts of time on a project; a professional can't.

So the result is that as a careful amateur you can end up with a job you probably wouldn't be able to convince yourself to pay for.

We can probably all agree that the worst case is the careless amateur....