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

Building for the 99% Developers

future.a16z.com

Post reply on HN
Print view View original

101–110 of 310 posts

Re: Building for the 99% Developers

#101

Post by gunnarmorling »

adra wrote: post #46
urthor wrote: post #38

Earlier quoted context omitted.

It's also that, in the past, the capacity of our monoliths to scale was far lower. There's many apps that need say, a 100GB database in 2022. Those apps also needed 100GB database in 2007, when horizontal scaling was the hottest thing around. Nowadays however, Moore's law has steadily overtaken an order of magnitude of use cases from 2007. Maybe 1/10th of the 2007 use cases still need that kind of enormous, big tech…

Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers. Scale horizontally and you're often constraining and or complicating your design/architecture, but you can handle outages far better, if not seamlessly. It's much harder to get right, so it's usu…

> Scale vertically and you're still a single point of failure away from a big, potentially fatal outage.

When folks talk about scaling up for stateful resources (database), this typically includes having stand-by replicas to which one can fail over within seconds.

Scaling up the DB and scaling out stateless compute nodes is more than enough for many, many use cases. Having a DB machine with one 1TB RAM isn't anything special these days.

Re: Building for the 99% Developers

#103

Post by arvinsim »

newrotik wrote: post #42
bjterry wrote: post #19

99% feels like an exaggeration. I've talked to many developers from non-FAANG companies, and it isn't at all uncommon for them to be using GraphQL or serverless. I guess there is some selection bias since they are usually applying to a unicorn, so they are probably more likely to come from environments that fit the "1%". Whether this distinction is relevant to you depends on where you sit. If you are a startup sellin…

The point the article raises is whether those "non-FAANG engineers" should be using serverless at all. Will their requirements ever scale to a point where it actually makes sense for them to be deployed as serverless services?

It's a chicken and egg problem.

How would you gain professional experience in something that is out of your current scope?

For example, if a frontend web developer wants to pivot to backend using serverless.

Re: Building for the 99% Developers

#104

Post by lelanthran »

weq wrote: post #56
newrotik wrote: post #42

Earlier quoted context omitted.

The point the article raises is whether those "non-FAANG engineers" should be using serverless at all. Will their requirements ever scale to a point where it actually makes sense for them to be deployed as serverless services?

So by No-FAANG engineer, you mean someone who isnt a robot ad hawker sell out? Serverless allows anyone to be scale for minimal up-front cost and only pay for the usage they really need. So glad that FAANG attract all this rare talent so us no-FAANG engineers can make a buck.

> So by No-FAANG engineer, you mean someone who isnt a robot ad hawker sell out?

Come now, is there any reason to throw those insults?

Re: Building for the 99% Developers

#105

Post by rzzzt »

urthor wrote: post #38
AnotherGoodName wrote: post #8

You'd be surprised at how fast you can create something with an SQL database, a well used backend framework (eg. Rails) and a well used frontend framework. The things big tech companies do are usually to avoid scaling problems. In particular scaling on the engineering side. The above can scale to billions on the user side if needed but 10k engineers constantly updating and messing with a traditional SQL schema doesn'…

It's also that, in the past, the capacity of our monoliths to scale was far lower. There's many apps that need say, a 100GB database in 2022. Those apps also needed 100GB database in 2007, when horizontal scaling was the hottest thing around. Nowadays however, Moore's law has steadily overtaken an order of magnitude of use cases from 2007. Maybe 1/10th of the 2007 use cases still need that kind of enormous, big tech…

Immediately reminded of https://yourdatafitsinram.net/

Re: Building for the 99% Developers

#106

Post by ju-st »

lumost wrote: post #45
MattGaiser wrote: post #40

Earlier quoted context omitted.

Yeah, that is not what recruiters seem to care about. Nor what is tested in interviews.

50/50 It's what employers look for in Senior Engineers, but junior engineers are often hired on pure tech. Historically there was a high amount of BS where people would take credit for deliveries that they were only tangentially a part of, or get ridiculously lucky on their first big project. It's next to impossible to hold an engineering team together to even KTLO if you don't have some project which grow's their ca…

