The Death of Microservice Madness in 2018 • Hacker News Board

Re: The Death of Microservice Madness in 2018

#401

Post by ntrepid8 » Mon, Jan 22, 2018, 4:32 PM UTC

I've often thought that micro-services were more of a software engineering management solution rather than a technical one.

From the perspective of a high-level architect it makes delegating certain types of responsibility a bit easier and potentially reduces the need for communication between teams while maintaining centralized control of the overall system.

However, it always seems to come with such a high overhead that IMHO it's almost never worth doing unless there really isn't another option.

Re: The Death of Microservice Madness in 2018

#402

Post by tabtab » Mon, Jan 22, 2018, 4:49 PM UTC

raspie wrote: post #99

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…

To put it in an even less flattening way, the real problem are developers, not the paradigm. Your company's code will be as good as your developers are regardless of the paradigm. Microservices will not help you if your developers have the same level of skill and foresight as whoever wrote the monolith, which is probably true if those devs were selected by the same hiring process that your company has today, subject…

Re: ...the real problem are developers, not the paradigm. Your company's code will be as good as your developers are regardless of the paradigm.

Indeed! Good developers/architects spot repetition or weaknesses in current techniques and can often devise solutions that can be added to the stack or shop practices with minimal impact. You don't necessarily need paradigm or language overhauls to improve problem-areas spotted. Poor developers/architects will screw up the latest and greatest also.

Re: The Death of Microservice Madness in 2018

#403

Post by logfromblammo » Mon, Jan 22, 2018, 4:57 PM UTC

Jaruzel wrote: post #340

moreless wrote: post #328

Earlier quoted context omitted.

For us non-english speakers - "sheetrock" == drywall. I find I can do most such works better than (average) professionals, but it takes a lot of time to learn, prepare, execute (+ sometimes re-execute) and clean. It all depends on when you are satisfied with the result.

I recently came across 'sheetrock' as a term and had to google it... For UK natives it's actually three steps: "sheetrock" == drywall == Plasterboard

I have also heard it as "gypsum wallboard", which is certainly most descriptive.

I'm not certain whether the water-resistant, mold-resistant variety typically hung behind tiles in bathrooms is ever referred to as "wetwall" or if they still call it "drywall".

Nor am I aware of whether anyone calls the foil-backed, glass-reinforced, fire-resistant variety "firewall" instead of "drywall".

I wouldn't be surprised if obsolete and inapplicable names still attach to items with the same function. If we ever move to polyethylene film panels sandwiched with phase-change material for our walls, it might still be called "plasterboard" somewhere.

Re: The Death of Microservice Madness in 2018

#404

Post by logfromblammo » Mon, Jan 22, 2018, 5:16 PM UTC

madshiva wrote: post #292

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.

A real hacker can fix is car, paint that wall, and can code too. There is no problem painting for me and many others who know how to use their hand. Is amazing when you talk to people and they are like: Did you do that? How do you know how to do that? Learn, try and you can do anything. As people did at every step.

The hardest part is knowing when it is a better use of your time to hire someone else to do it for you.

You can just follow all the same steps as you usually do:

1. Define the problem.

2. Determine the desired outcome.

3. Measure the existing state.

4. Note the foreseeable failure modes.

5. Plot the path from existing state to desired outcome as a series of reasonable steps, avoiding the failure modes.

6. Recursively analyze the steps, breaking them down into smaller steps if necessary.

7. Rework your plan as additional failure modes become evident.

In my experience, yes, you can do anything, as long as you ignore costs. You can't, for instance, justify buying a specialized tool to finish just one job. The hardest part is really step 2.

Re: The Death of Microservice Madness in 2018

#405

Post by cookiecaper » Mon, Jan 22, 2018, 5:16 PM UTC

kbuchanan wrote: post #166

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…

A little over two years ago my little team of three (gasp!) succumbed to the allure of microservices. After six months of writing custom solutions for problems I'd created, I bagged it. The _one_ upside of our microservice architecture was how simple it was to consolidate back into a single app. Only took a couple months. I believe the theoretical benefits of microservices, namely, hard domain boundaries, remain comp…

