What I Wish I Had Known Before Scaling Uber [video] • Hacker News Board

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

#181

Post by [deleted] » Wed, Sep 28, 2016, 8:59 PM UTC

rando832 wrote: post #174

agentultra wrote: post #128

What I Wish Small Startups Had Known Before Implementing A Microservices Architecture: Know your data. Are you serving ~1000 requests per second peak and have room to grow? You're not going to gain much efficiency by introducing engineering complexity, latency, and failure modes. Best case scenario and your business performs better than expected... does that mean you have a theoretical upper bound in 100k rps? Still…

I've never heard the term over-fill data, and google seems to have no idea of it in reference to software.

[deleted]

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

#182

Post by threeseed » Wed, Sep 28, 2016, 9:01 PM UTC

majormajor wrote: post #156

eternalban wrote: post #154

I think these "alarming trends" are highlighting that operational complexity is an easier pill to take than conceptual complexity, for most workers in the field. Microservices address that gap. And in the process the field is transformed from one of software developers to software operators. This generation is witnessing the transfer of the IT crew from the "back office" to the "boiler room".

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 minutes for a monolithic app to build.

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

#183

Post by mstade » Wed, Sep 28, 2016, 9:05 PM UTC

I quite enjoyed watching this. My takeaway isn't so much that this is a critique or endorsement of microservices, but rather just a series of observations. Not even lessons learned in many cases, just honest pragmatic observations. I like how he doesn't seem to judge very much – he obviously has his own opinion of several of these topics, but seem to let that more or less slide in order to not get in the way of these observations.

Good talk, will likely watch again.

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

#184

Post by agentultra » Wed, Sep 28, 2016, 9:13 PM UTC

threeseed wrote: post #179

agentultra wrote: post #128

What I Wish Small Startups Had Known Before Implementing A Microservices Architecture: Know your data. Are you serving ~1000 requests per second peak and have room to grow? You're not going to gain much efficiency by introducing engineering complexity, latency, and failure modes. Best case scenario and your business performs better than expected... does that mean you have a theoretical upper bound in 100k rps? Still…

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…

> 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 to be experts in distributed systems don't even know how to formally model their systems. This is manageable at a certain small scale as some computations take 35 or more steps to reveal themselves. But even the AWS team has realized that this architecture comes with the added burden of complex failure modes[0]. Obscenely complex failure modes that aren't detectable without formal models.

Even the presenter mentioned... why even HTTP? Why not a typed, serialized format on a robust message bus? Even then... race conditions in a highly distributed environment are terrible beasts.

[0] http://research.microsoft.com/en-us/um/people/lamport/tla/am...

You just have to know your data. The architecture comes after... and will change over time.

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

#185

Post by jessaustin » Wed, Sep 28, 2016, 9:13 PM UTC

mLuby wrote: post #146

zaroth wrote: post #18

Earlier quoted context omitted.

It seems like so many "best practices" are really thinly veiled attempts at exploding complexity with only tenuous potential business advantages. We create ourselves so many of the problems we are paid to solve.

"We create ourselves so many of the problems we are paid to solve" Sounds lucrative ;)

It works for doctors and lawyers; why shouldn't software developers try it?

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

#186

Post by duaneb » Wed, Sep 28, 2016, 9:14 PM UTC

agentultra wrote: post #128

What I Wish Small Startups Had Known Before Implementing A Microservices Architecture: Know your data. Are you serving ~1000 requests per second peak and have room to grow? You're not going to gain much efficiency by introducing engineering complexity, latency, and failure modes. Best case scenario and your business performs better than expected... does that mean you have a theoretical upper bound in 100k rps? Still…

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 YMMV. But not recognizing the myriad purposes isn't useful for criticism.

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

#187

Post by threeseed » Wed, Sep 28, 2016, 9:28 PM UTC

agentultra wrote: post #184

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…

> 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 architecture ? Bizarre. And I've worked on 2 of the world's top 5 ecommerce sites which both use microservices.

And HTTP is used for many reasons namely that it is easy to inspect over the wire, is fully supported by all firewalls and API gateways e.g. Apigee. And nothing is stopping you using a typed, serialized format over HTTP. Likewise nothing is stopping you using an message bus with a microservices architecture.

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

#188

Post by [deleted] » Wed, Sep 28, 2016, 9:29 PM UTC

dastbe wrote: post #90

jrochkind1 wrote: post #85

Earlier quoted context omitted.

that sounds nightmarish

Why? I'm assuming their highish engineer/service ratio is because their services do less individually. Anecdotally, I've worked on services that ran tens of thousands of instances across the world. You build the tools to manage them and it works very well.

[deleted]

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

#189

Post by sokoloff » Wed, Sep 28, 2016, 9:37 PM UTC

agentultra wrote: post #184

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…

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

> [Scalability i]s an aspect. It's often the beginning of a micro-service migration story in talks I've heard.

It absolutely helps with people and org scalability. I haven't seen it help with technical load scalability (assuming you were already doing monolithic development relatively "right"; we ran a >$1BB company for the overwhelming majority on a single SQL server).

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

#190

Post by yummyfajitas » Wed, Sep 28, 2016, 9:46 PM UTC

threeseed wrote: post #179

agentultra wrote: post #128

What I Wish Small Startups Had Known Before Implementing A Microservices Architecture: Know your data. Are you serving ~1000 requests per second peak and have room to grow? You're not going to gain much efficiency by introducing engineering complexity, latency, and failure modes. Best case scenario and your business performs better than expected... does that mean you have a theoretical upper bound in 100k rps? Still…

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