The Cloud Foundry PaaS team recently announced Cloud Foundry Core as a way to make it simple for PaaS customers to discover the services and platforms supported by each Cloud Foundry provider. The provider platform, such as CenturyLink Platform as a Service, is interrogated live to show the latest services and frameworks that are supported. But does this really matter? Is portability overrated? While your business applications are probably not leaping between environments on a daily basis, portability does greatly improve deployment choice and disaster recovery options**.
Let’s see how this plays out in real life. I built a sample application that used Node.js for the web layer and PostgreSQL for the database layer. My goal is to quickly and seamlessly move this application between development (Micro Cloud Foundry), test (CloudFoundry.com) and production (CenturyLink Platform as a Service) environments.
Deploy an Application to Micro Cloud Foundry
Micro Cloud Foundry is a fully encapsulated virtual machine that surfaces all of the Cloud Foundry services. Developers can work with this local cloud to build and test their applications before deploying to a production-quality Cloud Foundry environment. This offering differs from the development fabric offered by other clouds in that it’s a complete clone of the cloud offering. There aren’t weird differences between the developer environment and the cloud itself. With Micro Cloud Foundry, developers get the same exact deployment, configuration, and management experience as with any Cloud Foundry providers.
To begin with, I spun up a new Micro Cloud Foundry instance.
On my local machine, I built and tested my Node.js application and was ready to push to a “cloud.” Because Micro Cloud Foundry supports the Cloud Foundry interface, I could use the standard vmc command line tool to target my Micro instance and push my application.
I also added a PostgreSQL application service to this deployment.
In a matter of seconds, my website was published and I could see it online. Note that Cloud Foundry automatically takes care of identifying the right port for Node.js to run on, regardless of what’s set in my app.js file.
All that was left to do was to add and configure my PostgreSQL database. Cloud Foundry supports a tunneling mechanism (called “Caldecott”) that lets me connect from my local machine to my PostgreSQL instance in Micro Cloud Foundry.
After opening the tunnel, I launched the PostgreSQL management tool (pgAdmin) and connected to my PaaS database.
I then took a backup copy of my local PostgreSQL database and restored it to this new Micro Cloud Foundry instance.
At this point, you’d think that I’d have to go into my Node.js application and update my database connection string to reflect the host, username, and password of this instance. However, Cloud Foundry does some awesome auto-reconfiguration of (Node.js) applications that injects my credentials for me! Because I used the very nice node-postgres Node.js module for my database access, I got this Cloud Foundry-supported auto-configuration magic for free. Once I added my table to the database, my Node.js application could instantly read the data.
Move an Application to CloudFoundry.com
I had the full cloud experience while my application resided in Micro Cloud Foundry. However, that environment is not meant for demonstrating scale-out or making an application available to other developers or testers. So, I had to migrate my application to a bigger, more widely-accessible environment. CloudFoundry.com fit the bill.
The first step was to use the same vmc tool to target the public CloudFoundry.com cloud. I then deployed the same Node.js application, and chose to create a new PostgreSQL instance.
Just like before, I tunneled into this new PostgreSQL instance, acquired the database credentials, logged into the database, and restored the table backup. Because of all the auto-configuration magic mentioned earlier, I could immediately view my application without having to change Node.js connection strings or runtime port numbers.
Move an Application to CenturyLink Platform as a Service
At this point, the application was sitting in a very capable public cloud. However, what if you needed more than what this particular cloud provides? Maybe you want access to CenturyLink Cloud’s world-class, global infrastructure cloud to compliment your PaaS applications. Or, you’re looking to use our well-engineered management software that offers self-service features for server provisioning, environment orchestration, group management, disk resizing, firewall policy rules, and much more.
The CenturyLink Cloud Platform as a Service is a .NET-friendly (but fully Cloud Foundry capable) version of Cloud Foundry. Customers can provision as many Platform as a Service clusters as they want from the CenturyLink Cloud Control Portal.
To send my Node.js application to Platform as a Service, I first targeted this environment from the vmc tool, and did a push of the code.
Just as before, I tunneled into my PostgreSQL database instance and restored my database backup. Once again, my application could instantly access my database and show the table records.
It literally took less than five minutes to take a database-driven website application and move it from one Cloud Foundry provider to the next. There were no application settings to change or strange machine configurations to remember. Simply take the same application and push it to a different provider with a single deployment tool. We hope that you find CenturyLink Cloud to be an exceptional home for your PaaS applications, but we also want you to be confident that your applications can enter and leave our environment whenever you want.