In general: don't fix a non-existing problem. You don't know beforehand what the problems of the future look like. Fancy technology X of today is technical debt in 10 years. So do invest in solving technical debt along the way in products you keep.
Does it scale? Who cares (2011)
61–70 of 285 posts
Re: Does it scale? Who cares (2011)
#62I agree with this article; however, there are considerations that can be made early on, to ensure an easy path for future scalability, that don't waste any time or money during the project's nascency. For example, if I know I want my app to scale at some point in the future, I may opt to build it in Elixir, or I may choose to use a Riak cluster rather than of MySQL.
Re: Does it scale? Who cares (2011)
#63Earlier quoted context omitted.
Agreed that completely blasé is pretty bad. However in this case being blasé would mean, not working hard to scale when you users are getting a bad experience. A basic stack these days node.js+mongo, go+*sql can easily handle more than 100k users even with one of the worst implementations. Most products don't reach that point!
> A basic stack these days node.js+mongo, go+*sql can easily handle more than 100k users... That is making some very large assumptions about application workload. For an application which is purely a CRUD interface to a database, yes.
Agreed on this point.
Many a times there is heavy lifting - recommendations, machines learning etc. However that is don't using specialized technologies in a non user facing process and the results are then dumped into a DB available for a CRUD app.
I am hoping that products with such requirements will have some obvious tools for such tasks (Hadoop, Hive etc) and they would find a way to scale such processes with time.
So their stack might be go+*sql+Hadoop.
Can you please suggest some use-cases which don't fit the above pattern and maybe we can brainstorm. Seems like a fun exercise!
Re: Does it scale? Who cares (2011)
#64Earlier quoted context omitted.
> but even crappy options like RDS Curious as to why you see RDS as a 'crappy' option?? Given the choice of building and maintaining a MySQL box in the corner of your bedroom and hosting it on RDS - I know which way I would go (and I have done both over the years). If you are talking 'scaling' in terms of the OP's article, then RDS is almost a no brainer, and you can scale your instances (and add replicated instances…
The highest IOPS you can get on RDS is about a single consumer grade SSD.
Fair enough. But if the alternative is setting up a consumer grade PC on a consumer grade internet connection in a (non environmentally or power controlled) corner of a room at home, then surely we are looking at a similar situation?
Given that spooling up a RDS instance is quicker and cheaper than buying all the hardware and spending time installing and configuring an SQL server, then if time to market is a critical factor, you would choose RDS over a home grown solution, wouldn't you?
[Edit: I just realised that this is actually the point you were making, and I got sidetracked by my above question]
Re: Does it scale? Who cares (2011)
#65Couldn't agree with this article more. I built the biggest social network to come out of India from 2006-2009. It was like Twitter but over text messaging. At it's peak it had 50M+ users and sent 1B+ text messages in a day. When I started, the app was on a single machine. I didn't know a lot about databases and scaling. Didn't even know what database indexes are and what are their benefits. Just built the basic produ…
> I know of absolutely no service which failed because it couldn't scale. First focus on building what people love. If people love your product, they will put up with the growing pains (e.g. Twitter used to be down a lot!).
They haven't failed (yet), but I think gitlab.com would be a lot bigger if they scaled faster. Lots of people have been rejected using it because it was too slow.
Re: Does it scale? Who cares (2011)
#66Couldn't agree with this article more. I built the biggest social network to come out of India from 2006-2009. It was like Twitter but over text messaging. At it's peak it had 50M+ users and sent 1B+ text messages in a day. When I started, the app was on a single machine. I didn't know a lot about databases and scaling. Didn't even know what database indexes are and what are their benefits. Just built the basic produ…
> I know of absolutely no service which failed because it couldn't scale. If by scaling you mean increasing the number of page views that a given version of a web app can serve, then this is mostly true. But things like conceptual simplicity, unit economics, codebase readability, strategy, etc. are also dimensions of scaleability. E.g. the only reason that startups can even exist at all is because large companies hav…
"scale" here, as with all conversations on HN about "scale", refers to the technology required to service a large number of users or usage.
Re: Does it scale? Who cares (2011)
#67Couldn't agree with this article more. I built the biggest social network to come out of India from 2006-2009. It was like Twitter but over text messaging. At it's peak it had 50M+ users and sent 1B+ text messages in a day. When I started, the app was on a single machine. I didn't know a lot about databases and scaling. Didn't even know what database indexes are and what are their benefits. Just built the basic produ…
This is a delightful retelling; thanks for sharing. > I know of absolutely no service which failed because it couldn't scale. Genuine question: what about Friendster?
Friendster's problem was that instead of fixing its problems, it decided to re-write.
Re: Does it scale? Who cares (2011)
#68Earlier quoted context omitted.
Everything has flaws but PHP is a reasonable choice for many problems. Python pip is crap compared to composer for example. While my favorite language is Elixir I mostly do Node and Python at work can't say experience is significantly better with either of them compared to PHP 7.
>Everything has flaws False equivalence. PHP has many, many more flaws to a much deeper and more serious level than any other mainstream programming language. It's insecure, buggy, full of broken behaviour for legacy systems, slow and easy to misuse. Its standard library is inconsistent, hard to learn, easy to misuse, full of legacy behaviour and slow. >but PHP is a reasonable choice for many problems. PHP is an unre…
When did you last write a project in PHP? Your thoughtsmight have been valid ten years ago, but they aren't now.
fwiw, I find the PHP stdlib more complete than many other languages.
Re: Does it scale? Who cares (2011)
#69Couldn't agree with this article more. I built the biggest social network to come out of India from 2006-2009. It was like Twitter but over text messaging. At it's peak it had 50M+ users and sent 1B+ text messages in a day. When I started, the app was on a single machine. I didn't know a lot about databases and scaling. Didn't even know what database indexes are and what are their benefits. Just built the basic produ…
> I know of absolutely no service which failed because it couldn't scale. I would say this is because of the simple fact of visibility and adoption. You've probably never heard of these services probably because they ground to a halt with a mere 1000 users, so they never got mainstream enough to be recognised as a viable service. It is a bit like how no one remembers the dozens of people who failed to achieve sustain…
You're refusing to learn from someone who lived it. I also know of zero services which failed because they couldn't scale their technology. But I know of 100s that failed because they couldn't get enough users or usage.
Your example about the DB tables is exactly the trap to avoid while you are iterating rapidly to try and find product/market fit.
Re: Does it scale? Who cares (2011)
#70I agree with this article only for launching new products. But if you already have a product which is serving millions of customers, you better worry about scale while you change anything.