Let’s Answer The Question: What is Cloud Computing?
Buzzwords and acronyms are a mixed blessing.  On one hand, they are a very useful shorthand for those who are ‘in the know’.  However, for those who have no idea what it means, a phrase like “Web 2.0″ or an acronym like “SEO” can be a barrier to understanding, and for those who are too ashamed of their ignorance to ask, they risk using these terms incorrectly.

One of the newer phrases being bandied about is “Cloud Computing”.  In order to take the mystery out of the term (and allow us to use the term correctly), let’s answer that question:  What is Cloud Computing?

Getting Virtual With Your Servers
To understand Cloud Computing, first you have to understand the concept of Virtualization. Virtualization is the ability to run several standalone disk images on the same server.  Being able to create an image of your machine is technology that we’ve been using for years.  A typical machine backup involves making an image of the machine and pushing it to another server.  Then, when you need to restore your data, you can simply load the disk image onto your new hard drive.

Virtualization is just like this, except you take this disk image and you run it.  It’s like having an OS inside of another OS.  So you might have a Linux machine that is running several different Virtual machines, disk images that were created and loaded onto the server and assigned an IP address so that you can hit that virtual machine directly.

A Traditional Server Is A Great Big Desktop Computer On Steroids
A traditional server is a great big desktop computer on steroids, with hundreds or even thousands of different websites running on it.  They usually will share a single SQL server, run under the same OS, and everything on the server rises and falls together.  So if Site A has a big day and receives a hundred thousand requests, it can impact the performance of Site B because Site B resides on the same server and shares resources with Site A (and about a hundred other sites).

There are notable downsides to this traditional approach, namely:

• Hardware Expense- When hardware breaks or gets old and obsolete, you’re going to reinvest in the server that’s been purchased.
• Inefficiency- Of the 100 sites on a server, do all of them really need access to 16GB of RAM?  You’re usually increasing your server resources to account for 1 or 2 very busy/intensive sites on a server.
• Shared Risk- When the hard drive of your server fails, every site on the server is going to suffer.  When the OS encounters a “blue screen of death” sort of error, it’s going to bring down the entire server.  Why should 99 sites suffer for the failure caused by a single site?

There Is A Better Way Up In The Clouds
“There’s got to be a better way!” cries our paid sponsor, and there is.  Virtualization offers us the ability to grant every site its very own server, at a fraction of the cost.  The hardware doesn’t really matter, because you’re only going to allocate a small portion of system resources to each virtual machine.  So even though the server might have 16GB of RAM available, “Bob and Jo’s Kitty Cat Site” might only need a max of 256MB of RAM to run smoothly.  If we need to ’scale up’ and provide extra system resources for Bob and Jo’s Kitty Cat Site, we can do that easily and tell our server to allocate 512MB of RAM to the server instead.

This resolves the issue of shared risk, since if Bob and Jo’s Kitty Cat Site encounters a horrible error that requires a restart, you’re only restarting the Virtual Machine that runs on the server, rather than the entire server itself.  Service Interruption for a single client, rather than everyone on the server.

This also resolves the issues of efficiency and hardware expense, because at a more granular level you can assess the resource requirements of a site and limit a site to only using the resources it needs, rather than infringing on the resources needed by a more resource-intensive site.

With these advantages, it is no wonder so many companies are moving apps into “the cloud”.  Cloud providers like Amazon EC2 and Rackspace offer a very tempting proposal:  Create as many servers as you want for a fraction of the cost of doing things “the old way”.  Backups and maintenance on the hardware are handled already by the cloud providers, all that a web hosting company has to do is make sure that everything is running smoothly within the virtual machine itself.

Cloud Computing Offers An Inexpensive & Hassle-free Solution
Hopefully this has de-mystified some of the questions regarding Cloud Computing.  ArcStone has been using this capability for some time in managing our own servers, and after all of the advantages provided to using this method, it’s hard for us to imagine ever going back.

