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

What I Wish I Had Known Before Scaling Uber [video]

youtube.com

Post reply on HN
Print view View original

201–210 of 284 posts

Re: What I Wish I Had Known Before Scaling Uber [video]

#201

Post by threeseed »

yummyfajitas wrote: post #190
threeseed wrote: post #179

Earlier quoted context omitted.

I have no idea why people keep thinking microservices is all about scalability. Almost like they've never worked on a problem with them before. Microservices is all about taking a big problem and breaking it down into smaller components, defining the contracts between the components (which an API is), testing the components in isolation and most importantly deploying and running the components independently. It's the…

You don't need to build a distributed system for that. Just build the ShippingServiceLibrary, let others import the jar file (or whatever) and maintain a stable interface. I wrote about this a couple of years ago in more detail, so I'll just reference that: https://www.chrisstucchio.com/blog/2014/microservices_for_th... HN discussion: https://news.ycombinator.com/item?id=8227721

The point is that unless you use JVM hot reloading (not recommended in Production) you will need to take down your whole app to upgrade that JAR. Now what if your microservice was something minor like a black word filter. Is adding a swear word worthy of a potential outage ?

Re: What I Wish I Had Known Before Scaling Uber [video]

#202

Post by threeseed »

andrewchambers wrote: post #195
yummyfajitas wrote: post #190

Earlier quoted context omitted.

You don't need to build a distributed system for that. Just build the ShippingServiceLibrary, let others import the jar file (or whatever) and maintain a stable interface. I wrote about this a couple of years ago in more detail, so I'll just reference that: https://www.chrisstucchio.com/blog/2014/microservices_for_th... HN discussion: https://news.ycombinator.com/item?id=8227721

I think people don't maintain discipline if it isn't forced. So its a round about way of forcing people to maintain boundaries, that wouldn't be needed much of the time if people had stricter development practices.

Exactly. Every single monolithic application I've seen has a utilities package that has classes shared amongst components.

With micro services you could have different versions of those utilities in use which would not be possible in a monolithic app.

Re: What I Wish I Had Known Before Scaling Uber [video]

#203

Post by duaneb »

rhizome wrote: post #193
duaneb wrote: post #186

Earlier quoted context omitted.

The main benefit of microservices is not performance, it is decoupling concerns. As scale goes up, performance goes down and decoupling gives a better marginal return: it's often easier to work with abstract networking concerns across a system than it is to tease apart often implicit dependenicies in a monolithic deployment. Of course, this is context sensitive and not everyone has easily decouplable code bases, so Y…

a better marginal return: it's often easier to work with abstract networking concerns across a system than it is to tease apart often implicit dependenicies in a monolithic deployment. Do the complexities introduced not have a cost, i.e. are those marginal returns offset by the choice in the first place? Call it "platform debt."

Oh they definitely do. It's just a different flavor and the debt scales differently. Ideally the debt amortizes across the services so you can solve a problem across multiple places. This is obviously really difficult to discuss or analyze without a specific scenario.

It's probably not worth discussing unless you're actively feeling either perf or coupling debt pressure.

Re: What I Wish I Had Known Before Scaling Uber [video]

#204

Post by andy_ppp »

erichocean wrote: post #105
andy_ppp wrote: post #32

Earlier quoted context omitted.

I always wonder in these cases about giving each car an actor in Erlang/Elixir and having complete network transparency, message handling and crashes handled for free. The routing is very complex too but as you note scales well, until you want to start routing/pickups based on the realtime location of other cars.

> having complete network transparency, message handling and crashes handled for free That describes no system, ever, including Erlang. TANSTAFL

Care to explain which bits Erlang/Elixir doesn't do or at least provide a solution for? As the sibling show you may need to be smart about certain things but the OTP definitely provides ways of solving the above things.

Re: What I Wish I Had Known Before Scaling Uber [video]

#205

Post by threeseed »

marcosdumay wrote: post #191
threeseed wrote: post #179

Earlier quoted context omitted.

I have no idea why people keep thinking microservices is all about scalability. Almost like they've never worked on a problem with them before. Microservices is all about taking a big problem and breaking it down into smaller components, defining the contracts between the components (which an API is), testing the components in isolation and most importantly deploying and running the components independently. It's the…

Because what you described is "encapsulation", and microservices is a very heavyweight and expensive way to get it.