Props to you for realizing you were going down a bad path and cutting your losses. Many people are unwilling to honestly evaluate their projects until they've been in the rear view mirror for a long time. A great deal of software is driven by ego and fads, and it's great to see someone make a decision to change pace based on practicalities.

Re: The Death of Microservice Madness in 2018

#406

Post by fl0wenol » Mon, Jan 22, 2018, 5:18 PM UTC

moreless wrote: post #328

WalterBright wrote: post #277

Earlier quoted context omitted.

I've tried to hang sheet rock. How hard could it be? It certainly looks easy. A disaster for me, too.

For us non-english speakers - "sheetrock" == drywall. I find I can do most such works better than (average) professionals, but it takes a lot of time to learn, prepare, execute (+ sometimes re-execute) and clean. It all depends on when you are satisfied with the result.

Sheetrock is USG's trade name for a line of drywall products. Sounds like it's going the way of Kleenex, Band-aid, or Hoover.

Re: The Death of Microservice Madness in 2018

#407

Post by [deleted] » Mon, Jan 22, 2018, 5:20 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…

[deleted]

Re: The Death of Microservice Madness in 2018

#408

Post by cookiecaper » Mon, Jan 22, 2018, 5:24 PM UTC

bonesss wrote: post #331

oblio wrote: post #319

Earlier quoted context omitted.

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...

Microservice architectures are a sub-category of SOA. Many of the same reasons to use them apply to both, but with a finer granularity on what is being hosted where and how it is scaling with microservices. Scaling a service with multiple facets going through it gets tricky, hence a desire for a more appropriate modularity. "Placing services in the cloud" kinda papers over why microservices and cloud-native apps hang…

"Message queues, streaming services, specialized DBs, etc" have no intrinsic properties making them "cloud-provider capabilities".

All of these "cloud-provider capabilities" are just normal software that you can run on your own hardware. In one or two cases, the software was first exposed via a particular provider's platform, but similar, and very likely superior software that accomplishes the same goals, is now available for self-hosting (Dynamo -> Cassandra or Riak, for example). That's about as strong as the connection gets.

It doesn't follow that "microservices and cloud-native apps hang together" because the cloud provider charges you a lot of money to access their Redis server, when you could run your own Redis server.

Re: The Death of Microservice Madness in 2018

#409

Post by tyfon » Mon, Jan 22, 2018, 5:24 PM UTC

bigiain wrote: post #216

mauritzio wrote: post #207

Earlier quoted context omitted.

Sounds for me like productivity went down...

I think the complexity of solutions has gone up (especially in webdev), it seems to me perhaps complexity has gone up way further than actual requirements or new features would suggest... Which seems to end up meaning productivity has gone down when measured by "things end users of websites can do", even though modern FE devs end up creating much more code and html and css than "the old days". (Admittedly, if you inc…

"even though modern FE devs end up creating much more code and html and css than "the old days""

And yet, most homepages today can't be viewed without javascript. You are correct, for the end user the complexity has absolutely not resulted in better homepages but worse.

Re: The Death of Microservice Madness in 2018

#410

Post by cookiecaper » Mon, Jan 22, 2018, 5:30 PM UTC

corpMaverick wrote: post #400

stevenmays wrote: post #4

I posted this a few days ago... I wonder why HN didn't keep the original post. https://news.ycombinator.com/item?id=16159589

... and I tried to see comments on it days ago. https://news.ycombinator.com/item?id=16149039 It is strange how no one was interested when previously submitted and sudden it attracts a lot of interest.

Timing is one of the most important parts of getting "hits" on social media, and while it can be optimized for, it's not always controllable. A post may succeed because someone made an attention-getting comment, for example, and that's just the luck of the commenter running across the link when he or she had the time and inclination to leave a note.

Social is fickle that way, and since most social algorithms strongly consider post recency and other time-sensitive factors in their ranking, duplicates should be allowed within a reasonable time frame, because you never know when the critical path will get hit.