Of course, this solution is not the right one for all situations, and you should first evaluate the pros and cons of hosting a physical server of your own versus utilizing a cloud computing strategy.  In most web apps, however, cloud computing offers an inexpensive and hassle-free solution for your hosting needs.

If you’re interested in learning more about ArcStone’s hosting options see our email and web hosting services page.

As was recently announced, Railo, the open source CF engine, has finally given ColdFusion to the masses.  March 31st saw the release of the first 3.1 public beta, providing full feature compliance with Adobe’s ColdFusion 8 standard, and allowing developers to begin porting over existing sites to Railo.  The ability to port over existing sites, or to spin up entire servers for a client without running into the pesky licensing costs of ColdFusion is one of the developments that has me the most excited about Railo.

Previous versions of Railo (including the promising but ultimately not CF8-compliant and buggy 3.0) have been known to provide phenomenal speed increases, but without the ability to fully support the CF standard there have been compatibility issues with web software firms attempting to make a move to Railo.  This, combined with a lack of true enterprise capabilities led many to dub the platform unready for prime time.  Railo 3.1 is about to change all of that, at least once it is finally out of beta.

I have not yet had time to play with Railo 3.1 too much, but they provide an express install that isn’t really an install, so it has been very easy.  Just extract to a folder, double click the ’start’ script to start the application/web server, and then you can immediately browse to it at http://localhost:8888.  Drop code into the Railo webroot folder, and you can start testing existing apps against Railo.  The administrator for Railo 3.0 was very sparse compared to the CF administrator that ColdFusion developers know and love.  Not so with Railo 3.1.  The server adminstrator which manages the more global settings has a separate password from the web administrator, and there are numerous settings available, many specifically tailored towards compatibility with CF8, but there are also enhancements beyond what Adobe provides. Additional enhanced selections within the administrator, such as “convert 0000-00-00 MySQL dates to NULL” seem like a sensible upgrade to the default behavior of CF, others probably depend on the needs of your application.  Missing at this point in the release is the much ballyhooed cfvideo tag, a cluster scope (though Railo supports J2EE sessions at this point), and clustered caching.  With a CF license costs no longer at issue, expect Railo’s clustering functionality to get a full workout in the coming months.

Installing extensions, and restarting the cf service are available within the administrator as well.  Things like Galleon forums, the Mach-II framework, and other open source CF goodies.  Additional providers can be added via the server, too, (this works very similarly to how plugin providers are added via the Eclipse IDE) and updating the server software is also possible within the Railo admin itself.  One of the weirdest things for anyone that has restarted a ColdFusion service before is that Railo’s cf restart is darned-near instantaneous.  Everyone gets logged out on the server, as sessions and other scopes are cleared, but other than that, there is no painful delay waiting for the service to kick in while site visitors are crashing into technical looking 500 server error screens as is so often the case with a typical ColdFusion restart.  It’s…eerie.  It is also a distinct improvement, but performance has always been Railo’s most promising and consistent offering in their platform.

You can bet that many people across the internets have been tinkering with Railo 3.1 lately, especially in tandem with Amazon’s EC2 or similar cloud service, in order to provide things like open source load-balanced J2EE session-scoped cluster farms.  Suddenly, stunningly, ColdFusion developers are now enjoying something that PHP developers have been able to enjoy for years.  I welcome an open CF8 standard (whether Adobe has created or simply joined the CF standard is unclear) and a fully-featured open source ColdFusion application server.  It is clear that this can only mean good things for CFML and ColdFusion developers in the future.

What is not so clear, however, is how Railo’s other open source competitor Blue Dragon has fared, but with many members of the Blue Dragon team leaving (and some of them joining the Railo team), chances are that it will not fare very well.  Equally unclear is Adobe’s opinion on Railo, and how its official release might come to affect its bottom line.  Whatever the case, the cat is out of the bag now.  We’ve seen the future, and the future is open source.

Viva la Revolucion!