Why I Don’t Want an iPhone – or iPad – or iPod Touch…

Recently, Cory Doctorow wrote about why he didn’t want an iPad (and why we shouldn’t either).

I don’t want one either – for many reasons. It’s the same reasons I don’t want an iPhone or iPod Touch as well.

On the iPhone specifically: I don’t want to be forced into a specific carrier. When will the iPhone be available for US Cellular customers? Probably never. When will the tying of the phone to the carrier be invalidated by the courts?

Also, will it ever be possible to take the iPhone and take it from one carrier to another? There should be no bundling of phones with cellular service; I should be able to choose whatever phone I want and use it with whichever service I want.

Secondly, you can only install applications that are approved by Apple – and these same applications can be pulled from your iPhone without notice (and without refund!). The approval process for new applications is slow and mysterious, and the secret developer’s agreement contains some very draconian measures.

Thirdly, the battery is sealed – so you can’t change the battery if it dies. If you need a new battery, you need a new phone.

The battery is not the only thing that is sealed; there is no way to put your own software on your iPhone or iPod Touch or iPad – no way to load Linux, no way to write your own software and load it up. If you write your own software with Apple’s Software Development Kit (SDK), then you are required to use the Apple Application Store, and no other – even if you are refused (which an application can be for any reason).

The iPhone is a locked-down environment like no other; why be locked in?

Are You Ready for the Onslaught? (or Scaling Your Environment)

Is your environment ready for the onslaught that you may or may not be aware is coming your way?

One commonly known example of this is what is called “the Slashdot effect.” This is what happens when the popular site Slashdot (or others like it) links to a small site. The combined effect of thousands of people attempting to view the site all at once can bring it to its knees – or fill up the traffic quota in a hurry.

Other situations may be the introduction of a popular product (the introductions of the Iphone and of Halo 3 come to mind), or a popular conference (such as EAA‘s Airventure, which had some overloading problems).

Examine what happens each time a request is made. Does it result in multiple database queries? Then if there are x requests, and each results in y queries, there will be x*y database queries. This shows that as requests go up, database queries go up dramatically.

Or let’s say each request results in a login which may be held for 5 minutes. If you get x requests per second, then in 5 minutes you’ll have 300x connections if none drop. Do you have buffers and resources for this?

Check your kernel tunables, and run real world tests to see. Examine every aspect of the system in order to see what resources it will take. Check TCP buffers for networking connections, number of TTYs allowed, and anything else that you can think of. Go end to end, from client to server to back-end software and back.

Some of the choices in alleviating pressure would be using caching proxies, clusters, rewriting software, changing buffers, and others.

James Hamilton already has collected a wide number of articles about how the big guys have handled such scaling problems already (although focused on database response), including names such as Flickr, Twitter, Amazon, Technorati, Second Life, and others. Do go check his article out!