The number one requirement for Senior Engineers is their extensive experience with the company's tech stack. At least that is what is written in job ads outside of FAANG. You're probably not passing the HR stage when you have experience in Java but the company is looking for a senior .NET developer.

Re: Building for the 99% Developers

#107

Post by lelanthran »

deathanatos wrote: post #51
alberth wrote: post #10

We way over complicate things. SQLite can be used for 95% of real world use cases. And whenever WAL2 + BEGIN CONCURRENT get merged into main, it will be able to handle 99% use cases. And don’t fool yourself into believing you’re not in that 1%.

You're not the only commenter saying this, so I gotta ask: whatever VM that SQLite DB is on, is your business cool with a business disruption, dataloss, or both when that VM goes down, when that AZ goes down, or that disk fails? Or am I missing something? If you have some sort of fail-over-to-last-backup plan, is that not just a distributed database with more steps, and why not something like RDS, or CockroachDB? (Fr…

> is your business cool with a business disruption, dataloss, or both when that VM goes down

Most businesses seem to handle downtimes okay; some money[1] is lost, maybe.

[1] And if the business feels that the expected (negative) value of the downtime is less than the cost of mitigating it, they simply (correctly) ignore it. For example, most businesses don't build a separate highway to their building in the event that a traffic jam causes fewer customers to show up. The expense is not worth the savings.

Re: Building for the 99% Developers

#108

Post by AceJohnny2 »

In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with.

Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code for fun. Everyone for whom coding is something that gets in the way of their real objective.

No wonder they produced bad code! But that's not the point: they're solving something else. They're not spending effort making bug-free maintainable code, they've got more important things to do. They're doing the accounting for their small company, point of sale for the shops in their city, all the kind of things that may not be glamorous but that's all around us (for better or for worse)

So while I puttered around in my self-congratulatory ivory tower of unix, Microsoft understood what the real world needed, for the 99% of developers...

Re: Building for the 99% Developers

#109

Post by closeparen »

newrotik wrote: post #42
bjterry wrote: post #19

99% feels like an exaggeration. I've talked to many developers from non-FAANG companies, and it isn't at all uncommon for them to be using GraphQL or serverless. I guess there is some selection bias since they are usually applying to a unicorn, so they are probably more likely to come from environments that fit the "1%". Whether this distinction is relevant to you depends on where you sit. If you are a startup sellin…

The point the article raises is whether those "non-FAANG engineers" should be using serverless at all. Will their requirements ever scale to a point where it actually makes sense for them to be deployed as serverless services?

mod_php is a serverless compute platform. The better question, will anyone’s requirements ever scale to a point where it makes sense for them to NOT be deployed as a serverless service? FTPing source code to a shared hosting provider is about as simple a deployment story as it gets; people bring all kinds of incredible complexity and thousands of hours of work on themselves messing with daemons, init scripts, systemd units, VM images, containers, schedulers, etc.

Re: Building for the 99% Developers

#110

Post by DenseComet »

alberth wrote: post #54
deathanatos wrote: post #51

Earlier quoted context omitted.

You're not the only commenter saying this, so I gotta ask: whatever VM that SQLite DB is on, is your business cool with a business disruption, dataloss, or both when that VM goes down, when that AZ goes down, or that disk fails? Or am I missing something? If you have some sort of fail-over-to-last-backup plan, is that not just a distributed database with more steps, and why not something like RDS, or CockroachDB? (Fr…

Mentioning RDS is an apples to oranges comparison. RDS is a fully managed service by a 3rd party. Nevertheless, checkout https://litestream.io - given that SQLite is just a file, it’s incredibly easy to replicate. Failover is coming in the next release, which is already beta. Also checkout this Expensify blog post on how they use SQLite. It’s scales amazingly well. https://blog.expensify.com/2018/01/08/scaling-sqlite…

Can you really still call what Expensify uses SQLite? It is very heavily based on SQLite, but they say that they've "wrapped it in a custom distributed transaction layer named Bedrock". Feels like they've gotten much closer to a traditional DB architecture, with the related management overhead that people try to avoid by using SQLite.

http://www.bedrockdb.com/

Post reply on HN