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

311–320 of 469 posts

Re: The Death of Microservice Madness in 2018

#311

Post by hueving »

lulmerchant wrote: post #265
manigandham wrote: post #249

There is no such thing as "microservices", it's just services, otherwise known as a service-oriented architecture (SOA). A service is a logical grouping of functionality as it makes sense in your business domain. A small service for a large company can be bigger than the entire product of a startup; there is no standard unit of measure. Computers also don't care how code is deployed and different services can be boun…

"microservice" is certainly a buzzword, but it's not just service-oriented architecture. Mircoservice architecture is modular design, with all the advantages of effectively infinite scale, incredibly flexible orchestration, and the resilience provided by the public cloud providers. It has it's own set of challenges, and it isn't the right solution for every problem. But it can be fantastic when used properly. I've wr…

It has nothing to do with the resilience of cloud providers. If the cloud providers were resilient, then you wouldn't need all of the wonderful scheduling tooling from stuff like kubernetes to deal with unstable individual machines. You can also certainly have a microservice architecture without running anything on the cloud at all.

Microservices make it possible to simply deal with unstable environments. Cattle, not pets.

Re: The Death of Microservice Madness in 2018

#312

Post by danieltillett »

skate22 wrote: post #307
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…

Quality cleaning solution and sand paper so your high quality paint doesnt peel 2 years later.

Yes I agree especially the cleaning part. The kitchen and the rooms close to the kitchen it is critical to clean and clean and clean. The prep should take longer than the painting.

On the sand paper front make sure to spend money there. Cheap sandpaper last 2 nanoseconds and does a terrible job.

Re: The Death of Microservice Madness in 2018

#313

Post by detaro »

acd wrote: post #19
axelfontaine wrote: post #6

Earlier quoted context omitted.

This is the 9th time it's been posted: https://hn.algolia.com/?query=The%20Death%20of%20Microservic...

An improvement to the Hacker news website would be to compute and compare hashes of weblinks so that the same link is not reposted multiple times. Later posters of links could then be redirected to the first post of a link.

It does that, but only if the other submission has been very recently and/or(?) has points over a threshold - otherwise duplicate submissions are explicitly allowed.

Re: The Death of Microservice Madness in 2018

#314

Post by bonesss »

beamatronic wrote: post #141
JamesBarney wrote: post #90

Earlier quoted context omitted.

I really think microservices are a process win not a technical win. It's easier and better to have 5 teams of 10 managing 5 services. Then having one team of 50 managing a one super service. When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain.

What if you expect the team of 7 to grow to 20 or more.. In a larger context almost any company would hire more developers if they could find them and hire them.

Those growth points, and their associated market knowledge and budgetary constraints, would become perfect transition points into a friendlier architecture for the team... Plan for change, moreso than trying to plan against change.

Decomposing and fragmenting an established service into smaller clones of itself should be reasonably straightforward. In most languages with a component story (ie java), library reuse across microservices should make your service architecture orthogonal to your application logic. This kind of approach also eases a lot of pain of cross-service issues.

Re: The Death of Microservice Madness in 2018

#315

Post by SOLAR_FIELDS »

brisance wrote: post #212
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.

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 minutes, but then the leaders would spend the next two hours of the meeting debating about the $100,000 pilot project to help the homeless.

Re: The Death of Microservice Madness in 2018

#316

Post by [deleted] »

zenonu wrote: post #118
JamesBarney wrote: post #90

Earlier quoted context omitted.

I really think microservices are a process win not a technical win. It's easier and better to have 5 teams of 10 managing 5 services. Then having one team of 50 managing a one super service. When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain.

The key to microservices is a framework and tooling around them to make them work for you. Release management, AuthN/AuthZ, compilation, composition, service lookup, etc. should all be "out-of-the-box" before microservices should ever be considered. Otherwise the O(n) gains you get in modularity turn into O(n) FML.

[deleted]

Re: The Death of Microservice Madness in 2018

#317

Post by bonesss »

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.

"Micro" in this case relates to the services scope, not its operational footprint.

So if Netflix has a "User logon" service, and a "payment processing" service, used across their clients clients you might be looking at a couple of "microservice"s with hundreds of related employees. Imagine services for Googles search autocomplete, ML, or analytics...

As the article states the "micro" aspect is mostly in terms of deployment responsibility, freeing those 10-1000 employees from thinking about the totality of Googles/Netflixes' operations before rolling out a patch :)

Re: The Death of Microservice Madness in 2018

#318

Post by majewsky »

paulddraper wrote: post #199
anfedorov wrote: post #111

Earlier quoted context omitted.

That's nothing. I once ran 20 services before breakfast.

Well, my pre-breakfast routine consists of seq 21 | while read port; do python2 -m SimpleHTTPServer 80$port & done

  seq 21 | while read port; do
    python3 -m http.server 80$port &
  done
FTFY

Re: The Death of Microservice Madness in 2018

#319

Post by oblio »

lulmerchant wrote: post #265
manigandham wrote: post #249

There is no such thing as "microservices", it's just services, otherwise known as a service-oriented architecture (SOA). A service is a logical grouping of functionality as it makes sense in your business domain. A small service for a large company can be bigger than the entire product of a startup; there is no standard unit of measure. Computers also don't care how code is deployed and different services can be boun…

"microservice" is certainly a buzzword, but it's not just service-oriented architecture. Mircoservice architecture is modular design, with all the advantages of effectively infinite scale, incredibly flexible orchestration, and the resilience provided by the public cloud providers. It has it's own set of challenges, and it isn't the right solution for every problem. But it can be fantastic when used properly. I've wr…

And how is that not also service oriented architecture? That's also supposed to be modular and one of the reasons for splitting out service is to scale. You can then place those services in a cloud...

Re: The Death of Microservice Madness in 2018

#320

Post by scarface74 »

bigiain wrote: post #211
beamatronic wrote: post #141

Earlier quoted context omitted.

What if you expect the team of 7 to grow to 20 or more.. In a larger context almost any company would hire more developers if they could find them and hire them.

Premature optimisation... YAGNI is almost always the right approach.

I don't think you should always go with a microservice approach first, but you should always separate different domains/features into well defined modules/projects even within a monolith.

There have been plenty of times where I've taken a project out of a monolith and created a separate shippable package to be consumed by another monolith in a separate repo.

There were also occasions where I had to rip out a feature in a monolithic API that either needed to scale independently or be released independently and then just created a facade in the originally API that proxies the "microservice".

Post reply on HN