« November 2009 | Main | November 2010 »

June 18, 2010

Peaking at "The Cloud"

OK, so "Cloud Computing" is a fancy way of saying hosted data storage, servers or applications. Your stuff on someone else's hardware, for a fee. They do the drudge work, you do the thinking and rake in the money, right? Or not, as the case may be, as cloud resources still need to be managed by your own in-house team, but they just have less control and more constraints.

I went to the Web 2. conference a couple months back, and this year was very encouraged to see some of the pure BS hype from last year being dialed back. Plus, there were people actively promoting security and best security practices in the "cloud" space.

I have spent a lot of time trying to figure out what the heck I would really recommend that companies use "cloud" computing resources for. What is actually my idea of the "killer app" for "cloud computing"? It eluded me for a while, until one day I went to that venerated geek haven, Slashdot.

Who in the high tech industry hasn't heard of the "Slashdot Effect", when an article is written about your company or website, and the attention and resulting web traffic it gathers crashes your site? The Slashdot Effect exceeds all planned peak load (if you ever planned for such a thing), and gives systems people gray hair overnight. Thing is, not just Slashdot causes this - as Amazon found out with the Harry Potter releases.

The killer app, then, becomes the ability to handle those peak loads - seamless peaking - without having to have a large number of expensive machines idle 95% of the time. It must be cheaper than provisioning a bunch of machines and leaving them to run; it must come on-line rapidly, and it must be responsive to the demand. We are talking about dynamic peaking of web services.

IMO, this type of application would be a virtualization specialty, with load balancing and network allocation in the mix. Dynamic allocation of compute resources is a must. While the initial set up and configuration would be done under non-load conditions, the actual engagement of the resources would be based on demand, and automated to happen in near-realtime.

Automation is key, here. The Slashdot Effect happens rapidly, often faster than you can page a sysadmin out of bed at three am. Yet it is not so rapid that the traffic chart is a complete right angle. The key here is monitoring, and smart enough monitoring to discern between a DDOS attack and a genuine demand peak. The idea is to bring enough resources on line rapidly enough to respond to the trend without going too far, and then scaling them back when the peak is over (most peak scenarios neglect this.)

The cost-effectiveness of this is obvious. A base fee would be charged for the configuration of the various resources and the ability to "peak" up to a certain level. Above that, only the actual peaking usage brought on line and used would be charged for, by bandwidth, CPU, and disk space metrics. This, of course, is another reason why the ability to automatically de-provision resources has to be part of this.

So there you have it - dynamic peaking - what I see as the basic outline for the killer "cloud" application, something that would let more sysadmin's sleep at night, secure in the knowledge that the cloud would handle that surge in popularity that marketing has been promising "...any day now.".

Posted by ljl at 6:54 PM | Comments ()

Unemployment Issues

Silly companies, has no one told you that we are in a deprerecession? When you hire an H1(b) for a US job, you hamper the recovery. When you refuse to consider an unemployed applicant, you shoot yourself in the face.

... firms that hire unemployed job seekers could also benefit from a recently-passed tax break that essentially exempts them from paying the 6.2% of the new hire's wages in Social Security taxes for the rest of this year. - Out-of-work job applicants told unemployed need not apply
Yes, people, you are losing out on a tax break if you pass over the unemployed.

Oh, by the way, lifting and carrying are not IT skills. They really aren't. They are just excuses not to hire women, older people, and/or the disabled. I don't care how you try to spin it, how you try to justify it, but it's just discrimination. All you'll end up with if you want your expensive systems people to lift and haul stuff is geeks with bad backs and expensive workman's comp bills. Get carts or hire cheap people for the grunt labor, don't risk your expensive equipment on some geek trying to be macho. Flat screen monitors don't weight 5 pounds.

Lose the bias against older folks, seriously. I don't know how many times I have had to clean up after the young cowboy or reinvent the wheel type because the company only wanted "new, fresh" recent college grads (read that as "people under 3"). Don't expect a really experienced person to answer trivia questions on a phone screen, either. The petty details and file names? We look those up, because they change over the years, and move from distro/variant to distro/variant. I don't keep the syntax for every type of config file that I've ever touched in my head. Even standards like Apache, or Kickstart, have changed over the last 8 years. That may seem like slow change, but to an experienced person, that rate of change is a ridiculous amount of memorization for the purpose of passing phone screens every three years. Cut it out.

I realize that there are so many fakers out there that you actually have to ask "What is a man page?" I laughed when one interviewer told me that. (I didn't get the job because they *assumed* I couldn't lift 5 pounds - I can, but shouldn't need to.) If you're going to fake knowing about Unix/Linux, do your frigging homework. Know what RTFM means. But interviewers need to realize that those of us that do RTFM don't need to memorize - that's why we RTFM.

Oh, and for those of you who say "just get a job, any job" - go screw yourselves. Most sensible employers will not hire overqualified people because they will leave for their regular career as soon as they can. This means that not only can I not be considered for an entry level NOC job (which I would gladly take at this point, just to beef up the networking side of my resume), I will never be considered for a clerk, waitress, fast food, warehouse or even clerical job again, except maybe as a temp - and then only for a one or two day "day labor" gig, not a real job. So no, I really can't go work at MacDonalds or WalMart. Stop suggesting that I apply.

Posted by ljl at 2:37 AM | Comments ()