29 ms·
Will your application scale?
- casta 18y agoAlso consider that if you write your app with a little bit of "code responsabiliy", usually when you need to scale, you have so many users that you can afford to rewrite your code thinking about scaling.
- ryan-allen 18y agoOnly if you have a business model and you're making money... or VC funding. I think the more important thing is to hire developers who have 'been there, done that' so they already know how to write code that is balanced.
- casta 18y agoI wrote my little web app without caring about scaling. Now it has about 20000 visitors a day and an average of 8 request per second. The uptime command says: load average: 0.16, 0.19, 0.15 (on a dual core machine.) Should I have any problem with the load, I think it would be feasible to find someone funding me. I understand it depends of the type of the service, but I also think that most of them could afford to think about scalability when they actually need it.
- tomjen 18y agoHe is partly right, but if you think about what you are doing it shouldn't be such a big issue to scale reasonably well later on. Rails is properly more difficult to get to scale since that was never a concern of DDH when he made it, something like Erlang scales because it was made to do that.
- zepolen 18y agoFrom personal experience, I would say he is entirely right. The first iteration of an app will be used by very few people, and most probably require a lot of changes in scope as users tend to have a way of 'abusing' (in a good way) a system in ways you could never conceive. Optimising for something that won't be used can be a terrible waste of time. For example, I recall a niche site that dealt with antiques - People could list their antiques for sale in a nice searchable 'craigslist' style site. They also included a separate url that showed only the antiques for sale by a single user, it was more of an afterthought than a core feature. The 'abuse' came when users, especially antique shops, starting using these as their actual sites. In a time when getting a presence on the internet was an arduous deal (hire a developer, hosting, domain name etc.) It turned out that the real interest of the site wasn't searchable antiques, but rather as a very simple method of creating an antiques focused minisite. Unfortunatey I don't recall the url.
- derefr 18y agoI would say that with the kind of "applications" you have people writing today, it's actually more effort to build scaling in at the start, than to throw away and rewrite the whole thing for a more scalable platform once you need to--there's just not that much code involved that's very hard to translate. To put it another way: live with the prototype for as long as possible.
- dasil003 18y agoI'm sorry, but this is complete nonsense. Rails is a framework for building web applications. Erlang is a programming language optimized for distributed computing. Rails doesn't have any inherent scalability problems. It uses a share-nothing architecture which will scale just fine. It's true that Ruby (the language that Rails is written in) is slow and presents some additional challenges to scaling (green threads, memory leakiness), but ultimately the burden of scaling rests on the architecture. If Ruby were 100 times faster it would be a very fast language indeed, but that still wouldn't make scaling easy. 100x is nothing when you're trying to go from 10 req/s to 1,000,000 req/s. As to your second part about scaling not being a big issue if you think about it up front, that is also a load of crap. Yes, don't do stupid things, but once all the obvious optimizations are gone you will usually be surprised by where the bottlenecks are. Most applications won't ever get to that size that scalability becomes seriously difficult, but then they certainly won't have a problem with Rails either.
- yesimahuman 18y agoI guess we'll find out once I get customers!
- ruslan 18y agoWhy every boggling blog writer nowadays says "application" while meaning "web site" ?
- bandhunt 18y agoBecause a facebook app and an iphone app aren't websites, yet they still have many of the same issues. Websites are becoming more and more like desktop applications and pigeonholing something as a "website" doesn't make sense, unless you are only talking about websites and it does not apply to any other web connected application.