de facto mechanism for future applications, it occurred to me that, indeed, what goes around comes back around again. The first computer I ever had was a 286 and every application was stand-alone. What little networking existed was via modem and simple BBS applications. When I got to college I maintained various VAX/VMS and Ultrix-based "dumb terminal" applications. People hated them because of the esoteric commands needed to be productive. To send an email required the user to construct a command-line string similar to smtp%"email@example.com". Please remember that I was dealing with freshman college kids with little to no experience with networked computers, not to mention Luddite college professors who believed all innovation in "word processing" stopped with the advent of the IBM Selectric II typewriter. I had little "tricks" I taught the professors to make things easier for them to remember. Example: "SMTP" was "Send Mail To Postman". Even that was too hard to remember!
"I typed smtm% just like you taught me and it's saying 'Invalid command'."
"I'm sorry you are having problems Professor Mankiewicz. It's actually smtp, send mail to postman, not smtm. Why would you think it's smtm?"
"I thought it was 'send mail to mailbox'. Sorry about that."
"Is there anything else I can do for you today doctor? No? OK sir, see you in Econ 101 tomorrow. Bye."
My first "real" job out of college was as a programmer on an IBM mainframe TSO system. TSO stands for Time Sharing Option. It's quite simple, a user can login to the system and is unaware that other users are currently interacting with the system. This is no different than a Unix login over telnet. Around the same time TSO was introduced it was becoming common for universities to "rent" time on their computers to interested folks who could develop their own programs. You've probably heard of people like young Bill Gates who "rented" off-hours, unused cycles from colleges and companies that had these expensive computers.
Of course the concept of "renting" computing resources went out the window with the advent of technologies like the web and VMWare, right?
Wrong! Renting off-hours, unused cycles is again en vogue with the advent of the cloud.
(Google's first hit for TSO)
As I've mentioned in a few recent blog posts, I need to research and prototype a number of "NoSQL" solutions. I could of course build these in-house, but some of these products are extremely difficult to setup and install unless you hold a PhD in CompSci. It's much easier to provide Amazon with a credit card and use Amazon AWS. After an hour and less than a hundred bucks I had a running Riak system to play with. Very cool. But AWS is not really time sharing. That's what I thought until I researched all of the AWS offerings a bit more.
AWS and EC2
On the AWS website is a link to powerof60.com. This explains Amazon's EC2 offering. EC2 is an acronym for Elastic Compute Cloud. With this offering you purchase processing cycles just like you purchase electricity. You pay for as much as you use, and you pay more during peak hours. Services are available just like a utility. This sounds a lot like time-sharing to me. Amazon has lots of case studies where companies (even NASA) have occassional need for lots of processing power. Amazon will let you spin up the resources as you need them, when you need them, without the up-front capital expense of purchasing your own hardware and software (not to mention labor). If you can do your processing off-hours you pay less. You can even have Amazon spin up your processing for just a few minutes (off-peak) to save even more $$$.
Although I can't find this documented by the Azure folks, I just heard that Windows Azure is going to a per minute pricing strategy in the future. Apparently you can power down your VMs when (if) your developers leave the office and 5pm and you won't be billed again until you power them back up the next morning.
What goes around comes around again.
Dave Wentzel CONTENT
data architecture other nosql