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

Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos

uber.com

Post reply on HN
Print view View original

81–90 of 233 posts

Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos

#81

Post by eddtries »

x86x87 wrote: post #40
threeseed wrote: post #22

Earlier quoted context omitted.

I've worked on a couple of extremely large micro services projects. And the thing is that nobody ever needs to run the entire stack other than end to end tests which get run in the cloud. You just checkout the services you need and because they are designed to be isolated the dependencies will usually be automatically stubbed out. So it's just a matter of running them or chaining them together if you have a particula…

Question for you: how does performance measurement and optimization work in that environment? Is the key some sort of meta tooling that understands relationships between microservices? How would you express such relationships in the first place? Q2: How do you ensure the stubbed deps behave like the real thing? Q3: how do you handle logging and metrics in an unified way across the stack? And related to this: how do y…

Q2 - techniques like contract testing help here, beyond simple stubs. Also, mocked services maintained by the services original devs you can work against help

Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos

#82

Post by BigJono »

x86x87 wrote: post #46
0xblinq wrote: post #11

Earlier quoted context omitted.

What would be the engineers doing otherwise? You get bored if you don’t.

So we're going to get to the point where everyone gets their own microsevice, right?

That is unironically a better way to do it than anywhere I've worked that does microservices.

My experience with microservice shops is you have one macromonolith with 50 people working on it (which has all the problems of a monolith and none of the benefits), 5 actual decent microservices with a team or individual that properly maintains them, and 100 random utility micro"services" that are like 3 lines of code, used by exactly one other service, and you need 40 loc and a network call to interact with them.

I'll take everyone has their own service any day of the week. At least when I need to interface with 12 different things I can have 12 different people to roast for not properly documenting their API. And tbh literally the only positive I can come up with for microservices is the ability to neatly fire one into the sun and rewrite it from scratch.

Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos

#83

Post by deegles »

baz00 wrote: post #80
mirekrusin wrote: post #71

Earlier quoted context omitted.

Later "Lowering cost and dramatically reducing complexity with nanofunctions running on monoecosystem".

Don't even start on that. It's no longer funny coming up with things like that for me. I'm currently trying to get out of the industry because I'm drowning in architectural bullshit like this constantly. It is pedalled by snakes, bastards and wankers who care nothing for solving problems but want to create new ones.

Ultimately it's promotion-driven development.

Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos

#84

Post by baz00 »

deegles wrote: post #83
baz00 wrote: post #80

Earlier quoted context omitted.

Don't even start on that. It's no longer funny coming up with things like that for me. I'm currently trying to get out of the industry because I'm drowning in architectural bullshit like this constantly. It is pedalled by snakes, bastards and wankers who care nothing for solving problems but want to create new ones.

Ultimately it's promotion-driven development.

Yeah I call it Resume Driven Development.

Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos

#85

Post by fizx »

davidw wrote: post #18
danpalmer wrote: post #5

Earlier quoted context omitted.

A different (better?) question is, does Uber need 4000 API contracts? The answer to that is probably yes. APIs let us split work across systems/people/teams/regions, and provide a way for both sides of a split to work together. Uber has a lot of teams, a lot of engineers, and so it makes sense that there are a lot of API boundaries to allow them to work together more efficiently. Sometimes those APIs make sense to pa…

I wonder what setting up a local dev instance is like for anything involving more than one or two of those.

Something like https://tilt.dev/ where you spin up a subset of the service graph in a cloud environment that hot-reloads based on local edits.

Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos

#86

Post by christkv »

4death4 wrote: post #35
danpalmer wrote: post #5

Earlier quoted context omitted.

A different (better?) question is, does Uber need 4000 API contracts? The answer to that is probably yes. APIs let us split work across systems/people/teams/regions, and provide a way for both sides of a split to work together. Uber has a lot of teams, a lot of engineers, and so it makes sense that there are a lot of API boundaries to allow them to work together more efficiently. Sometimes those APIs make sense to pa…

> Uber has a lot of teams, a lot of engineers, and so it makes sense that there are a lot of API boundaries to allow them to work together more efficiently. Isn’t that the premise of the question? Does Uber need so many engineers?

New unrelated databases, frameworks and queue services don’t write themselves duh

Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos

#89

Post by lhorie »

danpalmer wrote: post #5
x86x87 wrote: post #2

Does Uber really need 4000 microservices?

A different (better?) question is, does Uber need 4000 API contracts? The answer to that is probably yes. APIs let us split work across systems/people/teams/regions, and provide a way for both sides of a split to work together. Uber has a lot of teams, a lot of engineers, and so it makes sense that there are a lot of API boundaries to allow them to work together more efficiently. Sometimes those APIs make sense to pa…

Uber has several different APIs for users. A naive purist might think that's silly until you realize a rider is user, a driver is a user, a courier is a user, a restaurant owner is a user, a line cook is a user, a doctor's secretary is a user, a Uber employee is a user, a freight broker is a user, an advertising manager is a user... people can simultaneously be multiple types of users and have multiple profiles as a single type of user, and did I mention that you have to properly secure PII due to being in a high regulated industry? And that's just users.

Don't even get me started on anything money related :)

Post reply on HN