¿Podemos usar Cloud Foundry para aplicaciones de TI tradicionales y no solo aplicaciones nativas de la nube?

En muchos casos, si. He visto grandes aplicaciones de WebSphere respaldadas por mainframe portadas para ejecutarse en CF con WebSphere Liberty, con bastante facilidad. No se requieren cambios de código reales, aunque es útil pasar a las variables de entorno en lugar de los archivos de propiedades, aunque es posible hacer una secuencia de comandos si es absolutamente necesario. Algunos incluso se modificaron un poco en Tomcat o Spring Boot (lo cual es fácil si ya usan un marco IOC).

Algunas aplicaciones empaquetadas funcionan bien en la fundición en la nube si se distribuyen como imágenes Docker o archivos WAR.

Todo esto funciona bien para bases de datos tradicionales o aplicaciones respaldadas por middleware.

La mayoría de los problemas han sido cuando necesita colocar bases de datos prioritarias o middleware, o un sistema de archivos compartido en el mismo contenedor: ¿cómo gestiona el ciclo de vida y la recuperación de volúmenes persistentes si es necesario? ¿O los puertos de red a través de un clúster? Etc.

Los servidores de aplicaciones tradicionales incluían intermediarios de mensajes, monitores TP y similares, y estas características siempre han sido problemáticas de administrar de manera HA incluso antes de la CF (recuerdo haber configurado el sistema de archivos del clúster Veritas para la recuperación de la cola del clúster JMS de Weblogic en los viejos tiempos).

Un desafío de larga data ha sido la incapacidad de exponer múltiples puertos de escucha TCP en una aplicación CF a la red externa. Esa característica ha existido en estado experimental durante algunos meses y debería llegar a GA este año.

CF tiene soporte NFS entre otros en estos días para volúmenes compartidos. También he visto SMBclient incrustado para acceder a unidades compartidas de Windows en producción en la naturaleza, aunque no hay ninguna razón para que SMB no pueda ser compatible de forma nativa eventualmente.

Lo que sigue siendo difícil de soportar son los volúmenes de alto rendimiento por contenedor para cosas como registros de transacciones o archivos de bases de datos. Para la mayoría de las aplicaciones que dependen de una base de datos, estas son raras: la base de datos se ejecuta en una máquina virtual en otro lugar y la aplicación puede funcionar con CF bien. Podría decirse que todos los servicios con estado deberían estar en máquinas virtuales en 2017 dado lo jóvenes que son las diversas tecnologías de almacenamiento de volumen de contenedores … pero si lo desea, Kubernetes StatefulSets tiene una solución aquí, y cada vez más se ubicarán con Cloud Foundry con el proyecto Kubo fuera (Pivotal y el proyecto conjunto de Google que BOSH automatizó Kubernetes y también permite la integración con CF).

Una línea : posiblemente sí con algo de tarea

Detalles :
Cloud Foundry ofrece una plataforma con muchos servicios disponibles. Necesita un respaldo IaaS.
Cloud Foundry tiene una abstracción definida sobre IaaS real. Esto se llama CPI.

CPI es útil para cambiar el proveedor de IaaS.

Entonces, teóricamente, Cloud Foundry se puede usar para aplicaciones de TI tradicionales, pero debe identificar
1. cuál IaaS te queda mejor. También puede usar su propio centro de datos como IaaS.
2. Puede haber algunas herramientas heredadas en su Aplicación. Si no están disponibles en Cloud Foundry. Debe implementarlos en Cloud Foundry y vincularlos como servicio en su aplicación implementada.