Building Everyday Web Apps as Cloud Apps

news
1
By Dennis Clark

In late September, Geoff Bowers, Director at Daemon, gave a fascinating talk at the Adobe Platform Users Group Sydney (APUGS).

The talk was titled “Building Everyday Web Apps as Cloud Apps”, but Geoff was really telling a personal story: his 15-odd year journey from “SysOps” through “DevOps” towards “NoOps”.

Geoff’s journey arose from his frustration with needing systems administration for the servers in his software development firm back in the late 90’s. Why can’t the systems just work so the developers can focus on building great apps? Is there a better way?

During the “naughties”, datacenters and Infrastructure-as-a-Service (IaaS) became more commonplace. At this time Geoff migrated some of his hosting to a virtualised server hosting firm Bulletproof Networks, and later started using Amazon’s EC2 service. These products solved the problem of maintaining the hardware, but the problems of configuring, maintaining, and updating the operating system and platform were as big as ever.

Looking for alternatives, Geoff came across “Stax”. Stax was a company founded by ex-Allaire engineer Spike Washburn (small world!) and offered a Platform-as-a-Service (PaaS) product for Java applications. Stax was new and complicated and Geoff didn’t feel like it was ready for Prime Time, so he moved on to other options.

There were other PaaS offerings around at the time, but none of them were particularly appealing. Heroku was popular for Rails, but deploying Java applications required compiling and uploading a full WAR file; a painful-sounding proposition for large applications. Amazon has a Java-based PaaS called Elastic BeanStalk, but working with it requires the use of the Eclipse IDE. After spending many years putting up with CFEclipse’s quirks and finally dumping it (first for TextMate and then Sublime Text), Geoff was loathe to go back.

He then came across Vagrant: a system for scripting virtualised development environments. Vagrant is a tool for “DevOps”, a methodology that ties development with operations. DevOps looked like the answer! If he could script the setup of the development environment as a Vagrantfile and include it the project’s source code, any developer could type “vagrant up” and get a running development environment for the project in minutes!

Well, that was the theory anyway. Vagrant offers a number of different provisioning systems to configure Vagrant environments. Geoff decided to try Chef Solo: unlike the older and more ubiquitous Puppet, it doesn’t require a server infrastructure for deployment and is based on the standard Ruby language instead of a custom scripting language. He spent months studying Ruby and learning “the Chef way” of provisioning Vagrant environments. While some progress was made, in the end it felt like DevOps was just another form of SysOps: you still needed knowledge of system infrastructure to set it up, and the only real difference was that the infrastructure was now virtualised and scriptable. It would be better not to have to deal with the infrastructure at all!

Meanwhile, some success was found with integrating cloud-based services into Web applications. Daemon had some clients that required video transcoding in their Web applications. The bespoke transcoding solutions Daemon developed worked, but they were difficult to maintain, so Geoff looked into BrightCove: a cloud-based video platform founded by none other than ColdFusion creator Jeremy Allaire (small world again!). BrightCove handled not only the transcoding of videos, but also the playback: the player could optimise playback based on the device and network, and a JavaScript API provided a lot of control over the playback interface.

Video wasn’t the only application functionality that could be outsourced to the “cloud”. Not all cloud-based solutions turned out to be better than their “physical” counterparts. For example, Amazon RDS is good for running a backed-up SQL database server, but the Microsoft SQL Server version has some painful constraints on backing up and restoring databases; however, Geoff did find some great uses for cloud-based services in Web applications:

  • Amazon S3 to store content-managed assets such as uploaded images
  • Amazon ElastiCache for front-end caching of Web site content
  • Amazon SimpleDB for no-fuss NoSQL storage (he used this for his rewrite-in-one-weekend of his newsfeed aggregation site fullasagoog.com)
  • Raygun for error tracking
  • Cloudinary for image processing

During the presentation, Geoff demonstrated the power of Cloudinary by logging into the webtop for a FarCry site that had Cloudinary support, uploading an image and then cropping it. The default cropping implementation in FarCry uses the built-in tags in CFML, but that requires a lot of processing and the server can take a few seconds to process it. For clients that did this regularly, Geoff would have to spec out beefier servers than normal to handle the load. With Cloudinary the cropping took less than a second from his laptop. Integrating Cloudinary into FarCry Core was almost trivial: Cloudinary API calls are simply URLs that embed the source image location along with the image processing instructions.

Geoff recently took another look at PaaS and discovered that Stax Networks had been purchased by CloudBees (the largest commercial support provider for the Jenkins Continuous Integration server) and the Stax technology had been integrated into a new PaaS.

The CloudBees PaaS consists of 3 major components:

  1. The CloudBees SDK for local development
  2. DEV@cloud for integration and testing with Jenkins
  3. RUN@cloud for production deployment and monitoring

Geoff showed how a simple Railo site could be dropped into a local CloudBees SDK project and started and stopped from the command line. He then showed the various tools to configure the application and related cloud-based services such as New Relic for performance monitoring and Papertrail for log management. Finally, with a couple of commands he deployed his new project “to the cloud” and within a minute he had a running application on a production server!

Geoff pointed out that the CloudBees PaaS stack does not use Apache so CloudBees applications cannot use Apache URL rewriting rules. Many Web applications rely on URL rewriting to create “friendly URLs” which are considered essential for SEO and deep linking, but fortunately found a JEE applet filter called UrlRewriteFilter that could provide the required functionality within the CloudBees platform.

CloudBees is the closest Geoff has gotten to NoOps, but there’s still work to do to integrate the PaaS stack into Daemon’s development process. No doubt we’ll be learning even more from Geoff about PaaS for practical Web application development in the near future.

Links:

Virtualised server providers:

Infrastructure-as-a-Service providers:

Platform-as-a-Service providers:

Software development tools (IDEs and text editors):

Integration tools:

  • Jenkins (continuous integration server)

Virtual Machine environment management tools:

Cloud services for Web applications:

Platform-as-a-Service tools: