Cloud Foundry is built to be as extensible as possible. Its architecture provides a lot possibilities for the ecosystem to integrate with different components. Naturally, you have to take into account the constraints that exist for apps that run on CF, e.g., the platform only supports one inbound HTTP port and all apps need to comply with the 12-factor principles. Still there are many ways to make existing enterprise assets work with CF.<\/p>\n

<\/p>\n

Mark Kropf explains that there are several levels of integration. User-provided services are the smallest degree. They require most effort to maintain and support. The next step are brokers, which provide services when apps need them. Finally, there are apps and services hosted on Cloud Foundry. What you choose depends on where you are in your journey. If you have a 12-factor compliant app, you can jump right to the end.<\/p>\n

As of the question of when it is time to switch from UPIs to service brokers, he says that UPIs need to be wired up to the app every time it is pushed, i.e. they have to be defined in the app manifest or during push time. A service broker can provision services to apps whenever they need them, even if they run in different environments where this service broker is enabled. If a service is used frequently, it becomes too laborious to maintain a UPI. This is the time to start thinking about a service broker.<\/p>\n

Generally, the highly flexible service broker API makes it easy to build service brokers of any complexity. A good example is the AppDirect service, which actually serves as an entire mapping layer between the Cloud Foundry API and a range of other services. In addition, you can technically run your PaaS on any infrastructure. The BOSH team are finishing their work on CPI extraction. When that is done, third parties will be able to build CPIs for literally anything, including containers.<\/p>\n

<\/p>\n

 <\/p>\n