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

The Death of Microservice Madness in 2018

dwmkerr.com

Post reply on HN
Print view View original

381–390 of 469 posts

Re: The Death of Microservice Madness in 2018

#381

Post by pixl97 »

kuschku wrote: post #259
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.

That may be a bad analogy, considering painting your own apartment is something a great deal of people do, and often with good success. My parents (not in any way experts on that field) painted their entire house themselves, except for two rooms that were painted by a professional painter, and the professional painter left much worse corners than my parents. This was the paid-for result (ignore the dark corner at the…

Have your parents start painting houses every day aND youll find they get far worse at it.

Re: The Death of Microservice Madness in 2018

#382

Post by carlmr »

tomtimtall wrote: post #342
SOLAR_FIELDS wrote: post #315

Earlier quoted context omitted.

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…

I once sat in the board of a student organisation management a $3mil investment fund. Which was rapidly declining as funds where being withdrawn to cover budget deficits. At the same meeting where no-one could explain, and no-one seemed to care about a 100,000$ transaction listed as “assorted expenses”, people spend 1,5 hours debating whether the coffee-shop should keep buying newspapers for 200$ a year...

I think it's also kind of an effect that humans don't have an intuitive grasp of big numbers. Add to that the effect that humans think more about what they can imagine. You can kind imagine spending $200 on newspaper in your everyday life. You seldom make $100,000 decisions. Big one-time transactiosn seem intuitively less impactful than many smaller ones.

As Programmers we deal with numbers a lot more often, so this effect is minimized. But still there.

Re: The Death of Microservice Madness in 2018

#383

Post by marcosdumay »

cortesoft wrote: post #205
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.

So you are saying edge and corner cases are the most difficult?

Keep the stuff from spilling all over the place is also between the most difficult things.

Re: The Death of Microservice Madness in 2018

#384

Post by [deleted] »

jblow wrote: post #139
Clubber wrote: post #130

Earlier quoted context omitted.

10 people managing a single "micro service" does raise a red flag to me as well. It may be normal based on the complexity, but my first thought is, why is the codebase require so many people to maintain and add features to? Are they just adding features like mad, or something squirrelly in there where most modifications take a lot of man hours?

How micro can it possibly be if it takes 10 people to deal with it? Seriously.

[deleted]

Re: The Death of Microservice Madness in 2018

#385

Post by corpMaverick »

linkmotif wrote: post #357

People talk about building monoliths like it’s some simpler alternative. On the JVM it’s not. When I first started with Java one of the coolest things was that I could embed anything. I could embed Elasticsearch in my web service. Wow! Forget services calling each other! I’ll prototype real quick with everything in one JVM! But that proved impossible! :( It turned out that until Java 9, the JVM has a single namespace…

I think the recommendation is Monolith First

https://martinfowler.com/bliki/MonolithFirst.html

You start with a Monolith and break it out as needed. (i.e. When you find out that is not a good idea to embed Elasticsearch )

You avoid premature boundaries that can become a significant constraint.

Re: The Death of Microservice Madness in 2018

#386

Post by marcosdumay »

ska wrote: post #370
danieltillett wrote: post #299

Earlier quoted context omitted.

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…

> economically irrational

I am not sure that description is apt. Underdelivering is only rational for the painter because the client won't be on the market long enough to gather sufficient information. The client is getting cheated, and it creates a lemons market, the fact that it is a Nash equilibrium does not make avoiding the entire thing irrational.

And the entire thing has parallels on software development...

Re: The Death of Microservice Madness in 2018

#387

Post by corpMaverick »

ChicagoDave wrote: post #186

I've delivered two major applications (400k users, critical internal apps) using micro-services in the cloud reducing cost and increasing continuous delivery capabilities. There are definitely special cases, but overall, after 33 years building software, domain driven design, PaaS, micro-services, and continuous delivery is the most productive paradigm I have ever seen.

How big or small are your micro-services ? how many do you have ? How do you draw the boundaries ?

Re: The Death of Microservice Madness in 2018

#388

Post by [deleted] »

marcosdumay wrote: post #386
ska wrote: post #370

Earlier quoted context omitted.

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…

> economically irrational I am not sure that description is apt. Underdelivering is only rational for the painter because the client won't be on the market long enough to gather sufficient information. The client is getting cheated, and it creates a lemons market, the fact that it is a Nash equilibrium does not make avoiding the entire thing irrational. And the entire thing has parallels on software development...

[deleted]

Re: The Death of Microservice Madness in 2018

#389

Post by ska »

marcosdumay wrote: post #386
ska wrote: post #370

Earlier quoted context omitted.

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…

> economically irrational I am not sure that description is apt. Underdelivering is only rational for the painter because the client won't be on the market long enough to gather sufficient information. The client is getting cheated, and it creates a lemons market, the fact that it is a Nash equilibrium does not make avoiding the entire thing irrational. And the entire thing has parallels on software development...

I meant it in a similar sense to that in which some hobbies are often irrational if you consider them only for market value. I probably could have chosen a better term.

An amateur painter will often spend far more time than any reasonable estimation of the market value of that job would justify. Part of this is lack of efficiency and experience, but another part is doing things with sharply diminishing returns. For example, you might apply expensive techniques to inexpensive materials, in a way that would not make for a viable business.

Put it another way - amateurs can easily arrive at a finished job (of painting, in this case) that they would never be able to convince themselves to pay market rate for. This is irrational in certain restricted senses.

For what it's worth I don't believe that "lemons market" is accurate for painters in general, but I'm guessing there is a segment of it that meets your description.

Re: The Death of Microservice Madness in 2018

#390

Post by corpMaverick »

daxfohl wrote: post #238
rurounijones wrote: post #218

Earlier quoted context omitted.

Usually because they have different usage patterns. Chess API is a daily cycle between 10-1,000 TPS and is CPU intensive. Haiku is uaually 1-10 TPS apart from Fridays (when everyone's device gets a new one) and holidays when it spikes to 100,000 TPS and is IO intensive. Scaling a single service with both these API endpoints being called for different pattens like the above is a pain. Splitting them allows for choosin…

Thanks, and to add to that, it occurred to me that they may have different criticality too. Some services you may want to scale very aggressively because a failure would be catastrophic. Whereas other services may be even more cpu intensive on average but failures are acceptable so you let them run at 90% load. I'd imagine this would be a far more difficult balancing act if they were both in the same process. For exa…

I think your original question is a good one. It must be thoroughly proven and not just taken as gospel.

You may find cases where decoupling a service is a good idea. That doesn't justify decoupling everything by default. The more you decouple the more rigid becomes the whole system.

Post reply on HN