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

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

#541

Post by JonasJSchreiber » Wed, Jul 11, 2018, 3:05 AM UTC

johndubchak wrote: post #235

ljm wrote: post #157

Earlier quoted context omitted.

I'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech, so less mature teams can silo themselves off and avoid communication (e.g. "I can work just on my backend image processing bit without dealing with the React guys now", "now the CTO won't be on my back so much," or whatever). The irony being that anything approaching SOA (or micro…

I think what was missed, in the article, is that the fundamental problem was centered around a shared architecture of destinations and shared code. You cannot possibly have every destination be a separate repo and then have the development lifecycle of your shared code be so active that it ultimately puts at risk the architecture of your entire organization. What makes shared code so perfect is having stability such…

Yes, couldn't agree more. The O in SOLID should be adhered to in this case. Open for extension, closed for modification

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

#542

Post by agentultra » Wed, Jul 11, 2018, 3:07 AM UTC

crimsonalucard wrote: post #514

wsy wrote: post #366

Earlier quoted context omitted.

It's a bit like asking to replace medical doctors with science and theory. We need science and theory, and skilled architects who can apply it to the problem at hand.

The practices of Doctors are based off of science and theory. Design patterns and microservices while technical are not based off of science. They are ideas without quantitiative basis or science.

Model checking is based off of mathematics and can be verified or, with some elbow grease, proven.

I'll take a TLA+ specification over a diagram any day.

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

#543

Post by spyspy » Wed, Jul 11, 2018, 3:08 AM UTC

dasil003 wrote: post #296

spyspy wrote: post #60

> 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 wan…

The job of these services is to transform their internal event format to 140 different output formats. You can imagine that there is a lot of duplication in the functionality that these services need to do. Are you suggesting that they avoid any shared libraries and just rewrite the same code over and over hundreds of times and update them independently?

If making a change to a shared library breaks half the services, should it have been shared in the first place? It still smells odd to me there’s so much interdependence amongst the individual services break at will.

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

#544

Post by stcredzero » Wed, Jul 11, 2018, 3:11 AM UTC

marcosdumay wrote: post #404

stcredzero wrote: post #298

Earlier quoted context omitted.

"But if he was shocked, he wouldn't bother to keep typing!" "Maybe he was taking dictation?!"

Nah... This one was clearly paralized while pressing a key. His browser must auto-post HN comments after a short while.

With the last sentence, we now award the best hypothesis to dictation.

https://www.youtube.com/watch?v=LJfowXTXOfU

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

#545

Post by neuromantik8086 » Wed, Jul 11, 2018, 3:16 AM UTC

stickfigure wrote: post #457

madamelic wrote: post #163

Earlier quoted context omitted.

>It's worse than that; it's my observation that most microservice architectures just ignore consistency altogether ("we don't need no stinking transactions!") and blindly follow the happy path. If two microservices have to share databases, they shouldn't be microservices. One microservice should have write access to one database and preferably, all read requests run through that microservice for exactly the reason yo…

My problem with microservices is the word 'micro'. It should just be services . Problem domains (along with organizational structures) inherently create natural architectural boundaries... certain bits of data, computation, transactional logic, and programming skill just naturally "clump" together. Micro services ignore this natural order. The main driving architectural principle seems to be "I'm having trouble with…

It took me longer than it probably should have to realize that the term microservices was made by analogy to the term microkernel. I think that part of my main issue with the "microservices" is that it conflates highly technical semantics with word forms that are a bit more wishy washy in meaning (i.e., a service is something formed more of human perception, not rooted directly in operating system abstractions).

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

#546

Post by sequoia » Wed, Jul 11, 2018, 3:18 AM UTC

It seems like their initial problems were:

1. Tests hitting 3rd party APIs are flakey & slow 2. The job queuing mechanism can cause all jobs to be slowed by a single 3rd party API outage/slowdown

Eventually they arrived at:

1. Replay responses to speed up HTTP based tests 2. Create a smarter queuing mechanism in house

I'm not sure what microservices has to do with any of this. Anyway, kudos to them for having the courage openness to share their learning from mistakes!

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

#547

Post by jdoliner » Wed, Jul 11, 2018, 3:18 AM UTC

jiveturkey wrote: post #376

acroback wrote: post #123

This is a classic case of not understanding micro services and trying to fit a problem around a tool. At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco/ , all Java services go under jumanji/ , all go services go under goat/ , all JS services go under js/. This means, ever…

