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

Lyft Files S-1

sec.gov

Post reply on HN
Print view View original

361–370 of 405 posts

Re: Lyft Files S-1

#361

Post by bm1362 »

throwaway-1283 wrote: post #231
icedchai wrote: post #203

Earlier quoted context omitted.

The public will eat this stuff up if there's huge YoY revenue growth like they've shown in the S1. You see this all the time with public SaaS companies. Sure, the losses also increase... but nobody seems to care.

Nobody seems to care...until the company literally runs out of money. The difference between a SaaS and a Lyft is that Lyft has huge operating expenses. Burn rate is order of magnitude higher.

The expenses are mostly in marketing to grow their market share- they won't market themselves into the grave.

Re: Lyft Files S-1

#362

Post by ericd »

spookthesunset wrote: post #278
ericd wrote: post #274

Earlier quoted context omitted.

We ran our own at a significantly smaller scale, it didn't take us nearly as much time to maintain as it saved us in terms of money over cloud.

I promise you weren't actually doing your costing correctly to arrive at that conclusion. Engineers always badly mis-underestimate the costs of things and "rack & stack data center management" is way more costly than you are actually accounting for. Especially in terms of opportunity cost and, well, just wasted resources that aren't actually adding value to the company. There is way, way, way, way, way more to a runn…

The savings enabled us to hire more people than it took to run. After the upfront setup (Xen and Ansible), it was pretty painless, had much of the same flexibility as cloud options, and better performance. For bulk storage, we used S3.

So basically, I disagree. These aren't estimates.

Re: Lyft Files S-1

#363

Post by chillacy »

spookthesunset wrote: post #281
djsumdog wrote: post #146

Earlier quoted context omitted.

The trouble is when people build around Amazon, they get locked into a lot of those services. Sure you can run your own DBs instead of using RDS, but what if you start using their proprietary rubbish, like Knesis or DynamoDB? You have to rewrite application to use something else that's open source and self-hostable. For new startups, I honestly recommend using DigitalOcean or Vultur. You don't get all the AWS compone…

> The trouble is when people build around Amazon, they get locked into a lot of those services. The trouble when people build things that have nothing to do with their core value propositions, they get locked into those services too. It is very easy for companies to get locked into their own homebrew garbage frameworks, clustering solutions, reporting & data analysis apps, or whatever else people hacked up because "o…

Seriously, I hear the same argument with frameworks too. At the end of the day it isn’t a choice between framework A and no framework, it’s going to be a framework A and your custom baked framework, and do you really have the time to spend reinventing the wheel?

Re: Lyft Files S-1

#364

Post by kerng »

mrep wrote: post #320
kerng wrote: post #249

Earlier quoted context omitted.

The idea to use hosting is much older. Many companies offered services like that even in the 90s with AWS it really scaled up and the quality for hosting then improved across the globe.

Did they offer services like RDS, S3, SNS, SQS, Autoscaling, Route 53, load balancing... because those are what make AWS so valuable.

SQL and Domain Names was very common even in the 90s. The other concepts hadn't really evolved. Even AWS only had EC2 and S3 in the beginning. I'm just trying to relate and point out that Google decided to self host, rather then depend on someone else - which for a business that exponentialy grows is the best way, even today.

Re: Lyft Files S-1

#365

Post by TheOperator »

halbritt wrote: post #172
doctorpangloss wrote: post #157

Earlier quoted context omitted.

> If those issues aren't in your company's core competencies, it's not necessarily efficient to invest in building out all of that. Maybe that's just the story cloud providers tell you. Until you try, do you really know if it's all that complicated? People have been running datacenters for a long time, and not all of them work for Amazon. But there may be also a beneficial side effect of having gearheads around, and…

Having done a bunch of bare metal, I can tell you the calculus isn't really that hard. Bare metal will save you money. Operating bare metal at scale requires talent that doesn't exist, not necessarily at an engineering level, but at all levels. As an example, I worked at a place that had a large bare metal deployment, i.e. >1MW worth of compute. It was woefully inefficient and costly to operate. The product that they…

>Or so goes the old adage, "nobody ever got fired for buying IBM."

This is true but its never really hit me before even though I've already been operating based on the assumption that trusting the cloud is less risky than trusting my own skills.

Re: Lyft Files S-1

#366

Post by alkibiades »

umeshunni wrote: post #132
chollida1 wrote: post #4

Some stylized notes: - If they do go public for $20B+ they that would be for more than Twitter and Facebook went public for. Would you really want to own Lyft over FB and TWTR the day they went public? That's a very large ask of the public markets. EDIT To be clear I"m talking about their valuation multiple not the abs valuation. - working with JPMorgan, Credit Suisse and Jefferies. So I guess we know 3 banks who won…

This caught my eye in their exec compensation section: > For Mr. Green, the 2018 amount reflects $935,105 in personal security services and $1,787 in ride credits for use on the Lyft platform. Nearly a million dollars for the CEO's security services (presumably also including private air travel)? I can understand Facebook or even Twitter doing this for their high-profile CEOs, but most people would not recognize Loga…

