Eight years ago I was sitting in a focus group sponsored by IBM, who was interested in seeing the reaction to a potential product offering they called, "Utility Computing". The pitch was a solution to a classic problem faced by all administrators of IT infrastructure, which is to find the correct mix of anticipating growth versus making good use of existing equipment when planning hardware procurement. In the classic data center model, a company would manage expensive stacks of hardware, much of which would be underutilized due to the fact it costs less to have extra equipment than to run the risk of not being able to scale. However, few companies have the unlimited budget required to plan for every possible IT contingency. IBM's basic idea was that your computing resources could be provided to you from an external utility service, in the same way as electricity and water, and if you needed more you could simply, "turn the tap". This could save a company a lot of money, since you'd only pay for what you used. Additionally, you'd reduce the risk associated with failing to plan correctly for increases in a company's IT requirements.
The concept of Utility Computing was well received by our group. Most of us could see the benefits. Objections included some fear over allowing important company assets, such as proprietary information stored in our data warehouses, to reside outside company walls on the equipment of a third party, possible even on hardware shared by competitors. For some of us in regulated industries there were legal concerns about data security. In the end, the consensus around the table was that such a service could find a home in our respective infrastructures, but it wouldn't replace them.
The Utility Computing concept IBM showed me was primarily targeted at large companies who were trying to reduce the risk and costs associated with maintaining large data centers. In contrast, Cloud Computing services, such as Amazon's EC2 (http://aws.amazon.com/ec2), are accessible even to small companies or individuals operating on a shoestring budget. Anyone can create an account from their web browser. This opens up all sorts of possibilities. It can allow a startup to scale quickly without having to incur the expense of purchasing or leasing expensive equipment. It can also allow an established company to purchase extra computing power when they need a place to experiment but don't have available internal resources. Lastly, the availability of prebuilt 'images' for most Cloud Computing providers can allow you to very quickly roll out a new service to your clients, as long as a server image for your need exists.
Recently I had the change to speak with Frank Speiser, who is leading several Cloud Computing projects that should be of interest to the Perl Community and to Catalyst developers in particular.
"Thank you for your feedback to the On
Demand Community site. We are the volunteer site for IBM employees and
retirees not the On Demand Business site. I did search on www.ibm.com
and the link below provides information about On Demand Business. I
hope this provides the information you need. "
Q. What is the best way for a Perl programmer to get started developing for the Cloud?
Having these images are a big time saver for people wanting to get started using Perl and Catalyst. Catalyst can take some time to install, particularly if you are limited to an older version of Perl. Here's a recent article with a step by step plan to getting started with EC2: http://www.onlamp.com/pub/a/onlamp/2008/05/13/creating-applications-with-amazon-ec2-and-s3.html
Additionally, look to the future to see documentation about how to get started with the Catalyst EC2 images integrated into the core Catalyst manual. Or see the online documentation at Amazon: http://aws.amazon.com/ec2
Come back soon when we have a screencast video showing step by step how to get started using the EC2 Catalyst development machine images.
For the non Perl developers, the mentioned modules 'DBI' and 'DBD' refer to the database access framework used universally in the Perl community. DBI is similar to ODBC or JDBC, while DBDs are database specific drivers. For more information see the documentation at: http://search.cpan.org/dist/DBI
Some additional resources:
However I found the search page that link returned to not be very useful. I send a request for additional information and will relate anything I receive in response.
"Thank you for your feedback to the On Demand Community site. We are the volunteer site for IBM employees and retirees not the On Demand Business site. I did search on www.ibm.com and the link below provides information about On Demand Business. I hope this provides the information you need. "