[flagged]
Might want to tweak the prompt a bit
Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
61–70 of 233 posts
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#62Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#63Earlier 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?
> Isn’t that the premise of the question? Does Uber need so many engineers?
The only people who can answer that are employees at Uber.
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#64Earlier 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…
Not OP, but I worked on a large microservices based system at a leading financial institute and when we needed to work on a single service, we had docker compose files that pulled the images needed for the dependency services of that service for us to develop what we needed. They all just ran in our local docker. If we wanted we could have a massive compose file with all services in it, but typically we only needed the iam service and a few other small ones depending on what services we were working on.
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#65Earlier quoted context omitted.
[flagged]
The “in 3 years” was meant as a forward looking statement. The post was being sarcastic that Uber will in 3+ years time claim another victory, based on abandoning the cloud.
Thanks, I also misunderstood "in 3 years" meant forward-looking (i.e. "3 years from now...") rather than backward-looking ("for over 3 years...")
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#66Earlier quoted context omitted.
Uber is a global company (70+ countries) operating Uber and Uber Eats. So almost certainly they are duplicating their entire stack per-country if only to get around the vastly different regulatory environments.
No, that's not correct (mostly). Services are written in the way to support global operations. But that scale introduces a lot of complexity so you can't just have "one service for onboarding drivers"
Do you have knowledge of this?
I find this hard to believe given the regulations from some of the larger countries requiring, by law, customer data be processed in country.
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#67Earlier quoted context omitted.
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 exist…
Part of my point is the goal with such a system is usually to require less infra work/knowledge from your devs, but it backfires if you don’t invest enough in your abstraction. The implicit goal of these abstractions is really to central knowledge and best practices around the underlying tech. Kubernetes itself is trying to free developers from understanding server management, but you could argue it’s not worth using…
> Part of my point is the goal with such a system is usually to require less infra work/knowledge from your devs, but it backfires if you don’t invest enough in your abstraction.
I disagree that the solution is to simply build more. Often the best thing to do is accept that devs will need to know a little infra, and work with that assumption.
> The implicit goal of these abstractions is really to central knowledge and best practices around the underlying tech.
I agree with that.
> Kubernetes itself is trying to free developers from understanding server management, but you could argue it’s not worth using directly vs. just teaching your devs how to manage VMs for the vast majority of organizations.
The difference is that spinning up a VM and setting it up to have all the features you would want from k8s would be too much to ask from a dev. You would probably just end up re-creating k8s.
> I don’t think you’re ever going to stop more and more layers of abstraction, so the best we can hope for is they’re done well. Otherwise you may as well go back to writing raw ethernet frames in assembly on bare metal.
The problem is that abstractions are not free, and most of the time they aren't done well. Once in a while you'll get one that reduces(hides) complexity and becomes an industry standard, making it a no-brainer to adopt, but most of your in-house abstractions are just going to make your life worse.
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#68In 3 years… “Uber saved cost by migrating their micro service to their own colo.” followed by “Uber simplified operations by migrating their micro service platform to a monolith”.
In 5 years... "We've discovered a new paradigm for efficiently carving up and distributing computational units for our application. We call it, nanofunctions."
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#69Earlier quoted context omitted.
No, that's not correct (mostly). Services are written in the way to support global operations. But that scale introduces a lot of complexity so you can't just have "one service for onboarding drivers"
Do you have knowledge of this? I find this hard to believe given the regulations from some of the larger countries requiring, by law, customer data be processed in country.
Deployments != unique codebases.
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#70Earlier quoted context omitted.
My own company has 800+ microservices. I am very familiar with the politics of microservices.
My personal microservice fiefdom is about ten. My company probably has 1000. Is this ratio normal?
Any more than 1 microservice per engineer (as in, 7 microservices for a 7 engineer team) is too much for engineers to handle during on-call incidents.
If management values business SLAs that is.