Tras la teoría expuesta en el anterior artículo sobre la evolución de SAP en el mundo de la computación en la nube, hemos visto que SAP CLOUD PLATFORM es la herramienta principal para desarrollar aplicaciones y aprovechando en el mismo tiempo de una multitud de otros servicios y técnicas de integración.
Desde el principio SAP Cloud Platform ha proporcionado dos entornos de desarrollo diferentes: Cloud Foundry y Neo, los cuales han estado evolucionando de manera paralela, trayendo novedades y mejoras continuamente. ¿Pero qué diferencias hay entre esos dos entornos de desarrollo?
Diferencias entre Neo y Cloud Foundry
| NEO | CLOUD FOUNDRY |
| El entorno Neo admite un conjunto fijo de tiempos de ejecución y lenguajes de programación: ● HTML5 ● Java ● Servicios de aplicaciones extendidos de SAP HANA (SAP HANA XS) | Cloud Foundry utiliza paquetes de compilación, que son API estandarizadas entre Platform-as-a-Service (PaaS) y las cargas de trabajo que se ejecutan sobre la capa de PaaS. Permiten que el entorno de Cloud Foundry admita una amplia gama de tiempos de ejecución y lenguajes de programación, que incluyen, por ejemplo, PHP, NodeJS, Ruby y Python, así como opciones de comunidad y traer su propio idioma. |
| Con el entorno Neo, se pueden usar solo servicios propiedad de SAP, como SAP HANA y SAP Cloud Platform Enterprise Messaging. | El entorno de Cloud Foundry le permite elegir no solo entre los servicios propiedad de SAP, sino también entre varios servicios de respaldo administrados por su respectivo proveedor de IaaS. |
| El entorno Neo se ejecuta solo en centros de datos de SAP. Para garantizar la resiliencia, la mayoría de los componentes del entorno Neo de SAP Cloud se ha configurado de forma redundante dentro de un solo centro de datos. | El entorno de Cloud Foundry le permite elegir entre diferentes proveedores de IaaS y, por lo tanto, contribuye a la disponibilidad multicloud de SAP Cloud Platform. |
Evolución de Neo y Cloud Foundry
A principios de este año, era posible crear una cuenta trial en cada entorno, para poder probar y verificar tú mismo las diferencias, las ventajas y las limitaciones de cada entorno.
Sin embargo, para respaldar la estrategia de proporcionar SAP Cloud Platform en una base multi-cloud, SAP moverá el enfoque de SAP Cloud Platform completamente a Cloud Foundry y cerrará las cuentas de prueba en el entorno Neo desde el 13 de noviembre de 2020. Esto nos demuestra que Neo no va a seguir mejorando mucho en el futuro, por lo que tendríamos que migrar todo a Cloud Foundry. ¿Y ahora, qué?
¿Qué supone la migración desde Neo a Cloud Foundry?
Cada migración del entorno Neo al Cloud Foundry es individual y se basa en sus escenarios, es decir, en los objetivos que desea alcanzar y en las diferentes aplicaciones, servicios e integraciones involucrados. Migrar un escenario de un entorno a otro implica migrar todos los componentes que contiene. Desafortunadamente, cada uno de estos componentes tiene sus propias particularidades, lo que hace que sea imposible migrarlos de una vez.
Las aplicaciones HTML5, por ejemplo, en SAP Cloud Platform constan de recursos estáticos y pueden conectarse a cualquier servicio REST existente en las instalaciones o bajo demanda. A diferencia de las aplicaciones backend estándar, las aplicaciones HTML5 no requieren cuota de tiempo de ejecución de la aplicación adicional para esta conexión. En cambio, los recursos estáticos y las llamadas REST se ejecutan a través de un servicio dispatcher compartido.
En el entorno de SAP Cloud Platform Neo, se proporcionan tanto el repositorio de contenido, como el servicio dispatcher, por SAP Cloud Platform. En cambio, en el entorno de Cloud Foundry, su funcionalidad está cubierta por dos componentes:
- SAP Cloud Platform HTML5 Application Repository: este servicio le ayuda a almacenar de forma centralizada el contenido estático de las aplicaciones HTML5.
- Application Router: el enrutador de la aplicación ofrece contenido estático del repositorio de aplicaciones HTML5 de SAP Cloud Platform, autentica a los usuarios, reescribe las URL y reenvía las solicitudes de proxy a otros microservicios mientras se propaga la información del usuario. Puede utilizar una aplicación independiente dedicada que gestiona usted mismo o una oferta totalmente gestionada por SAP Cloud Platform.
Como conclusión, para que nuestros escenarios funcionen correctamente al cambiar de entorno, tenemos que asegurarnos que todos sus componentes han sido adaptados a las nuevas estructuras de arquitectura. Para conseguir esto, tenemos tener en cuenta los artefactos de seguridad y autenticación, destinos, grupos y roles, pero también las limitaciones, novedades y mejoras que ofrece la plataforma.
Vamos a seguir escribiendo artículos sobre el desarrollo de aplicaciones, migraciones e integraciones para mostraros como aprovechamos nosotros de la puerta que tenemos abierta con el mundo CLOUD. ¡Quédate con nosotros para estar al día!
