I often hear statements in the form of “X is cheap, don’t worry about it”. This usually comes up in design sessions, software or infrastructure, it doesn’t matter, you can usually find or hear a statement in this form in either type of design session.

The most common versions would be in reference to disk space, bandwidth, and CPU.

I suppose this type of thinking is a result of the effects of Moore’s Law. One of the troubling things about this sort of thinking is that it is frequently wrong and is indicative of someone with a closed mind, an inability to see the big picture, lack of insight, short-sightedness, or any other similar phrases. In all cases, when someone makes an X is cheap statement it’s a safe bet that they haven’t really thought things through. These statements are very dangerous, particularly if you happen to be in a design session when someone says this and is of particular concern if that someone is a team leader or manager.

The most dangerous aspect of these statements is that on the surface they may appear to be accurate and correct. Unfortunately, unless we are designing as system that people will only look at (ie. the surface), rather than actually use, it is rarely correct.

I’ll make an attempt to examine the most common of these statements to show how and why they are incorrect and assumptions. The analysis will be from a business/enterprise perspective rather than a personal/consumer one. You might be surprised to see how inter-related these can be! Let’s start with:

Disk is cheap, don’t worry about size

I will have to start by conceding the fact that disk storage has gotten very cheap indeed. The average consumer can put a terabyte of disk into their PC for less than $200. So how can that NOT be cheap?

We first need to understand what is really being said here. This usually isn’t a reference to disks and storage in general, it will be in reference to data files or databases.

So lets talk about files… in the past files weren’t that big, they were text files or word documents, and although the word documents were bigger, the size was still reasonable. This is no longer true, text files are rarely used anymore, the same information is now in a PDF file, or word document, an image, or a multi-media file. Those PDF and word files usually have graphics in them too, and to ensure that they look good when they print the graphics are stored at full resolution, even if they are only displayed thumbnail-sized in the document itself. The average document size is now measured in MB instead of KB, and for media files, GB is becoming more and more common.

So, what am I trying to say? The amount of storage that is available at a reasonable cost has increased by orders of magnitude, but so has the average size of the files that we store. The net result is that we can store about the same number of files as we used to before.

Even if we can store more files there is another cost involved. The more files and directories we have on our disks, the more difficult it becomes to find a file when we need it. If a user can’t remember where they put a file on a file server and they have to search for it, that potentially ties up a lot of I/O and CPU resources as the server scans all the files. That results in slower performance for all the other users relying on that server. That same server could be hosting a database, or a VM, or even just the virtual disk of a VM, and each of those would be affected by this search. Even if you don’t search for files very often because you are so well organized… those files are getting scanned anyway a couple times a day by your anti-virus and anti-spyware software.

Now lets look at databases… Modern database servers make them easy to use, quick to access, all those good things. So where is the problem. Let’s look at how a real production database gets used. To start with, you don’t just put a production database on disk, that’s too risky, disks can fail. You put it on a raid array instead, using mirroring, or striping, or whatever. The end result is that we now have two or possibly three (depending on the level of raid) copies of that database. We need to back up the database, that’s another copy… but in today’s web-enabled global economy, we can’t take the database server offline to back it up. So we have to take a snapshot to another disk so that we can make a backup of it without it changing while we write to tape, that’s another copy. Add some developers into the mix, any system that has a database probably has some developers working on new versions of the software and they need working copies of those databases to use for testing and development. That’s another copy (per developer) for each database. What are we up to now? 5 or 6 copies? Once again, the way we use that so-called cheap disk space quickly changes the cost per MB when each MB that we use is actually stored multiple times.

Backups become important too. Bigger databases take longer to backup, which also means they take longer to restore too. That can be crucial when the database for a web-commerce site goes down and we need to restore it. The companies that chose to believe the “disk is cheap” myth will be offline waiting for the restore a lot longer than the company that chose to use their disk space more wisely.

Storage in general is no longer local in a business environment. Files get shared on file servers, as well as through the use of SAN and NAS devices. This means that accessing the data on those “cheap” disks is now over a network and now bandwidth enters into the equation. A perfect segue into…

Bandwidth is cheap, don’t worry about the size of your data

Once again, we start with trying to understand what is really being said here. This is typically the speed of the available network rather than the cost of the network, although it can easily refer to both.

