Goodbye Microservices: From 100s of problem children to 1 superstar • Hacker News Board

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#51

Post by mockingbirdy » Tue, Jul 10, 2018, 5:30 PM UTC

pythonaut_16 wrote: post #35

tracer4201 wrote: post #29

Too many smart folks that I've worked with, for some reason, just stop thinking critically when it comes to certain ideas. I was a product manager on a team of really rockstar developers. They all earn at least $200k a year. Instead of demanding more ambitious projects, you could keep about 99% of them happy by just letting them use the new framework of the week to build their next web app. Their excitement when they…

Sounds like you really don't understand development if you think getting to use React isn't a big deal. React (and others like it, e.g. Vue) really is a huge win and solves a ton of pain points common to front end development. It still has its own pain points, but it's hard to overstate how much of an improvement it is over other older approaches like jQuery.

I think he doesn't have a problem with that.

> Building another dumb website with the new framework, yay.

He's just astonished how excited they are although what they build is "another dumb website" in his opinion. Many developers love the "how?" and don't care about the "why?". I don't judge it, but it can explain some of the excitement. Angular, React and Vue are great for development. But Ember, Backbone and others were also good back in their times. What he essentially says is "We use specific technology so they get excited although the problems we solve are boring af"

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#52

Post by hinkley » Tue, Jul 10, 2018, 5:30 PM UTC

SE4L wrote: post #41

Seems to me the problem is the shared libraries. Yes, without sharing it means you have to repeat a fair amount of code, but in most cases the representation that each service cares about is not necessarily the same, which reduces the value of these shared libraries. It seems that they would have solved a lot of the really critical issues by simply not sharing as much code.

I maintained the shared library for five teams trying to move data around.

The biggest challenge is making the shared library forward and backward compatible with itself for at least a few releases in either direction, because not everyone will redeploy at the exact same moment.

If you can't solve that problem everything gets painful. Doing that right was the second hardest part of that job (meetings were the hardest). The job title (securing the data interchange) came in third place.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#53

Post by techinformed56 » Tue, Jul 10, 2018, 5:32 PM UTC

alexrbarlow wrote: post #2

I'm not sure what they've been left with is a monolith after all. I would say they just have a new service, which is the size of what they should have originally attempted before splitting. In particular, as to their original problem, the shared library seems to be the main source of pain and that isn't technically solved by a monolith, along with not following the basic rule of services "put together first, split la…

+1

I felt this article is more about how to use microservices right way vs butchering the idea. It is not right to characterize this as microservices vs monolith service. Initial version of their attempt went too far by spinning up a service for each destination. This is taking microservices to extreme which caused organizational and maintenance issue once number of destinations increased. I am surprised they did not foresee this.

The final solution is also microservice architecture with a better separation of concerns/functionalities. One service for managing in bound queue of events and other service for interacting with all destinations.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#54

Post by aniketpant » Tue, Jul 10, 2018, 5:32 PM UTC

I probably don't understand their architecture well enough since they don't try and explain it in detail. The blame is also put on microservices whereas it's the architecture that can be fixed to improve performance and the cost of deployment.

A shared library works up until a certain point. If every service uses a shared library then you are already getting to a world of a monorepo. A monorepo for different services should work fine if the overall architecture is feasible.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#55

Post by cortesoft » Tue, Jul 10, 2018, 5:32 PM UTC

the_arun wrote: post #30

Micro Services solve for logical smaller teams, speed, deployment isolation & ton of other problems. Every solution comes with a trade off. There is no perfect solution. It is up to us to decide whether we need a monolith or micro service for our need & use case instead of comparing them.

Not only that, but there is a lot of room between a 'monolith' and 'micro services'. How about medium services? You break somethings up and leave other things combined.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#56

Post by nodesocket » Tue, Jul 10, 2018, 5:32 PM UTC

thermodynthrway wrote: post #3

I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…

I generally agree that for the vast majority of web applications KiiS holds true and use monolith.

In terms of the common code divergence why not just use private NPM and enforce latest? Have a hard-fast rule that all services must always use the latest version of common.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#57

Post by cirgue » Tue, Jul 10, 2018, 5:33 PM UTC

ascendantlogic wrote: post #34

What's old is new again. The inevitable rewinding of the 2012 architecture "revolution" starts now. I look forward to people in 2026 saying "monoliths are bad, split everything out to services"

"You may not be interested in the dialectic, but the dialectic is interested in you."

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#58

Post by jacquesm » Tue, Jul 10, 2018, 5:33 PM UTC

badasstronaut wrote: post #22

Personally, I don’t like the terms ‘microservices’ or ‘nanoservices.’ What’s the value add in describing the relative size of the service? The _domain_ should drive what becomes its own service. Every service should handle the business logic within a particular domain. It’s definitely a goldilocks problem, though, in that there’s a too-small and too-large, and we’re looking for the just-right fit!

That's exactly it. But when you start doing 'microservices' you get the architecture astronauts who go and see into how many silly little services a monolith can be broken up. The end results are as predictable as the original monolith, both end up as an unmaintainable mess in a couple of years.

I predict the same will happen to the 'superstar', it just isn't old enough yet (and at least it was built with some badly needed domain knowledge).

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#59

Post by thinkmassive » Tue, Jul 10, 2018, 5:33 PM UTC

dualogy wrote: post #17

thermodynthrway wrote: post #3

I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…

"Need to" and "sane" are among my favourite subjective terms! (Further below, I'll go into in which contexts I'd agree with your assessment and why. But for now the other side of the coin.) In the real world, current-day, why do many enterprises and IT departments and SME shops go for µservice designs, even though they're not multimillion-user-scale? Not for Google/Netflix/Facebook scale, not (primarily/openly) for h…

These are great observations. For anyone interested in going more in depth on the topic, I highly recommend the book Building Evolutionary Architectures

https://www.goodreads.com/book/show/36308520-building-evolut...

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#60

Post by spyspy » Tue, Jul 10, 2018, 5:33 PM UTC

> While our systems would automatically scale in response to increased load, the sudden increase in queue depth would outpace our ability to scale up, resulting in delays for the newest events.

This strikes me as the core of their problem, and every step taken was a way to bandaid this limitation. Would the cost of moving to faster-scaling infrastructure been so high as rearchitecting the entire system?

> When we wanted to deploy a change, we had to spend time fixing the broken test even if the changes had nothing to do with the initial change.

This seems like a separate and even larger problem. Changes are breaking tests for unrelated code areas? Is the code too tightly coupled? Sounds like it. The unit tests are doing exactly what they're designed to do. Hard to feel sympathy for the person who's breaking them and then trying to figure out a way to sidestep them rather than fix the underlying issues.