In the cloud computing world, preserving a choice of clouds is critical. The risks of being locked into a single cloud are substantial. Cloud Foundry provides an abstraction layer for deploying and scaling applications and preserves the ability to move between clouds today and into the future.
In this guest blog, Mark Geene and Vineet Joshi, Co-Founders of Cloud Elements, a Cloud Foundry Core application developer, provide guidance on how to design cloud portable applications while not compromising performance or functionality.
Why Portability is Important
We often find that the cloud provider clients select when they first develop their application does not meet latency, uptime or redundancy requirements as their application scales.
We were struck by the experience of one customer who actually saw the incremental costs on their cloud infrastructure provider rapidly increase as their app began to grow due to the additional time, management effort, and expense in setting up servers, managing load balancers and network configuration, and continuously adjusting the application and infrastructure for high availability, redundancy and failover.
In order to change to a more suitable cloud provider this company invested over six months of development effort to unwind proprietary service integrations, including storage management, workflow, and identity management.
Developing your application using open technologies will not guarantee portability when you redeploy your application to another cloud provider. You also need to consider the interaction of these technologies within the infrastructure you select.
RDS and MySQL Interoperability Lessons
We saw this firsthand in working with a client who developed a mobile sales force automation application for the retail industry in India. During the prototyping phase they sought to minimize cost and designed their application using Amazon RDS (Relational Database Service).
As the prototype became a successful product, a number of large retail clients wanted to deploy the application in a private cloud. To their surprise, the MySQL implementation of RDS is proprietary, and migrating the application data wasn’t as simple as exporting data files from RDS and importing these into a private MySQL installation.
Some of the APIs offered by RDS were not available in the open source version of MySQL. In hindsight, they regretted choosing a proprietary service because the migration to a truly open-source version of MySQL cost them nearly two additional months of effort.
Designing Portable Applications – Stories From Customers
Based on experiences like this we’ve developed a process to guide clients in designing portable cloud applications:
- Select a PaaS first
- Make portability a key PaaS selection criteria
- Use PaaS services to drive your cloud application architecture
- Select value-add application services with portability in mind
- Loosely couple selected services
Select a PaaS First
Selecting the right PaaS has a significant impact on keeping an application portable. We urge our clients to select their PaaS before they select their IaaS provider — not the other way around. You wouldn’t select your hardware vendor and then the operating system, why would you take this approach in the cloud?
PaaS is the equivalent of your operating system for cloud applications. It provides a set of capabilities such as application runtimes and database services that are more portable if used at the platform tier than the infrastructure tier. In fact, we’ve avoided the RDS migration issue described above by using a PaaS as the provider of the MySQL database instead of IaaS, even when deploying to AWS.
Public/Private PaaS Portability
When we make portability a design criteria for our application, we make it an evaluation criteria in selecting a PaaS.
Criteria we use in evaluating PaaS portability:
- Multiple IaaS providers provide public clouds utilizing the PaaS
- Open-source is available for private and hybrid cloud deployments
- It provides application management and monitoring capabilities independent of infrastructure management and monitoring
For example, we developed an application for a client using Cloud Foundry PaaS deployed on a private cloud. We had two choices 1) use a PaaS that provides the runtimes and services for the application or 2) install, configure and manage these services ourselves. The technology stack for this application included Apache, Java running in a Tomcat container, PostgreSQL for the database and an open source NoSQL database.
Past experience without a PaaS told us it was two weeks of effort to setup the hardware/OS, install and configure Apache, Tomcat, Java and PostgreSQL before we could even deploy the application. This effort did not include tweaking network, software and hardware configurations in order to ensure the application ran smoothly.
For this particular client, we chose to deploy the application using Cloud Foundry in a private cloud. The setup, installation, configuration of Cloud Foundry and the deployment of our application to the private cloud took less than a day. More importantly, adding new servers/nodes simply involved replicating virtual machines with this configuration, which took less than a minute.
This vast saving of time and effort does not even include the countless hours developers spend architecting and fitting their applications to provide functions such as health checks, real-time application management via JMX and integrating the hardware and application monitoring consoles. We were able to achieve all of the above without writing a single extra line of code.
A few months later, we migrated our client’s applications to a hybrid cloud, i.e., some of the applications continued run in the private cloud, while some were moved to a dedicated Cloud Foundry instance on Rackspace’s cloud infrastructure. The total migration effort was 24 hours based on the portability of our underlying PaaS, Cloud Foundry.
Strict Separation Between IaaS and PaaS services
We see clients interested in maximizing the services provided by their public IaaS provider, including some services that cross over into the PaaS tier including storage, data and queuing services. Our advice to these customers is to architect the system to have a strict separation between IaaS and PaaS services to keep these services portable in case they need to move the PaaS layer and application services to another infrastructure provider.
For these clients we selected a PaaS layer using Cloud Foundry which we used to anchor the cloud application architecture model.
Figure 1 – The PaaS Tier of Our Cloud Application Architecture Model
The services provided by Cloud Foundry define the PaaS tier of our model:
- Application runtime services including Java on Spring, Ruby on Rails and node.js
- Application management services including application health monitoring and alerting, application resource management and application scaling and deployment management.
- Data services including PostgreSQL, MySQL, MongoDB and Redis. By persisting application data within data services offered by the PaaS, you increase the portability of your application data vs. persisting data directly to the infrastructure level data service, e.g., Rackspace Cloudfiles or AWS relational Data Service (RDS).
- Messaging & Queuing services including RabbitMQ. Multiple cloud applications deployed within the same environment often need to communicate with each other. The mechanism for communication between applications should leverage the PaaS Messaging and Queuing services, which again eliminates dependencies on the infrastructure. For example, multiple applications should never use environment variables to communicate with each other, as extra effort is required to migrate such configuration from one IaaS provider to another.
Use these services at the PaaS level instead of at the Infrastructure level and each of these services will be portable. Every Cloud Foundry Core instance includes the same release version of these services. If you stick with “Core” services your application will be certain to have portability among all Cloud Foundry Core compatible providers.
Figure 2 – The IaaS Tier Follows Our Selected PaaS Services
Based on some prototyping and performance testing, we were able to convince one of our customers to leverage a PaaS for the data and storage services. This also served to validate our application architecture model. Within a year this client decided to migrate to a different public cloud infrastructure provider to lower their costs. This layered architecture saved this customer a substantial amount of money by maintaining the architectural separation between the PaaS and IaaS providers for the data and storage services. The only activity we had to perform with the client was to install Cloud Foundry and replicate the application data to the new IaaS provider. This allowed us to migrate the application, services, and data (using Cloud Foundry Tunneling) to the new cloud infrastructure provider in a matter of days, which otherwise could have taken months.
Social Networking App on AWS Demonstrates Service Integration
We recently designed a social networking application for a startup customer that required the following application layer services: Payments, SMS Messaging, Email and Facebook/Twitter Integration. The application was to be deployed using Cloud Foundry on Amazon EC2. For each of these services Amazon offered alternatives as did third party SaaS providers.
We evaluated these application level services, regardless if they’re offered from the IaaS or PaaS provider, like we would services from any third party SaaS provider based on functionality, price, performance and integration capabilities. Consider the implications to portability on your application. Will it be more difficult to migrate from the IaaS vendor if you utilize their other application services versus 3rd party application services that work on any cloud? Consider portability implications across technical, business and contract considerations.
Integrating SaaS Applications
When integrating value-add SaaS services into your application ensure a loose coupling between the application and the third party SaaS providers to optimize release management, operational integrity and application portability. The most recommended mechanism to achieve a loose coupling is to ensure that third party providers support RESTful APIs for your application to use and that your application provides a RESTful API for your customers to use.
For example, we helped one of our customers integrate their SaaS application with two 3rd party cloud services, ServiceNow and Jira. The application provided a bridge between these two services so that external customers could use ServiceNow and the engineering staff could use Jira as the defect tracking tool.
Jira has a RESTful API and ServiceNow has a tightly coupled interface via a Java JAR. We recommended that our client separate the integration between the SaaS app and ServiceNow into a separate “broker” application. As a result, changes to the vendor’s JAR file did not require any changes to the main application. The broker application provided the main application with a consistent, RESTful API, isolating the application from directly having to consume the Java JAR.
By selecting an open PaaS you significantly increases the probability of developing a portable application. Using a layered, PaaS centric design approach you can increase the portability of your application by limiting the proprietary IaaS services on which your application depends.