sad that i have to even consider this but i wouldn’t put it past uber to have him physically harmed considering their ethics

Re: Lyft Files S-1

#367

Post by jordanbeiber »

theossuary wrote: post #165
doctorpangloss wrote: post #157

Earlier quoted context omitted.

> If those issues aren't in your company's core competencies, it's not necessarily efficient to invest in building out all of that. Maybe that's just the story cloud providers tell you. Until you try, do you really know if it's all that complicated? People have been running datacenters for a long time, and not all of them work for Amazon. But there may be also a beneficial side effect of having gearheads around, and…

Yes, I've worked with a few of those datacenters. A few examples: - Recently had to purchase new servers, because of signed contracts the only servers we were allowed to purchase and put in the datacenter were four years old and technically EOF. - Firewall changes, AD changes, provisioning a VM, etc. are 48 hour turnaround. Purchasing new hardware requires 4-6 weeks. - Had an intermittent issue with their edge firewa…

Seems like your experience is a case of ”ad hoc” systems management and I know what you’re saying is all to common in the enterprise world though.

Having spent my entire working life automating infrastructure of all kinds I know you can achieve an enourmous increase in efficency rather easiliy with a few well placed automated processes.

I’ve always been baffled by the fact that at any given larger company there are 100’s of employees trying to supply the business with tools to automate business processes — the IT dept.

Yet, they are completely incapable of using these very same tools to automate their own ”business”. And the resistance I’ve been met with at different places through the years when trying to implement the simplest of automation is massive.

I used to laugh at the ”cloud” bacause, back then, at 25 years of age, sitting at a medium size company with boatloads of cash, I assumed everyone was doing it the way we were; automating all the things.

Now, many years later I’v obviously realized that many places simply does not have the right culture and mindset as it’s not “core business”.

I believe however that this is changing, and changing quickly. In many ways thanks to the “cloud”.

Re: Lyft Files S-1

#368

Post by BurritoAlPastor »

halbritt wrote: post #354
bradstewart wrote: post #302

Earlier quoted context omitted.

Route53, RDS, DynamoDB, SNS. To name a few.

Route53 is okay. Has an API that is incompatible with BIND. There are many other, better providers. Still, it's cheap, so who cares. RDS doesn't really scale without costing a fortune. It buys you HA and backups. Great, but what if you need performance? DynamoDB? It scales in terms of IOPS, but again, it's unaffordable. SNS exists and isn't terrible, but why wouldn't I just run Kafka?

My forecasting on RDS is that it’s a dead-end product – all the future hotness is going to be in Aurora Serverless. Multi-region active/active Postgres with totally usage-based pricing and totally elastic performance is going to be a game-changer.

But if you need bleeding-edge Postgres performance, you hire a DBA, and they probably build something on EC2 or bare metal.

———

As I understand it, RabbitMQ is probably a better point of comparison for SNS/SQS, and Kinesis is the Kafka peer.

Regardless, the reason you don’t “just” run Kafka is: you don’t have a team that knows how to tune, deploy, and operate a production Kafka cluster. I learned enough about SNS and SQS to get it running in an afternoon, and I really haven’t needed to think about it since. Kafka (or RabbitMQ, or ActiveMQ, or etc) need instrumentation and monitoring and patching and quorums and capacity planning and etc, and at some scale those are worthwhile, but that scale is MUCH larger than what most Kafka clusters are actually serving.

———

The theme here is: if you have a business requirement for 90th percentile specialized performance, great! Hire domain specialists who can make your systems run at that tier! But for everyone else in the world, when you can get usage-based pricing, elastic resources, and automatic durability and patching... why would you go to the trouble of learning how to deploy and manage a service?

Re: Lyft Files S-1

#369

Post by tjoff »

fierro wrote: post #308
Alupis wrote: post #245

Earlier quoted context omitted.

> person who knows how hard it is to run your own infrastructure > fierro Profile: SWE @ Google Resource & Capacity Planning I think you mean "Person who's job it is to convince others it's really hard and they should just buy your product"...?

ha sure. I just meant I know the sort of operational burden cloud customers are able to outsource by not rolling their own, based on my time at the G inside resource planning and management.

You know anything of the burden to be reliant on someone else for your core operations? And having to invest and adapt so much just to lock yourself to one vendor? For many that alone is more than the operational burden of doing it yourself.

Re: Lyft Files S-1

#370

Post by mrweasel »

0xffff2 wrote: post #192
Sohcahtoa82 wrote: post #186

Earlier quoted context omitted.

If AWS went down, we'd be worrying about a lot more than catching a Lyft ride. EDIT: typo

Who's "we" and why would they worry? I'm struggling to think of a side-effect of AWS going down that would worry me more than being unable to get a Lyft (which itself doesn't worry me very much).

Europe tried having a Telia route throw away Amazon traffic a few years ago. The Internet basically stops working if AWS is down.
Post reply on HN