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

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

segment.com

Post reply on HN
Print view View original

531–540 of 782 posts

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

#531

Post by scruffyherder »

maxxxxx wrote: post #512
mikekchar wrote: post #486

Earlier quoted context omitted.

> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism. The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro…

"From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism." I always tell people if you can't write and maintain a library then don't do microservices.

Yes the kids have just rediscovered the move from COM to DCOM.

It's so silly that we are wasting so much time rebuilding existing things, poorly.

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

#532

Post by akamaozu »

woahthere123 wrote: post #492
akamaozu wrote: post #421

Getting the feeling Segment didn't really stop using microservices. Sounds like they just redrew their service boundary, from Integration APIs to Business Function. Centrifuge sounds like a new service deals with connecting to integration APIs, so they've replaced 140+ services with one. Another service they've spun up is Traffic Recorder, and its responsibility is to eliminate the need for http requests when testing…

Segment is very much built around microservices. They just consolidated 100+ of these destination services into a single one. That's it.

Glad you think so too.

The title and opening paragraphs gave me the impression they felt they were moving away from microservices, but maybe I didn't those bits correctly.

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

#533

Post by aeonsky »

ronjouch wrote: post #526
mikekchar wrote: post #486

Earlier quoted context omitted.

> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism. The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro…

> "should we implement ld.so for micro services? :-)" Working exactly along those lines this week on multiple services exposed over REST APIs, I was wondering if tools exist to check compatibility between them. Said differently, - I have a `swagger.yaml` for my service A managing chipmunks and it says endpoint `/chipmunks` supports an 'color' query parameter. - In service B, I have a `handleToServiceA` that encapsula…

I think this is one of the standard options: https://docs.pact.io

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

#534

Post by eropple »

kapv89 wrote: post #515
eropple wrote: post #282

Earlier quoted context omitted.

The notion that the node.js ecosystem moves way too fast is a time-traveling statement from, like, 2012. When it really was, in a lot of ways, true. But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago. They're also mostly the same tools you would have seen five years ago, and plenty of people use "old" tools…

"SQL database usage is still an ongoing bummer, though." ... have you looked at Typeorm ( http://typeorm.io/ )?

I have, actually. This week has made me decide to move away from it. I have been using it, and filed an issue[0] asking them to document the schemas emitted by their entity-tree code; I was then told that I was doing it wrong and that I should use their code-first/synchronization feature and trust in their magic rather than writing my own explicit migrations which are informed by my (tbh, pretty extensive) understanding of PostgreSQL.

The code seems fine. But I don't really trust anybody who is that insistent on owning the changes made to my database schema--I am certain it is well-intentioned but it makes me itch. Although I will say that there's an interesting project[1] that creates entities from a database that I need to examine further and see if it's worth using to get around TypeORM's unfortunate primary design goals.

[0] - https://github.com/typeorm/typeorm/issues/2453

[1] - https://github.com/Kononnable/typeorm-model-generator

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

#535

Post by luord »

Probably off-topic, even if it's about the article: they should've never relied on doing requests for the tests, specially unit tests.

Isn't the recommended practice to treat third-party services and libraries like a black box? That's what I do, and that's how I figured what their solution was (roughly) before I read it. Felt a bit proud of myself.

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

#536

Post by meesterdude »

wuliwong wrote: post #269
EdSharkey wrote: post #248

Earlier quoted context omitted.

Didn't Rails have all kinds of scaling issues for non-trivial apps and loads?

Twitter had issues with stability but I would say that they were under MUCH heavier than a 'non-trivial' load. I also think that it remains an open question as to whether the old twitter was just simply not well written at first or if it was really a fundamental issue with Rails. There are many very large websites that are claimed to be written in Rails. For example: github, airbnb, kickstarter, basecamp,...These see…

FWIW twitter switched out of rails before some of the huge performance benefits made their way into ruby itself. A rails stack could handle twitter capacity these days, given ruby/rails improvements made since.

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

#537

Post by johndubchak »

acroback wrote: post #179
thelastidiot wrote: post #159

Earlier quoted context omitted.

Amen to that. Just by curiosity, what is the barrier of entry for adding a new language in your ecosystem?

Totally technical considerations which engineers must present and justify. e.g When we added Go, we had to present what it brings? A good testing framework, light weight(subjective), goroutines(which fit our use case), in built benchmark support, mature support of third party packages etc etc.

Out of curiosity, was it replacing an existing language or developing new functionality?

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

#538

Post by johndubchak »

anxiouspete wrote: post #360
YawningAngel wrote: post #331

Earlier quoted context omitted.

Aren't literally all of the above present in Java?

Like the others said, our JVM apps would require at least 1GB for the JVM and then 1-4GB for heap, depending on the service. This made the average JVM service require about 4GB of RAM in the container scheduler. Meanwhile our Go services almost never had a working set larger than 256MB and most didn't even need that. We could schedule on average 16 Go services for each JVM service.

I love the low overhead.

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

#539

Post by codesuki »

mikekchar wrote: post #486
johndubchak wrote: post #235

Earlier quoted context omitted.

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…

> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism. The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro…

> Should shared libraries be in different repos, or should you put everything in a single repo? How do you deal with versioning? What happens if one app wants version 1 of the library and another app wants version 2? How do you deal with backwards compatibility of the API? Do you make a whole new library when you decide the old API is incompatible with the new vision?

Could you share methods that worked well for you? Asking because those question come up a lot and there never seems to be any conclusion.

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

#540

Post by staticassertion »

asdsa5325 wrote: post #504
spraak wrote: post #488

Earlier quoted context omitted.

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

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://stackoverflow.com/questions/3270680/how-does-python-...

Exceptions everywhere, for control flow even - iterators are implemented with exceptions.

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

Speaking of calling out to C... you think you're writing in a memory safe language, but actually, you're writing in a memory safe language that's probably been hollowed out and replaced with a fast C implementation. But it's actually worse

https://hackernoon.com/python-sandbox-escape-via-a-memory-co...

Exploiting C code loaded by Python is like exploiting C code from the 1990s.

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.

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.

I could really just go on and on and on, but at some point it just feels mean.

Huge respect for the project and the team but Python has made mistakes (as all languages do). They were understandable mistakes, but they were mistakes. It's fine for some things, but there's plenty wrong with it, just like there's a ton wrong with javascript. But javascript gets probably 1000x the flack.

Post reply on HN