Shifting to Software-Defined
Showing results for 
Search instead for 
Did you mean: 

Cloud Foundry: Avoiding Vendor Lock-In


Author: Rick Evans, Senior Evangelist Technologist, HP Helion


In my previous blog I stated: "..., by adhering to a relatively small set of standards recommended by Cloud Foundry for configuring your application, you should be able to move your application to run on any Cloud Foundry environment, regardless of vendor."


In other words: Cloud Foundry avoids "Vendor Lock-In" of your application code.


You may be wondering how this works; what are these "relatively small set of standards" that enables your application to run on any vendor's Cloud Foundry environment?


First, we need to consider how a web application relates to the environment it is running in.

The components of a web application run on servers.

In a modern web application, each component communicates with other components, typically, through a set of industry standard network protocols, for example: HTTP, UDP, ODBC, JDBC, LDAP, etc.

As long as these components use the standard protocols, connecting the components should be relatively simple.


In a broader sense, some of the components that modern web application depend on include what we used to call: "MiddleWare."

These are 3rd party software systems, like database engines (e.g., MySql, Oracle, MongoDB), Application Servers, Message Queue Servers, and Directory Servers. In Cloud Foundry jargon, this middleware is known as "services." The interface with each service is well-establish, i.e., the API an application uses to connect to the service is the same regardless of which service instance it running on. BUT the connection values to connect to a SPECIFIC service instance will be different on each server.


It may be a subtle point.


The API are standardized, but the connection values are unique. The algorithms are the same, but the data is different.


One analogy that has been used is, given a specific model of a combination lock, the steps you take to dial the combination are the same, BUT the combinations are completely different for each lock. Likewise, each web component has its unique set of connection values that include things like: hostname, IP address, port number, valid username & password (credentials), etc. The protocols are standard but the configuration values for each instance on various servers are completely different.


Consider further, when a modern web application starts receiving too many requests for it to handle, the modern way to increase a web application's capacity is to create additional copies (instances) of the web application's components on more and more servers; each of these new server instance will include unique configuration values.


Each time a web application component is deployed to a new environment, it must discover the values of the other application components it communicates with.


The "traditional" way to provide each application component with these values for its runtime environment is to place them in a new copy of a configuration file customized with those new environment values. The configuration files were written in a format that the application must be designed to read. There are many popular standard formats used for configuration files; for example: INI, XML, JSON, YAML, etc. There are libraries of code that the application can incorporate so the developer does not have to re-invent this wheel. The application code must include commands to read the configuration file and then retrieve the values it finds within, however, sometimes developers create their own custom format and write their own custom code to read that file format. Just because the configuration file uses a standard file format, it does not imply that the structure of the values is standardized. For example, most formats do not stipulate of the order or names of each value in the configuration file. That is, each application will have a unique list of values it needs.




But now consider the point-of-view of Cloud Foundry. Cloud Foundry's job is to upload (deploy) the application components to server environments. That implies Cloud Foundry must create a new configuration file for each application it deploys with the values that match each environment it is deploying to. Imagine how complicated it would be if Cloud Foundry had to know how to populate the different configuration files with the values for each server.


Instead of accepting this "Tower of Babel of configuration file formats," Cloud Foundry borrowed process and the manifest.yml file used by public Platform-as-a-Service provider, Heroku. Someone recognized that the server environment values are unique to each server instance. So why not just store those values as environment variable in OPERATING SYSTEM for each server?


Each programming language provides support for reading values from the host operating system.

By simply asking the developers to retrieve connection information from the operating system,

Cloud Foundry sidesteps the issue of maintaining code libraries for writing to any arbitrary configuration file format.


In some ways, it actually is easier for the developer to write code to retrieve connection information from the local operating system, than from an application specific configuration file.


But, you may ask, how does Cloud Foundry know which connection information the application needs? That information is in manifest.yml file. The manifest.yml file is a description of how the Cloud Foundry runtime communicates with a deployed application about its environment.

Among other things, the developer provides the names of services in the manifest.yml file that the application needs to operate. Those service names must map to the services that the local cloud foundry has been configured to deploy.


For example, if the application requires a MySQL database engine, the manifest file lists MySQL under the Services section of the manifest file. The manifest.yml file not only includes connection values it also includes information about how many instances to create and how much memory to allocate. The manifest.yml file is a single convenient place where the interface between the application and its runtime is environment is specified. If you want to try deploying your web application on a new cloud environment, it provides the basic information needed to know if the new environment has the service necessary to support the application.  It is also a convenient place to start when considering testing changes to the versions of the backend services the application is deployed on.


Since each Cloud Foundry distribution from the different vendors use the manifest.yml file, there should be less problems with moving your application to run on a new Cloud Foundry environment.


In other words: Cloud Foundry avoids "Vendor Lock-In" of your application code.


For more information about Cloud Foundry manifest.yml files see:

Senior Manager, Cloud Online Marketing
0 Kudos
About the Author


I manage the HPE Helion social media and website teams promoting the enterprise cloud solutions at HPE for hybrid, public, and private clouds. I was previously at Dell promoting their Cloud solutions and was the open source community manager for OpenStack and at Rackspace and Citrix Systems. While at Citrix Systems, I founded the Citrix Developer Network, developed global alliance and licensing programs, and even once added audio to the DOS ICA client with assembler. Follow me at @SpectorID

June 19 - 21
Las Vegas, NV
HPE Discover 2018 Las Vegas
Learn about all things Discover 2018 in Las Vegas, Nevada, June 19 - 21, 2018.
Read more
See posts for dates
See posts for locations
HPE at 2018 Technology Events
Learn about the technology events where Hewlett Packard Enterprise will have a presence in 2018.
Read more
View all