Perl Catalyst and Cloud Computing

Jul 16, 2008 at 9:26 AM
8 comments

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.

Q. What is Cloud Computing and why is it important to Perl?

Cloud computing is on-demand, virtualized computing. You don't need to own the hardware, or even see it, in order to run your software.

Most cloud computing providers offer the ability to pay-as-you-go, and to buy computing power as you need it. In many cases, you configure a "machine image", which is a base OS install plus all of the stuff you'd like to run on it, and then you’d freeze it to use when you spawn up an instance of that machine image.

This is the natural outgrowth of "commodity computing". As a software owner, or software builder, you really care about access to computing power, and that is scalable and available. Cloud computing solves a lot of problems that have been a real issue for growing businesses or businesses with peak load times. You used to have to plan to carry enough hardware to cover your peak, plus some additional room for insurance. Now, you just have to be able to balance and scale your application if you have thought about architecting in such a way as to allow your app to scale horizontally.

If you properly design your applications so that you can scale them by balancing / routing requests, you can build machine images or application profiles of what you need, and as demand for them increases, you can scale horizontally. There are Facebook-app-specific cloud computing instances out there, as those apps are self-contained in scope by nature, and it lends itself very well to provisioning only when demand warrants it, but large organizations can take advantage of this type of thing too. For instance, why would you run a machine that costs $3-8 per hour with power and maintenance factored in, when you can run a machine for 1/10 to 1/20th of that -- so long as the stability for such a thing has been demonstrated? If there's a way to mitigate that risk, it's almost your duty as an IT Manager to make sure thos cost savings are realized. There are companies like GoGrid, Joyent, Amazon and Terremark all operating in this space, in slightly different ways. The opportunity to cut your costs is out there, though.

Q. What Cloud Computing related projects exist for Perl developers?