The speed and cost of networks has improved dramatically over the years. They have gone from 300 baud modems to 1200, and on and on up to 14400 and 56Kbps only to be replaced by broadband connections anywhere from 128Kbps to 10Mbps. Local networks went from proprietary systems to 10Mbps Ethernet, then 100Mbps, and now 1Gbps or wireless networks that started at 11Mbps and are now 54Mbps or 108Mbps.

What was once inconceivable to transmit over a network is now commonplace. So where is the problem here?

The first misconception comes from a single user perspective of the network. This is easiest to explain with an example. A typical office will have a 100Mbps network, providing 100Mbps of network bandwidth to each user. Sounds pretty good and we don’t use hubs anymore everyone uses switches, so user A doesn’t get impacted by what user B is doing on his segment of the network. Or does he? That depends, although in most cases the answer is yes, they are affected. Those network switches only isolate traffic between two end points. So, I might have 100Mbps between me and the switch, but ultimately I don’t need anything from the switch, I need it from some resource on the network. That resource might be a file server, or a database, or a website. There is a significant chance that I’ll be competing with the other user to connect to the same end point. So while we both have 100Mbps to the switch, we are sharing the 100Mbps from the switch to the common end point, so we’ve effectively been reduced to 50% of the “perceived” bandwidth. Chances are that it won’t be just two users connecting to that common end point, but a lot more. In a small company, you are probably competing will ALL the other users, so divide that 100Mbps by 10 or 20, bringing us down to 10Mbps or 5Mbps, certainly not the amount of bandwidth that you expected to get.

I will admit that I’m not being completely fair in my calculation, its far to primitive to be accurate, everyone would have to be accessing the same server at the same time for those numbers to be correct. Statistically we will get much better performance, exactly how much better is harder to predict since it depends on what is being accessed. Of course, the bigger the files we are after, the longer we send transferring their data, the more likely we are to be affected. This is where we can start to see the impact of the “disk is cheap” mindset on other (seemingly unrelated) areas of computing.

So, I haven’t proven anything other than you won’t see 100% of your bandwidth. We’ve only been talking about an typical office LAN, lets examine networked applications.

There are two typical varieties of networked applications. Those that explicitly use the network by implementing some form of protocol, and those that indirectly use a network through file sharing, web-services, SOA, or database connections. If a protocol is designed with the “bandwidth is cheap” thinking, you’ll probably find that it sends and receives lots of data. The networks are indeed fast enough to make this appear to be a non-issue. Unless you happen to be the the sysadmin or the hosting provider. More efficient use of bandwidth translates directly into more users, which translates directly into revenue. Once you max out your bandwidth with users, you might also need to buy/build new servers to handle more customers.

The more customers you can fit into the same bandwidth, the fewer servers and infrastructure you need, which directly affects the capital investment required (which again, affects Time-To-Revenue, since you have to recoup the infrastructure cost to become profitable).

More and more often you will find servers running in VMs, which wind up aggregating network traffic from all VMs to a single physical network. Applications running in VM servers that don’t make efficient use of the network could find the VMs running out of available network bandwidth before they run out of available CPU. If we have network traffic between two VMs, it never hits the physical network, but it does wind up consuming additional CPU possibly impacting performance of the other VMs.

When we introduce wireless and cellular networks to the mix the impact is more easily observed. Sure that new 802.11n wireless is fast, but when you have an office full of users streaming video over the same shared wireless bandwidth…

So if you encounter someone that suggests “X is cheap, don’t worry about it” in your next design session or troubleshooting discussion, you will know that what they are really saying is that they probably don’t understand the issue at all.

I have a confession, I’ve fallen victim to the power of Steve Jobs’ Reality Distortion Field. I’ve been glued to the live “blogcasts” of his keynotes from MacWorld, Apple WWDC, and the special event announcements/presentations. I don’t even own a Mac! …but now I know I want one.

Now that I have that off my chest…

I was extremely pleased as I watched the keynote from the September 5th Apple Special Event. What pleased me the most was confirmation of some of my previous musings by the announcement of the new iPod Touch. This device confirms what I suspected, the “touch” is the first of Apple’s embedded hardware platforms. When the iPhone was announced, it was the fact that this platform was running OS X, enabling Apple to leverage a self-hosted environment in Mac OS X. This has been a competitive [and strategic] advantage that QNX enjoyed in the past. The iPod touch is using the same platform and derives the same benefits.