Exactly. And we have decades of experience with monolithic apps where encapsulation is not adhered to.

So yes it is heavyweight. But it also works.

Re: What I Wish I Had Known Before Scaling Uber [video]

#206

Post by rer »

threeseed wrote: post #201
yummyfajitas wrote: post #190

Earlier quoted context omitted.

You don't need to build a distributed system for that. Just build the ShippingServiceLibrary, let others import the jar file (or whatever) and maintain a stable interface. I wrote about this a couple of years ago in more detail, so I'll just reference that: https://www.chrisstucchio.com/blog/2014/microservices_for_th... HN discussion: https://news.ycombinator.com/item?id=8227721

The point is that unless you use JVM hot reloading (not recommended in Production) you will need to take down your whole app to upgrade that JAR. Now what if your microservice was something minor like a black word filter. Is adding a swear word worthy of a potential outage ?

Is hot reloading that big of a problem?

Re: What I Wish I Had Known Before Scaling Uber [video]

#207

Post by vkou »

threeseed wrote: post #187
agentultra wrote: post #184

Earlier quoted context omitted.

> I have no idea why people keep thinking microservices is all about scalability. It's an aspect. It's often the beginning of a micro-service migration story in talks I've heard. > Microservices is all about taking a big problem and breaking it down into smaller components ... and putting the network between them. It's all well and good but the tradeoffs are not obvious there either. Most engineers I know who claim t…

You seem to be repeating these weird myths that have no basis in reality. You don't need to be an expert in distributed systems to use microservices. It's literally replacing a function call with an RPC call. That's it. If you want to make tracing easier you tag the user request with an ID and pass it through your API calls or use something like Zipkin. But needing formal verification in order to test your architectu…

> It's literally replacing a function call with an RPC call.

Until you want to make five function calls, in a transactional manner.

Architecting correct transaction semantics in a monolithic application is often much easier then doing so across five microservices.

Re: What I Wish I Had Known Before Scaling Uber [video]

#208

Post by marcosdumay »

taeric wrote: post #134
sah2ed wrote: post #69

Earlier quoted context omitted.

That's just a manifestation of Conway's Law [1]. [1] https://en.wikipedia.org/wiki/Conway's_law

Taken in a healthy organization, Conway's Law is not a bad thing. It is really just more of an observation. So... taken to this example, it sounds like the company is a confusing mess of people trying to figure out who they need to coordinate with to make something happen.

> It is really just more of an observation.

Or maybe some instruction into how to assemble the organization.

Re: What I Wish I Had Known Before Scaling Uber [video]

#209

Post by majormajor »

threeseed wrote: post #182
majormajor wrote: post #156

Earlier quoted context omitted.

Do you think that's it's that people would rather deal with operational complexity, or just that it's easier to not think about operational complexity early on ("running locally, with low volume, everything works together great!")? Personally, I vastly prefer debugging and building on non-microservice architectures than on something split willy-nilly into dozens of services (because most implementations I've seen don…

You seem to be missing the point though. Most developers working on microservices projects don't have to deal with the operational complexity. They just need to work on their microservice and don't have to know what is going on elsewhere. Personally I much prefer microservices for debugging. You can quickly identify which one is the problem then test the APIs in isolation pretty quickly. Sure beats having to wait 20…

So what do these people do when they get data back from one of their dependency services, and it looks wrong? Or a bug is reported that somewhere in the chain, something is being dropped on the floor? You say you can quickly identify which one is the problem, but if that's a chain that spans 5 teams, how does that actually work in practice? (My experience is that it doesn't.)

That's the sort of thing I was including in operational complexity, not just the "are the packets making it through" stuff.

Re: What I Wish I Had Known Before Scaling Uber [video]

#210

Post by dahauns »

threeseed wrote: post #202
andrewchambers wrote: post #195

Earlier quoted context omitted.

I think people don't maintain discipline if it isn't forced. So its a round about way of forcing people to maintain boundaries, that wouldn't be needed much of the time if people had stricter development practices.

Exactly. Every single monolithic application I've seen has a utilities package that has classes shared amongst components. With micro services you could have different versions of those utilities in use which would not be possible in a monolithic app.

> With micro services you could have different versions of those utilities in use which would not be possible in a monolithic app.

You have no idea...:)

Post reply on HN