Don't want to reduce your smug, but we're doing just this - restart services from the failed component, service the failed resource on a non-critical timeframe. The small shop with a half-dozen server boxes doesn't give a damn about cooling costs or this level of service, for the most part. If they do, they're likely going to someone else to satisfy that requirement, not doing it in house.

I've got stack of servers in my datacenter that are allocatable on demand. Any unused server blade is a potential spare. If a production blade tips over with a CPU fault, memory error, or similar crash, its personality (FC WWN's, MAC's, boot and data volumes, etc.) are moved to another blade and powered on through an automated process. Since the OS and apps live on the SAN, both VMs and dedicated server hardware can be abstracted away from the actual services they provide.

This is a product my company's selling to the market at large right now, and that I designed. Any of our IaaS customers can take advantage of the redundancy and fault tolerance built into the system. Even the six-server small IT shop.

Even then, a small IT organization can easily virtualize and provide some level of HA services in hypervisor clusters now. It's just not that hard anymore. Take the handful of servers you're running on now, replace them with an equal number of nodes in a VMM cluster, and go to town. Any of those systems fails, shift the load to the other nodes and effect repairs.

"Cloud computing," while it has very nearly achieved meaningless buzzword status, is an attempt by the business and marketing types to get their heads around what is a very real evolutionary transformation occurring in IT. The drivers are the drying up of CapEx budgets, the need to reduce service delivery time, and the requirement to purchase and pay for only what an organization needs to fulfill their business requirements.

Capital expenditures are coming under increased scrutiny, and are under constant budgetary pressure. "Cloud" based, on demand services allow IT service procurers to shift from a CapEx based model of owning the infrastructure to an OpEx model. Operational expenditures are typically larger chunks of budget than capital purchases, and moving IT services there can allow them to get "lost in the noise". Less red tape, less stringent approval processes, etc.

Time to deliver service is a labor cost, and if a procurer can shift that operational expense from internal overhead required to deploy an IT architecture to acquiring those same services from a cloud provider, it's perceived as a big win. The provider gets to deal with the headaches of capacity management, infrastructure design and integration, and delivering IT resources. The purchaser gets the luxury of simply specifying how much they want, for how long, and letting the provider leverage its economies of scale and automated processes to deliver the resources within the terms of the provider's SLA. The tradeoff is that the consumer of cloud services loses the ability to specify the platform and all its parameters in exchange for rapid delivery of a standardized service.

IT organizations are also under increased pressure to abandon the concept of designing and purchasing for peak capacity. Cloud providers are specifically addressing these needs by allowing their customers to pay only for what they use, not the spare capacity. Since the "cloud" capacity is shared, reused, and managed by the provider, the customer is afforded the ability to scale their environment dynamically to meet the needs of the business and its budget.

Now, how this ties into Web Services is important. Web Services, for a long time, was a solution in search of a well-defined problem. Now, with the "cloud" becoming a workable construct, Web Services come to the forefront as the way that stateless platforms can interact without intimate knowledge of the underlying infrastructure. Web Services will become more and more important as IT services are increasingly abstracted away from the hardware and OS platform. As I've worked for the past two years as a design architect for an infrastructure-as-a-service type platform, I can say with some authority that they're are an integral part of how we're going to need to deal with virtualized environments and stateless service contexts as they become pervasive elements of IT solutions.

Yes, technical tests are fair, and required.

Recruiting agencies will put everything and anything on a candidate's resume. Their people are evaluated by how many interviews they can schedule, and how many placements they achieve. So, they will stack the applicant's CV with anything that's ever been in the same 10-mile radius as the individual in question.

The result is that you're faced with a piece of paper that looks identical to every other programmer's. It's an alphabet soup - .NET, C#, Java, C, C++, Python, .NET, ASP, ADO, JDBC, XSLT, VB, XML, SQL, BLAHBLAHBLAH. And every programmer lists every one of these. Even the projects look the same - "Senior programmer for web development project implementing a user portal and reporting system for... etc, etc, etc." I have a stack of 12 resumes sitting here in front of me, and could literally swap the names in the header and you wouldn't be able to tell the difference.

So, we make a first pass, weeding out those who a) can't write, even after the headhunter has spiffied their CV, b) are scant with details, and c) hop assignments every three months. The rest have to do a preliminary interview, and that mainly consists of determining whether or not they actually know any of the stuff that their resume's been padded with. Sure, we ask the traditional interview questions, but we also do a base knowledge test. You would be surprised how many .NET "programmers" we get who don't know the most basic C# operations, web developers who don't know the difference between POSTing and GETting form data, and "7+ years experience SQL" applicants who can't tell you how a left outer join works.

Programmer's resumes are becoming increasingly useless, especially when you're flooded with nearly identical H1-B applicants with the same vague academic credentials (ie: "BS Elec. Eng., India", "Masters of Computer Applications" - no institution listed, "Bachelor of Engineering" - no discipline given), identical alphabet soup, and interchangeable litanies of 6-month contracts scattered about the country. They all have widely varying levels of competence that is in no way obvious from their resume. They all have "7+ years experience." That's what makes up 90% of the programmer pool these days, and even if you're in the top 10% with verifiable credentials and a real track record, you're gonna have to go through the same process. Because those of us on the hiring end can't tell anymore from your paperwork, without giving you some sort of objective evaluation of skills, syntax, and basic concepts.

It's been the rule for some time now. Ten years ago, it was all of the newly minted MCSEs rolling out of the fly-by-night tech schools. Before that, it was the "paper CNA/CNE's" who were able to sit the Netware exams and pass by the grace of their deity of choice. And there have always been the code-monkey grindhouse diploma-mill shops, who crank out "programmers" in the language du jour - especially since the web boom - CGI, Java, .NET, AJAX. All with credentials like "Doctor of Divine Coding" and the real competency of an ADD third-grader.

So, don't take it as a personal insult. You may be better than all of the above, but no one can determine that from a piece of paper, a firm handshake, and a good story about how you were the lead coding god on your last project. 'Cause there's a dozen other applicants out there with the same spiel.