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

31–40 of 233 posts

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

#31

Post by Nextgrid »

jbotdev wrote: post #23

It seems like they’ve gotten to the “holy grail” of deployment where developers don’t have to worry about infrastructure at all in theory. I’ve seen many teams go for simple/leaky abstractions on top Kubernetes to provide a similar solution, which is tempting because it’s easy and flexible. The problem is then all your devs need to be trained in all the complexities of Kubernetes deployments anyway. Hopefully Uber ab…

The other "leak" in these abstractions that arises from physical limits is performance, especially when it comes to IO.

This is a major problem for databases and ultimately makes database "portability"/fault tolerance tricky since they work best with direct-attach storage that's inherently bound to a single physical machine.

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

#32

Post by plonk »

threeseed wrote: post #22
davidw wrote: post #18

Earlier quoted context omitted.

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

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…

Is there typically a “cold restart” plan to rebuild the whole infra from scratch? I’m thinking of things like circular dependencies when services boot.

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

#33

Post by herval »

talent_deprived wrote: post #19
x86x87 wrote: post #2

Does Uber really need 4000 microservices?

I've seen at least one place with many more than that in recent years. If you have one microservice "listener" per queue and another for the database processing and persistence (business logic) and another providing an API for one or more frontend UI's related to it then the microservice tally goes up very fast. It's kind of surprising to read so many comments indicating HN readers weren't aware of this.

sounds like a massive nightmare

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

#34

Post by mooreds »

nine_zeros wrote: post #3
x86x87 wrote: post #2

Does Uber really need 4000 microservices?

How else would engineers demonstrate "impact" for promotions? /s

I worked at a SV startup (series A) for a while and an EM once mentioned struggling to keep the number of microservices under the number of engineers.

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

#35

Post by 4death4 »

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

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

#37

Post by mattsan »

ilrwbwrkhv wrote: post #30
speedgoose wrote: post #21

Earlier quoted context omitted.

It reminds me this thread about Netflix, with insane amounts of events and logs compared to active users. https://news.ycombinator.com/item?id=30635369

Yup Pornhub serves much more video than Netflix and they do so without that insane amount of complexity.

Honestly Pornhub's stack is genuinely impressive. More start-ups should just use PHP and get shit done

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

#38

Post by zeroCalories »

jbotdev wrote: post #23

It seems like they’ve gotten to the “holy grail” of deployment where developers don’t have to worry about infrastructure at all in theory. I’ve seen many teams go for simple/leaky abstractions on top Kubernetes to provide a similar solution, which is tempting because it’s easy and flexible. The problem is then all your devs need to be trained in all the complexities of Kubernetes deployments anyway. Hopefully Uber ab…

It's not clear to me that being completely unaware of your infrastructure is a good thing. I don't think it's too much trouble to ask an engineer to understand k8s and think about where their service will live, even if it's a ci system that actually deploys. Furthermore, many layers of abstraction, especially in-house abstraction, just mean you have more code to maintain, another system for people to learn, and existing knowledge that you can't leverage anymore.

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

#39

Post by cma »

threeseed wrote: post #22
davidw wrote: post #18

Earlier quoted context omitted.

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

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…

Nobody needs to if they can't possibly.

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

#40

Post by x86x87 »

threeseed wrote: post #22
davidw wrote: post #18

Earlier quoted context omitted.

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

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 you ever get to upgrade services crosscutting concerns that ideally are not invented in every service?

Post reply on HN