Apple has proven they have the ability to leverage this platform, I think we are going to see some interesting products emerge from this more rapidly than anyone expected. The iPod touch was announced only 3 months after the release of the iPhone, that is an insanely short period of time between products. It also means that in order to even get the device manufactured in time for the announce availability, that the hardware had to have already been in manufacturing when the iPhone was announced.

Self-hosted development is a huge advantage that Apple now has over its competition. They can develop new applications on desktop mac computers long before any target hardware is even available. This improves time to market tremendously, a key advantage in the cut-throat consumer device markets that Apple is playing in. With an embeddable OS X as the core, handling all the hardware differences behind standardized APIs, and the ability to re-use application from previous products, this is a killer environment. Developing and debugging a WinCE device (which are the guts in many iphone competitors like the HTC TyTn, Samsung Blackjack, Motorola Q, as well as devices from Audiovox, Symbol, HP and others) is a painful experience. Much of the pain experienced with the WinCE development model is all the time spent waiting to deploy a new build of an application to the device, it’s slow, even when on a fast/powerful developer workstation. Sure there are emulators, but they are no faster when deploying or debugging an application, and networking (wired and wireless) doesn’t work at all in the emulator. A developer at Apple will be able to develop an application for the “touch” platform in easily one half or one quarter the time required for a similar app on a WinCE smartphone.

I don’t think the rest of the embedded world has much to worry about from Apple though. They aren’t likely to be sharing their hardware platform with anyone else. They might need to be worried if they are making consumer devices and Apple decides to enter their market.

I think we are going to be seeing some interesting products from Apple in the future some of which are sure to take them in directions that will be quite unexpected from the outside.

I’ll be staying turned and keeping an eye on Apple, I suggest you do the same.

I’ve been thinking about Apple recently, just like everyone else many thoughts have been provoked by the upcoming iPhone release as well as the latest beta release of Safari. I don’t own a Mac, and I’m not a Windows fan either, my background is in embedded systems and software, I run QNX, Linux, and Windows on my network.

The most interesting things that I have noticed seem to have been missed by the mainstream, or at least I haven’t seen or heard a lot of commentary on the things I’ve noticed.

Embedded Apple
The first thing that struck me about the announcement of the iPhone was the mention that it is running OS X. The iPhone is certainly not running an x86 processor, or even a PPC one, it’s closer to the iPod than it is to a Mac, and the iPod uses an ARM processor. Apple has not officially revealed which CPU is powering the iPhone, although this ars technica article is rumored to be correct.

Which means that Apple has a version of OS X for ARM. That’s a big deal. A really big deal. ARM is one of the predominate CPUs for low-power embedded systems. Apple now has OS X running on three CPU families: PPC, x86, and now ARM. To make this even more significant, is that the development environment is self-hosted. Developers (at least the one @ Apple) can code, develop, build, test, and debug their applications on their Macs, and once they have it working, and assuming they’ve allowed for the difference in pixel resolution, can recompile for the iPhone and have a running application. Of course this doesn’t have to be for the iPhone, the Apple division that is responsible for developing the iPhone is actually a consumer products group, and the iPhone is merely their first product. There are countless consumer devices that Apple can build using the ARM processor and their new embedded OS X.

Yeah, I’m making a big deal of this. Self-hosted development represents incredible productivity when developing software for embedded platforms. Not only has Apple boldly entered a new tier of consumer devices, but it has done so by equipping itself with a huge time-to-market advantage over it’s competitors.

Carrier 180°
Apple will have done something remarkable when they release the iPhone, and surprisingly, it has nothing to do with the iPhone itself. The market dynamic between wireless carrier and handset manufacturers has been distorted by the carriers for many years. Typically the carriers will dictate to the handset manufacturer which features they want in a handset and specifically how they want to be able to control those features. This is the concept of a “carrier lock” on a phone. Consumers don’t like it, but by providing the ability to control features and/or lock them to the carrier allows the carriers to subsidize the handsets since they have a reasonable guarantee of revenue stream from the device. Control of this revenue is huge factor in how much a carrier will be willing to subsidize a handset. It’s quite common for carriers to offer some handsets at ridiculously low prices or even for free with fixed-term contract.

