eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The corner of cloud computing known as platform as a service has been heating up over the past year, with new products and projects coming online that are aimed at abstracting away application deployment details and enabling developers to focus primarily on their code.
Early on, most platform as a service (PaaS) options have favored languages such as Java and Python, paired with largely open-source application stacks. With the exception of Microsoft’s own Azure service, most of the PaaS focus has been aimed away from Microsoft’s .NET framework and its corresponding stack.
Recently, however, this situation has been changing, with the emergence of .NET-targeted options such as Apprenda Inc.’s Apprenda 3.0, which enables organizations to deploy their own .NET PaaS atop the Microsoft Web application stack.
Apprenda 3.0 is private PaaS, which can be installed either on a company’s on-premises infrastructure, or in a public cloud, such as Amazon’s Elastic Cloud Compute (EC2) service. Organizations install the Apprenda software on one or more machines, and the product arranges the application and database server components into a single hosting platform.
I tested Apprenda 3.0 on a single Windows 7 machine in our lab, with a focus on the developer-facing aspects of the product, such as its amenability to hosting pre-existing applications. I found getting up and running with the product easy. It was also easy to deploy standard .NET applications with only modest modifications.
Based on my tests, I recommend that individuals and organizations deploying .NET applications take Apprenda out for a spin themselves to determine if its deployment model can make their lives easier, and free up more time to focus directly on their applications.
Fortunately, the product is easy to try out. The Express version of Apprenda is free to download and use, but is limited to 12GB of RAM across the cluster of systems managed by the product. Pricing for the full version of Apprenda is based on the amount of RAM in one’s managed cluster. For more information on the two versions, see this rundown at the Apprenda Website.
Taking Apprenda for a Spin in the Lab
I kicked off my tests by downloading Apprenda Express and launching its installer on a machine running the 64-bit edition of Windows 7. The installer checked for the Microsoft Web stack dependencies it required, and prompted me to provide any missing elements before continuing. I managed to pull down most of what I needed using Microsoft’s Web Platform Installer tool, including IIS 7, SQL Server Express Edition and an Express edition of Visual Studio.
I also downloaded and installed the software development kit for Apprenda, which came with solution templates for Visual Studio. For my first project, I used an Apprenda solution template to create a simple, database-backed “hello world” application, as laid out in the product’s developer tutorial. After writing and building my application, I ran the project through a deployment archive builder, which also shipped with the SDK.
The templates and archive builder got me started with the folder layout I needed for deploying to Apprenda, but as I soon learned, it was easy enough to adapt existing projects to run on the service without calling on the templates at all.
To get a feel for deploying existing applications on the service, I picked out a few popular open-source .NET applications from Microsoft’s Codeplex project foundry. I started with the aptly named BlogEngine.NET, which I configured to use a database back-end, rather than its default XML back-end, as described in the project’s documentation.
Next, I set the database connection string for the application to $#APPLICATIONCONNECTIONSTRING#$, a wild-card value that the Apprenda system swaps out for the correct value at deploy time.
Once so configured, packaging the code into an Apprenda deployment archive involved placing all the project files into a directory named “root,” which itself sat in an “interfaces” directory. The BlogEngine project archive included a SQL script (MSSQLSetup2.5.0.0.sql) for creating the tables it required. I renamed this file to ApplicationProvisioning_Script.sql, and placed it in a directory named “scripts,” within a “persistence” directory. I compressed the persistence and interfaces directories into a zip file, which was then ready for deployment.
I also tested with Umbraco CMS, which doesn’t ship with SQL scripts for setting up the tables. Rather, the Umbraco installer creates its tables during initial set-up, and needs only a database onto which to install. For this case, I included a blank ApplicationProvisioning_Script.sql script in my deployment archive, which was sufficient to prompt Apprenda to create a blank database for use with the application.
Once running, the Umbraco CMS installer asks for credentials for the database associated with it to complete the installation process. I was able to access these credentials from a data management console in the Apprenda developer portal.
The third application I chose for testing was BugNET, which ended up requiring file and folder permission settings changes not accessible to an Apprenda developer. To get the application to work, I would either have to modify my Apprenda installation to make the requested permissions changes, or modify the application to no longer require them.
For each of my test applications, once I’d come up with my deployment archive, I visited the Web-based Apprenda developer console to give my application a name and description before uploading its deployment archive to the service. After uploading the archive, the Apprenda system would check to ensure that necessary elements, such as a valid database script, were in place, and if pieces were missing, the console would prompt me to provide them.
For instance, when I uploaded my Umbraco CMS deployment archive, the system notified me that the project’s use of “configSource” attributes to reference separate configuration files in the project’s web.config was unsupported. As suggested in the error message, I folded these configuration elements into the main configuration file.
To test my applications, I then would promote them from development to sandbox status, where I could launch them, carry out any additional configuration steps through the browser, and give the applications a run-through before promoting them from sandbox to production status.
With each redeployment, for instance, shifting from sandbox to production, the system wiped the databases associated with the applications.