> This means, everytime you touch something under a repo, it affects everyone. This is horrible at scale. > This is a classic case of not understanding micro services and trying to fit a problem around a tool. That much I agree with. TFA even acknowledges that, in the conclusion. Not in so many words, but they basically admit they did it wrong.

> This is horrible at scale.

This can work fine at scale, Google does it with however many tens of thousands of engineers they have these days. Having everything in a monorepo doesn't solve the communication problem, it doesn't prevent solving it either.

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

#548

Post by weberc2 » Wed, Jul 11, 2018, 3:20 AM UTC

spraak wrote: post #488

asdsa5325 wrote: post #293

Earlier quoted context omitted.

badlanguage/ is too long

Such a tired view/joke. Python is just as bad but doesn't receive nearly as much hate

I'm a Python guy, but there are lots of things about JS that make me jealous. For example, the main implementations are quite fast, and the tooling is good. In Python, there is Pypy which doesn't get enough investment, or CPython where your only optimization lever is "rewrite it in C!". TypeScript also seems quite a lot nicer/less-broken than Python's mypy. Lastly, I like that JS has actual, multi-expression lambdas and a pleasant syntax.

Some things are more pleasant in Python--everything is sync by default, there's less churn, the standard library gets me a lot farther, it's less permissive (no 'undefined is not a function' nor '!= vs !=='), etc. Both languages serve similar niches well, but the feeling I get is that JS is quite a bit faster and nicer for IO-heavy workloads (JS just has a more mature async story than Python) while Python is generally more intuitive and perhaps better for general application development. But for most things, one isn't dramatically better than the other, and they're both a good deal more disappointing than Go. :p

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

#549

Post by User23 » Wed, Jul 11, 2018, 3:32 AM UTC

briandear wrote: post #86

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…

Teams have a lot to do with microservice use. If you have a small team a monolith can work well. If you have a large team, microservices have some significant advantages. And in some cases, you might have a microservice in Swift when you need high performance, but other less intensive services might be in Ruby or some other language, etc. Right took for the job should be the goal as opposed to chasing fashion. Micros…

> Imagine the complexity of Amazon.com or Netflix were a monolith.

That was called Obidos and it's shortcomings were why Jeff pushed through the services mandate at Amazon.

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

#550

Post by weberc2 » Wed, Jul 11, 2018, 3:33 AM UTC

staticassertion wrote: post #540

asdsa5325 wrote: post #504

Earlier quoted context omitted.

I'd like to hear why you think Python is as bad

2 or 3? Or all of the problems that come with choosing between the two (no, it is still not an easy choice). Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely unhelpful, etc. Slow. Plenty of 'wat' like mistakes: https…

> no, it is still not an easy choice

Yeah it is, choose 3. Python 2 is reaching EOL.

> Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely helpful, etc.

Yeah, the typing stuff is a pretty big disappointment. The ergonomics are pretty terrible (probably because they wanted to push as far as they could without introducing more syntax support for typing). Mypy isn't just young, but it's buggy and its codebase was a sloppy mess last I checked. There's no support for recursive types (you can't define a JSON type, for example). And it absolutely falls over in the face of common libraries, like SQLAlchemy, which are too dynamic for it.

> Absolutely AOT unoptimizable. Pypy's cool, never got it working for my use case. In theory a JIT could help.

Yeah, Pypy is the best hope for Python's performance. They're making great progress, but I also couldn't get it working in our Python 3 codebase (Numpy and Pandas installation issues).

> No parallelism. Multiprocessing? Good luck with that - pay the cost of pickling, pay the cost of an additional interpreter, pay the cost of debugging hell.

Yeah, this is a real pain point. Some die-hard Python folks say otherwise, but there's really no good parallelism option for lots of workloads. Pickling is just too expensive.

> An ecosystem split in two, and don't let anyone tell you otherwise - a few hundred top packages moving over after many, many years, is a sad state for a language that was known for having an absurdly large ecosystem.

This hasn't been a problem for me for years. Most things that have seen active development in the last 5 years have good Python 3 support. The only time I've run into a Python-2 only utility, it was 7 years stale. Well, except for Centos's `yum`.

These are all reasons I like Go, by the way. Super fast, great tooling, and fairly stable (except for the package management story). I do wish there was a lightweight scripting language with a great VM and real parallelism--something like JS without the inheritance, OO baggage, etc; just objects and arrays and functions running on a JIT VM like V8 but with parallelism as a first-class citizen a la BEAM. And preferably optionally typed from the start, in a way that the runtime could leverage for optimization purposes.