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

261–270 of 284 posts

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

#261

Post by _asummers »

ci5er wrote: post #258
_asummers wrote: post #257

Earlier quoted context omitted.

You should check out what the Elixir folks are doing with Ecto. I'm a huge fan so far!

Thanks for the pointer. I'm already using BEAM in a project, so that wouldn't be a bridge too far for that one...

Conceptually, everything is a Schema and then you generate Changesets for DB operations like insert, update, etc. and apply various validations and transformations as a chain of function calls on the input map. No such thing as a model anymore. It fits really nicely with a data > functions mindset.

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

#262

Post by ci5er »

_asummers wrote: post #261
ci5er wrote: post #258

Earlier quoted context omitted.

Thanks for the pointer. I'm already using BEAM in a project, so that wouldn't be a bridge too far for that one...

Conceptually, everything is a Schema and then you generate Changesets for DB operations like insert, update, etc. and apply various validations and transformations as a chain of function calls on the input map. No such thing as a model anymore. It fits really nicely with a data > functions mindset.

> It fits really nicely with a data > functions mindset.

That will probably confuse my procedural mind, much like declarative "stuff" often does! :-)

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

#263

Post by nine_k »

lnanek2 wrote: post #121
mtrpcic wrote: post #110

Earlier quoted context omitted.

Could you give some information as to what the breakdown of functionality is for those services? I can't fathom 1700 different and unique pieces of functionality that would need to be their own services.

I work at a microservice company. An example microservice is our geoservice which simply takes a lat/lon and tells you what service region the user is in (e.g. New York, San Francisco, etc..). You can see how dozens of these services might be needed when handling a single request coming in from the front end or mobile apps. The service may eventually gain another related function or two as we work on tearing down our…

It looks that for functions as simple as that the RPC overhead should be pretty small, or it will eclipse the time / resources spent by the actual business logic.

E.g. I can't think of a REST service doing this; something like a direct socket connection (over a HA / load-balancing level) with a zero-copy serialization format like Cap'nProto might work.

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

#264

Post by borlum »

taf2 wrote: post #94
gtrubetskoy wrote: post #57

I think the world of service architecture is roughly divided in two camps: (1) people who still naively think that Rest/JSON is cool and schemas and databases should be flexible and "NoSQL" is nice and (2) people who (having gone through pains of (1)) realized that strong schemas, things like Thrift, Protobufs, Avro are a good thing, as is SQL and relational databases, because rigid is good. (Camp 1 is more likely to…

the short summary of what you describe is... 1. new business evolving quickly to meet and discover the product that fits the market they are chasing. 2. established and optimizing for a possibly still growing market but very well established set of features and use cases. They can take longer to deliver new features and can save lots of money by optimizing.

Spot on

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

#265

Post by nine_k »

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 ?

If you run multiple instances of your server and follow certain reasonable practices, you can take down old-version instances one by one and replace them with new-version instances, until you have upgraded the entire fleet.

Alternatively, you can deploy the new version to many machines, test it, then make your load balancer direct the new traffic to the new instances, until all old instances are idle, and then take down these.

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

#266

Post by aurelianito »

dozzie wrote: post #253
the_other wrote: post #251

Earlier quoted context omitted.

Isn't that just "Ops"?

My point exactly.

Yes, but now we actually try to automate in a systematic way; as opposed to a single admin hacking some custom shell scripts. That's what the dev in devop mean. And that's new, at least it was not a common activity in the XX century.

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

#267

Post by marcosdumay »

threeseed wrote: post #205
marcosdumay wrote: post #191

Earlier quoted context omitted.

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.

Well, granted. It will take decades for we to have decades of experience with microservices that break clear encapsulation.

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

#268

Post by bch »

s_kilk wrote: post #241
bch wrote: post #161

Earlier quoted context omitted.

It's not a simulation, it's real-world production technology. https://en.wikipedia.org/wiki/Technical_details_of_Netflix

I think they meant that Netflix Chaos Monkey is a "simulation" of the real-deal, which is sending a shaved-ape into a physical server room and pulling out physical network cables. I didn't read it as derogatory.

Oh perhaps they did mean shaved-ape simulator. I read none of it as derogatory, and hopefully my response didn't suggest otherwise.

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

#269

Post by dozzie »

aurelianito wrote: post #266
dozzie wrote: post #253

Earlier quoted context omitted.

My point exactly.

Yes, but now we actually try to automate in a systematic way; as opposed to a single admin hacking some custom shell scripts. That's what the dev in devop mean. And that's new, at least it was not a common activity in the XX century.

If by "systematic way" you mean a group of programmers clueless about system administration hacking together some custom Ansible scripts, then I wouldn't call it progress.

Sysadmins have tools to automate their work for a long, long time (cfengine, bcfg2, even Puppet and Chef predates DevOps hype). DevOps didn't bring anything new to the table.

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

#270

Post by iamleppert »

willejs wrote: post #245
iamleppert wrote: post #230

It amazes me they have 1,700 services. It would be hilarious satire to actually see the description of each. And the debugging scenarios he listed make it sound like they have very poor engineers working for them. Who on earth lets an application get to prod that iterates through a list of items and makes a request for each thing? When did we loose our heads and think such an architecture is sane? The UNIX philosophy…

Saying something like '...they have very poor engineers working for them.' is pretty unfounded, and naive. It's easy to say that having 1700 services is overkill from our point of view, but we don't know the complete architecture, problems being solved and environment that they operate in. One thing to possibly consider is that once you have set up tooling for a platform; logging, request tracing, alerting, orchestra…

This wasn't a derivation from the repo count, it was in response to the debug part of the talk where he was talking about fan out. Some app was iterating through a list of things and for each thing was making a network request, instead of figuring out what it needed up front. It's either complete laziness or incompetence, probably the later. I assume with any company that has that many services their culture is partly to blame, too.

It's interesting because this kind of technical debt will eventually open the door to competitors once Uber is under more financial pressure...i.e. they have burned through all the investor money.

Post reply on HN