In 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”.
[deleted]
Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
141–150 of 233 posts
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#142Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#143Earlier quoted context omitted.
It’s been happening since the dawn of time, fat client/thin client, static link/dynamic link, micro services/monolith, centralised/decentralised, it doesn’t just migrate from one to the other, the pendulum swings back and forwards, and will do for eternity. You can be all angry about it, but being angry at the storm doesn’t affect the storm, it only affects you. A lot. Negatively. The trick is to position yourself to…
> The trick is to position yourself to maximally profit from the next trend swing, I’ve been doing it for 20 years now, if you can predict where the next place is gold will fall from the sky, then go and stand there, with a really big bucket. Where the pendulum will be in 2030? Asking for a friend :D
I'm out of the market then so I'll drop what I think will be the situation:
Put everything on: cost savings, energy reduction, privacy, death of advertising.
Cost savings -> inefficient languages and architectures will die because the main datacentre currency is going to be performance/watt and that's going to cost serious money when transport infra is contending with DC power consumption. Things which are compiled and not interpreted will have a cost benefit then. Rust/C# (with AOT)/Go etc. Half these bloated piles of shit with expensive build toolchains will die too.
Energy reduction -> linked with above, energy usage reduction is going to be a big one. That means reducing workforce, simplification and efficiency are going to be key drivers. This may kill some ML approaches off that consume a lot of energy. So ARM etc.
Privacy -> Confidence in surveillance states and the cloud is declining so privacy first oriented services are going to have a huge uptick. Apple / standalone systems / new opportunities.
Death of advertising -> advertising is in the death throes with AI coming in as it decreased the signal-to-noise ratio. It becomes less effective so discovery rather than promotion will be the way to get attention for your product. Portals / landing pages / software catalogues.
Me I'd concentrate on cloud cost management and code efficiency and business efficiency as key areas to invest my time in.
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#144Earlier quoted context omitted.
Yeah I call it Resume Driven Development.
Exactly. "What's Kubernetes FOR ?" "To the best I can tell, it's a jobs program for our industry."
Kubernetes is great for the problems it is designed for. It's fucking terrible for the other 99%.
Source: juggle lots of clusters full of things that shouldn't be in Kubernetes.
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#145Does Uber really need 4000 microservices?
There's an an interesting HN comment[1] from 2020 by former Uber engineer, which discusses the complexity a bit. It's more about UI, but the thread discusses the backend as well. In brief something that may look super simple for the user (like handling payments) is actually quite complicated when you cover all the market, different payment types etc. And all this carries to the backend as well. [1] https://news.ycomb…
Do all of those need to be microservices or you could you instead have one monolithic payment service that handled all those use cases?
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#146> The team used existing tooling to move services between zones in order to ensure they were portable. Firstly, they allowed services to be moved back to the original zone to resolve any portability issues, but once resolved, services would be moved periodically to validate portability and prevent regressions.
This is something that most companies don’t do when they say they want to do $x to “prevent lock in”.
Uber actually is testing for portability along the way.
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#147Does Uber really need 4000 microservices?
There's an an interesting HN comment[1] from 2020 by former Uber engineer, which discusses the complexity a bit. It's more about UI, but the thread discusses the backend as well. In brief something that may look super simple for the user (like handling payments) is actually quite complicated when you cover all the market, different payment types etc. And all this carries to the backend as well. [1] https://news.ycomb…
And also certain states and localities have different requirements for ride share. I noticed this in NYC and Seattle
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#148Earlier quoted context omitted.
There's an an interesting HN comment[1] from 2020 by former Uber engineer, which discusses the complexity a bit. It's more about UI, but the thread discusses the backend as well. In brief something that may look super simple for the user (like handling payments) is actually quite complicated when you cover all the market, different payment types etc. And all this carries to the backend as well. [1] https://news.ycomb…
Do all of those need to be microservices or you could you instead have one monolithic payment service that handled all those use cases?
And then every time you had a change, you would have to deploy everything and your surface of failure is greater.
What would a monolith buy you?
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#149Does Uber really need 4000 microservices?
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 I remember that. Netflix seems to be the poster child for overengineered architecture - for something that is almost entirely commoditised nowadays (one-way over the internet video streaming).
Uber's problem space is significantly more complex than Netflix, so I'm unsure it's a fair comparison. But they do seem to have quite a lot of overengineering going on. At least that's how I feel each time I read an Uber tech article.
About the only companies which seem to justify their complex architectures are Google/Meta/Amazon imo.
Re: Uber migrates microservices to multi-cloud platform running Kubernetes and Mesos
#150Earlier quoted context omitted.
In general in a micro service environment, you try to build things so that 1) you don't need to run other things locally, and 2) if you did need to, the services are just containers so it's pretty easy to run one. But you tend to try to write your service so that it treats everything else it depends on like a vendor-provided API. Like, if you were building a Slack bot, you wouldn't ask Slack to let you pull down and…
We're not big on microservices, but we do integrate with a lot of other systems. I find the opaqueness of other services to reduce development speed quite drastically. With local code I can view both sides of the fence and easily see if I'm using it wrong or if it's a bug in my colleagues code. Seems that if you're constantly developing against opaque services you'd end up in the same quagmire quite quickly?
You shouldn’t care about anything outside of published contracts for dependencies. You’re slwags dependent on underlying APIs