Currently, there are only two Perl projects relating specifically to cloud computing of which I am aware. There's Jeff Kim's great work on Net::Amazon::EC2 (http://search.cpan.org/dist/Net-Amazon-EC2), which allows for the management of Amazon's virtualized services through a Perl API, and then there's the Net::Cloud (link forthcoming) project. I registered that namespace about two years ago, but back then there was only really one viable cloud computing option, and it was a closed Beta, which I was fortunate enough to get into with a recommendation from Ruv Cohen over at Enomaly (a provider of cloud management software). The project is due for its initial release on CPAN within the next few weeks. I'm working to roll in as many initial cloud provider services as has been feasible. Some of my work extends Jeff Kim’s Net::Amazon::EC2 modules and I have to give him a lot of credit because he was the first one to do a lot of this stuff, so when I needed to settle on a standard, I went with what Jeff had done.

Q. What is the best way for a Perl programmer to get started developing for the Cloud?

There's already a big resurgence in Perl around the Catalyst (http://www.catalystframework.org/ ) MVC framework, headed up by Matt Trout, and Moose (http://search.cpan.org/dist/Moose) by Stevan Little. I think people should give those a look, because it gets them developing with a proper design pattern that is well suited for projects that organizations want completed RIGHT NOW. To that end, I went and set up two machine images over at Amazon's EC2 that have everything you need to get up and running with an MVC framework, in the time it takes you to register an account and read through the instructions.

The machine ids at Amazon are:

ami-bdbe5ad4 developer-tools/Debian-Etch_Catalyst_DBIC_TT.manifest.xml

ami-9fbe5af6 developer-tools/Fedora8-Catalyst_DBIC_TT.manifest.xml

You have one instance with Debian (Etch) and one with Fedora8. Take yer pick. The Debian instance includes svk and git, but aside from that, there’s pretty similar in terms of what you can do. I set them up in such a way that if you actually do something that gains traction, there’s source control there for you to call in the cavalry. Just remember to save your work somewhere, because if a cloud instance is terminated for any reason, you lose your unsaved work.

The effort to get up and running ON the cloud is minimal -- and it should be. Architecture and scaling, which has been like a black art for years, shouldn't be so difficult. There's plenty of room to be clever, so smart folks will always be employed in this field. There are better problems to solve. Porting existing apps and building Perl (http://www.perl.org/ ) extensions to make that possible are a great way to get paid while you use cloud services. There’s also a real need and opportunity for Perl development in many organizations to simplify architectural designs that grew out of dive-from-the-hand-grenade necessities of scaling to meet demand. In this economy, saving people money is not going to go out of style.

I remember the first time I saw Brad Fitzpatrick's slides on how he grew LiveJournal (http://www.livejournal.com/), and I remember thinking, "Wow, that is briliant, but it is also crazy." He has a slide in there specifically intended for people not to faint, because that's how complicated it grew to be, managing all those devices. I mean, all that hardware was just amazing… AND IT WORKED! The fact that LiveJournal and Danga produced all that great stuff is a testament to the folks that worked there, and they were doing their thing well in advance of this whole emergence of cloud computing. But the fact is, Brad Fitzpatrick and his team isn't available everywhere, and the risk associated with trying to duplicate that would prohibit most places (in fact all but a few) from ever replicating that success.

Nowadays, you have cloud computing, Hadoop filesystem (http://hadoop.apache.org/), perlbal (http://danga.com/perlbal/) and memcached (http://www.danga.com/memcached/) (thanks Danga!), and either squid or commercial reverse proxy systems. A lot of these can both be moved to the cloud and be made more service-like. This is right up Perl’s alley. The more you can decouple the service from the hardware, the better off you’ll be in your organization. Unless your organization makes its money by selling hardware solutions coupled with software. In which case, grab a life raft now.

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.

Q. What are the next steps for your Cloud Computing plans related to Perl? Where would you like to see Perl in the Cloud Computing space over the next 18 to 24 months?

The goal of this project is to allow for the basics, and build from there. You should be able to start, stop, load balance and cache across one or multiple clouds: think "DBI for cloud computing" with the various "condensers" for each cloud provider or virtualization API being congruent to the DBD effort that has proven a very successful and economical Perl implementation in many organizations. Perl is great at integration, and holding things together. As such, it makes an excellent choice for a transfer layer among computing services. Now that the basics of the project are in place and we’re about to roll out the initial release, there will be quite a few opportunities for Perl developers to get involved in contributing to cloud computing. There’s a lot of brilliant Perl developers out there, and I think that they only get amped up about new and improving technologies. The potential of virtualized cloud computing is enough to do that, I’d hope. I am inviting anyone that wants to contribute to the project. There’s room enough for everyone, and this type of project is going to have a few different outgrowths. There’s a lot of room for involvement.

The first step is to make a very stable and portable interface to all cloud and virtualized environments. We want to enable people to get up and running on a cloud and demonstrate that it is real, it works, and is viable. The way to do this is to develop the gateway that allows people to make this happen, and make it as easy to use as possible. I think with this release of Net::Cloud, I have that covered.

From there, we will split the project into providing architectural support and portability, and then allowing access to a growing number of specialized instances across all the clouds. There will be caching-specific instances, genomic computation specific instances, and possibly neural networks, but it doesn’t need to be so academic, either. The idea is to provide a uniform interface layer for people to issue publicly available software as a service (if I can borrow a buzz phrase), and make that easy for developers to tie it all together. Although I plan to build a gateway REST-based service for access to one or multiple clouds, I don’t intend to keep it specifically Perl-centric. The idea here is to provide the bridge and standardize, hopefully letting the good languages (more specifically good developers) rise to the top.

Looking longer-term, I would like to see a lot of IPC stuff move to allow for slower-but more scalable transport across the cloud, or multiple clouds for redundancy. I am not talking about simple "virtualization" in the sense that comes built into machines rolling out of the systems manufacturers. I mean actual "virtual process communication". Also, databases should be segmented to make full use of the cloud, clustering and replication and anything you can replace in a database using Hadoop or GFS will probably happen sooner or later, depending on how easy and reliable we developers make it, to make the leap. I think that stuff is maybe two years out, but it’s coming. It won’t be long before that type of talk is not taboo among large organizations. My advice would be to start pitching the seeds of these ideas now, and build up acceptance in your organization for them.

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

Q. Can Perl's Cloud Computing projects do anything to assist people who are using other programming languages?

Absolutely. Like I alluded to in the last question, I’m looking at this as a way to extend many existing computational limitations. If you have an existing project, setting up cloud images and using a REST-based call to a server running Net::Cloud should help a lot of people doing things that don’t have much to do with Perl at all. The idea is to make it so that someone doesn’t need to master the ins and outs of Perl, Catalyst of Net::Cloud to use it.

I would love the help of other front-endian developers doing Ajax and UI work to help build some slick tools to go on top of this stuff, that we would ship with existing cloud management instances, or deploy on you local machine to get up and running, a la YUI.

Q. What can the community do to help? What are the current communication channels (mailing list, IRC, etc).

When this release hits, register for some cloud services, and try it out. Start a few machine instances, stop them, and then pick one or two services which you’d want to test scale for. Maybe it’s encoding video formats, or managing sessions. If you make a plugin that works, abstract it and I’ll gladly include it in Net::Cloud and mention you in the release notes as a contributor.

Aside from that, I want to do something here that the Perl community has traditionally overlooked. I want to put a polished package on this, that includes an easy-to-install, easy-to-use interface. I don’t care if that is “trivial”. I think the missing piece for wider co-operation and adoption here is just a cloud solution that looks good and the price is right. The fact that this release is free should satisfy at least one of those requirements.

Currently the best place for discussion is(IRC) #net-cloud at irc.perl.org

Q. A little about yourself, your interest in Perl and what inspired you to start with Cloud computing. Also, some details about your role related to some of the discussed projects.

I have been interested in computing -and generally taking things apart to see what they do- since I was an early age. Sometimes I was even been able to put those things back together. This tendency sort of led me out of the business program in college, and into building web sites and doing commerce-based stuff. My first non-static website was built with hand-rolled Perl CGI, then I had a go with Java, then back to Perl. I’ve worked with PHP, Python, Ruby, and now back to Perl. I keep coming back to Perl because it seems to create resourceful bridges amongst diverse systems. This is a reflection of the people in the community as well as the language itself. I have never considered myself painted into a corner with Perl. It’s improvisational enough to do new things, but has voluntarily enforced conventions enough to make it work at scale. Sort of like a reflection of a healthy society, in a way. I do not think this was an accident on Larry Wall’s part, but that’s a topic for another discussion.

People say that bad Perl code is unreadable, but I’d say that code that doesn’t run is worse than code that doesn’t read well. There’s varying degrees of cleverness, readability and elegance in all languages and it’s a balancing act. I think Perl and the community around it is full of intelligent and motivated people that are necessarily skeptical and inquisitive. Some code is great and some isn’t. There’s a guy, a legend basically, Paul Lindner at Hi5 right now, and he has a knack for taking a complex problem and solving it in a simple, solid-state way, and being pretty accommodating to anyone that has to read the code. That’s the kind of Perl we should all be shooting for. There’s another guy I met while in Boston.pm, named Ronald J. Kimball, and he writes some impressively well presented code as well. Some of these guys have moved up and moved on, because their skill set is so valuable, but I think the culture we have in place in the Perl community still breeds that type of meritocracy. Stevan Little and the Moose guys are an example of that. They're doing great stuff. The team at Shadowcat is doing great stuff as well, and the Moose, Catalyst and DBIx::Class communication channels are very active and helpful.

My involvement with this cloud initiative is that I am the author / maintainer of the Net::Cloud modules and namespace, and I have been using cloud computing services since Amazon made them available in 2006. I had a semi-successful Beowulf cluster cobbled together with some buddies back in maybe 2001 or so, so it has always been interesting to me to use and share excess computing power. I even ran that SETI app when it first came out, but I stopped when it produced no publicly reported aliens ;) .

Recently, I see how it has become impractical to have to sustain a static top-end of your computational ability. It’s expensive, and impractical, especially if you ever start trying to solve bigger problems or scale. To that end, I have started this project and I’m working with some great folks on getting it off the ground. I’m looking forward to building on this, because I think it is the next frontier in computing and connecting systems. There’s already a bunch of bright people involved with it, and there’s always something new to learn or to try while paying the bills, which is why most of us got into this profession to begin with.

Some additional resources:

Note: I followed up with IBM regarding their OnDemand services and how there were positioned against Cloud Computing services such as Amazon's EC2. I received the following email 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. "
http://www.ibm.com/Search/?q=ondemand&v=16&en=utf&lang=en&cc=us&Search=Search

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.