Apple turned this dynamic around 180° on AT&T when they chose them as the provider. Steve Jobs knows that much of the success of Apple products is a direct result of the “Apple experience”. The engineering of the UI usually makes an Apple product much easier to use than the competition, and when combined with the elegant and sleek physical designs Apple is known for, the result is very high customer loyalty. That loyalty makes Apples customers quite willing to pay a higher price, a nice payback for the design effort. So, it should come as no surprise that the experience is paramount with the iPhone as well. If Apple were to allow the carriers to dictate what features could be controlled, it would negatively impact the experience. As an example, in the traditional model, many carriers might restrict the WiFi capabilities to file transfer, and prevent its use for VoIP applications to protect their revenue stream from airtime.

With the iPhone, Apple calls the shots, and leaves everything enabled. This too is a big deal, it is a complete 180° change in the dynamic between device/handset manufacturer and carrier. The effects of this change are much larger than the effect of the iPhone in the handset market. I’ll definitely be watching that to see how it turns out.

Windows Target
The last thing I want to mention is in regards to the beta release of Safari for windows. Ignoring the bugs and other issues that numerous others have found and discussed, what caught my attention was how much of the Apple GUI was present. I will openly admit that I don’t know a lot about the application development environment on the Mac, so I could be dead wrong on my interpretation here.

Jobs has talked a lot in his keynotes about core animation as a key feature in OS X, which I found interesting in the context of Safari. Now, I know that Safari has little use for core animation when rendering web sites, since web sites don’t do anything with it. When I went to a site that was password protected though, the dialog box that appear for the login credentials had some slick 3D animation as appeared and disappeared. Certainly looked like core animation to me, but I could be wrong. Others have noted that the font rendering in Safari differs from Windows. I won’t get into the debate over whether it is better to honor the font design or the pixel grid, that isn’t the important part of this. The important part is that the graphics rendering in OS X is display postscript, of which font rendering is a component. Does the presence of the Apple-style font rendering indicate that the GUI API includes Apple’s display postscript too? To me, the (apparent) presence of core animation and the Apple graphics render engine are significant. Display postscript provides an excellent hardware abstraction layer for graphics rendering, the presence of Apple’s DP in a Windows application would mean a low barrier for ALL Mac OS X graphics on Windows. I really have to wonder how much of the Mac OS X GUI / Windowing API is now available in a DLL for Windows.

As I mentioned previously, this is the one thing that I have less confidence in due to my lack of knowledge of the Mac OS X application development environment. If I am right though, the existence of core animation and the Mac OS X GUI API & render engine on Windows makes the possibility of windows as an cross-dev target quite high. Apple already has a universal binary that can carry PPC and x86 binaries simultaneously, it wouldn’t take much to extend this to also include x86/Win32 as well.

Tomorrow’s Apple
All of these things together have Apple well positioned to dramatically change the landscape for embedded device/application development as well as windows application development. The appeal of being able to produce Mac and Windows software with only a recompile would be a strong incentive to bring significant numbers of developers to the Mac platform. Could tomorrow’s Apple be the next Windows dev platform? I don’t know, but it seems to be within the realm of possibility, and that will make the future of software development very interesting indeed.

While I was fumbling around attempting to recover the few posts from my original blog, Trever managed to find that the Way Back Machine aka Internet Archive not only managed to index my site, but it had a complete copy of the original postings. I have transcribed them into the new blog, which was nice enough to let me back date them so that the appear in their original order.

Three posts have been recovered, hopefully they are still of some interest and relevance to others.

To Trev:
for( i = 0 ; i < 100 ; i++ ) printf( "Thank you!\n" );

…just isn’t as much fun as it used to be. I managed to recover the titles of the posts that I wanted to recover, 3 out of the 5 that I had posted (yeah, I know not an overly impressive count by any measure). After several attempts to recover the text from the disk, I gave up, I have no idea what postgresql did but it sure didn’t put all the text contiguous on the disk. I was able to recover a couple of comments, and that was it.

So, I have decided to just start over.

After an unfortunate corruption of the database that was running the original blog, we are now back online. This time though, I decided that I would let the folks @ WordPress.com host the site.  Uploading the new header image seems to have made it blurry, not sure why, I guess I will have to play around with that some more.

I will try to recover the original posts (I know there weren’t that many) and get them back online in this new location.