Cloud Foundry POC: Tips and Concerns for Your Apps
Getting monolithic architectures to work with CF takes some effort and, in the end, the resulting solution may lack some of the features that make cloud-native software so attractive. This post contains criteria for selecting an app that will work on CF out-of-the-box or with minimal modifications.
The 12-factor app principles are a great way to start if you are looking to build for the cloud, but those are general recommendations. We provide an extended list of concerns to keep in mind when migrating workloads to/developing for the Cloud Foundry PaaS.
What if my company does not have any cloud-native apps? Read the blog for technical details on how to implement an app for Cloud Foundry.
Choosing an app for your Cloud Foundry POC
Virtually anything can be made to work with Cloud Foundry. Still, a layered architecture cannot be expected to run and scale without modification. CF is designed to support microservices, so, unless the monolith is split into smaller parts, you won’t be able to reap all the benefits. The difficulty of porting will differ from app to app, but it is hardly a trivial task.
The best option for a POC is to choose an app that will be compatible with CF without or with minimum changes. A Cloud Foundry POC has the best chance to be successful with cloud-native workloads and staying away from monolithic apps on a single server.
Applications that will find the most success will meet the following criteria:
- Do not write to the local file system
- Short-lived/ephemeral
- Instances of the same app do not share a local file system
- Do not persist or replicate HTTP sessions
- Take into account HTTP and HTTPS port limitations
In general, any 12-factor app will work as is. A quick review of 12-factor apps can be found here: https://12factor.net/.
Developing apps for CF: key concerns
In case existing apps do not meet the above criteria, it may be reasonable to implement a new or an ongoing project that has just started as microservices and then use that in the POC. Below are the key concerns for applications that will run on Cloud Foundry. These can be used as guidance when building for or migrating software to CF.
| Dependency management | Environments differ, so one should never rely on implicit existence of system-wide packages/libraries/etc. There are great tools to manage dependencies, such as Bundler and Maven, but nothing is as effective as building and packaging an app to contain the very same dependencies no matter what environment it is running in. It’s also recommended to build the workflow on tools that help to create reproducible environments. Consider using Docker for these purposes. |
| Stateless sessions | Applications keep user and app data in HTTP session variables. If there is more than one app instance running behind a load balancer then a ‘Sticky Session’ pattern has to be implemented. |
| Local disk storage | This concerns applications that need to share files through a local file system. In a PaaS, instances are ephemeral. They can crash and new ones can be automatically launched. You can scale down, destroying the instances that are no longer necessary, etc. |
| Configuration variables with environment variables | Store config in the environment. Hardcoded config goes against maintaining multiple environments. |
| Available ports | PaaSes do not allow for having multiple ports opened. Only ports 80, 443, and 4443 (Web sockets) are allowed. Do not rely on port numbers at all, because an application can be started in a container using a port provided with the PaaS. For instance, see the $PORT variable in CF env variables. |
| Runtimes and frameworks | If the application server, framework, etc. is customized, the corresponding buildpack will also need to be customized. Try using standard frameworks and libraries to avoid problems with PaaS integration. |
| Background applications (with no Web interface) | If the application runs as a background job, custom deployment parameters need to be provided, so that the PaaS does not consider it to be down/crashed. In case of Cloud Foundry, the –no-route option will need to be added to push a command. |
| Stateless processes | In Cloud Foundry, processes can be recreated in a separate container environment in order to scale application. In this case, new processes (application instances) will know nothing about the local state of other instances. |
| External services | The connection to external services must be used wisely as it can take time to bring traffic to them. Security questions must not be forgotten. It is strictly recommended to use SSL. An even better option is to use services that are embedded in Cloud Foundry. |
| Separation of concerns | Decouple work between processes and increase separations of concerns. Processes can be started, and errors localized, faster. |
| Hardware architecture dependencies | Avoid using precompiled components. Don’t use database data files and other components that may rely on a specific architecture. |
| CI tools | Running tests on the PaaS side will increase reliability of deployments. |
| Ignored files | Not everything needs to be pushed. Avoid sending temp files and configuration files, for example, with credentials or individual setup to Cloud Foundry. |
| System libraries | Use framework/language libraries to perform system work. For instance, it is better to use a Temfile object rather than create something in the ‘/tmp/’ directory. |
For more on how to implement a Cloud Foundry POC, what to expect from the PaaS, and how to introduce it within the organization refer to the Architect’s Guide to Implementing Cloud Foundry.
Or, join us at the upcoming CF LiveCast on November 24, 2015:
