01 Sep System Platform, la primera Plataforma como Servicio (PaaS) industrial
Muchas personas que trabajamos en el sector TIC leemos noticias abrumadoras sobre el futuro de los servicios y aplicaciones, en las que se asegura que en poco tiempo todo estará basado en el Cloud. Noticias del tipo:
- “La consultora IDC auguró que más del 80% de las grandes empresas utilizarán en 2018 entornos de Cloud híbrida”
- “Los servicios de Cloud pública moverán 96.500 millones de dólares este año (y el doble en 2020)”
- “El mercado mundial del Cloud híbrido superará los 240.000 millones en 2022”
No sé si estas cifras se cumplirán o no, pero que a corto / medio plazo los sistemas actuales evolucionarán a la “nube”, es seguro. La razón de esta afirmación está basada en las funcionalidades que aporta, así como en las ventajas competitivas que ofrece a las empresas.
Uno de los 3 pilares del cloud (IaaS, PaaS y SaaS) es la Plataforma como Servicio (PaaS), que permite a los desarrolladores disponer de un entorno automatizado de desarrollo y despliegue en producción, aislándolo de la infraestructura necesaria para la ejecución de las aplicaciones.
Algunas de las funciones que soporta una Paas son:
- Gestión de los procesos en tiempo real
- Comunicación entre clientes – servidores y entre los mismos servidores
- Servicio de descubrimiento
- Gestión de fallos y redundancia
- Gestión de los entornos software y del rendimiento
- Despliegue de código
- Diagnosis y Log
Actualmente existen múltiples plataformas de IT que ofrecen estas funcionalidades: Red Hat OpenShift, Microsoft Azure, Google Cloud Platform, o Heroku. Pero, ¿qué os parece si os digo que una de las primeras PaaS del mundo industrial es System Platform de Wonderware?.
La arquitectura actual de System Platform fue liberada sobre el año 2000 (la arquitectura “core” que prácticamente se ha mantenido inalterable, fue realmente revolucionaria).
A continuación veremos cómo System Platform cumple con las funcionalidades que comentamos anteriormente.
Gestión de los procesos en tiempo real
En una Arquitectura Cloud, suele haber 2 capas para gestionar la ejecución en tiempo real:
- Hypervisor: Esta capa proporciona un contexto gestionable, proporcionando una abstracción del sistema operativo que permite la ejecución de otras piezas de software dentro de esta capa. Esta capa permite que partes de software se ejecuten en un área determinada de manera controlada.
- Contenedor: La idea básica de un contenedor (como docker), es poder desarrollar y desplegar código y librerías que se podrán ejecutar en cualquier host siempre y cuando se ejecuten dentro de un contenedor.
En System Platform, la analogía de estas 2 capas la tenemos con las Platforms y las Engines del sistema. El sistema permite desplegar la misma aplicación y librerías sobre diferentes versiones de Windows (W7, W8, W2K8, W2K12) y funcionará de la misma forma cada vez. Una vez el código está desplegado, permite arrancar o parar la aplicación en segundos (una de las grandes ventajas de los contenedores).
Comunicación entre clientes – servidores y entre los mismos servidores
Cuando se despliega una Platform, lo único que se necesita es un hostname o dirección IP. Una vez instalado el bootstrap, la Platform ya está operativa para funcionar.
Durante el proceso de despliegue, se notifica al resto de platforms la nueva configuración de la galaxia, no siendo necesarios ficheros de configuración sincronizados en todas las máquinas, y haciendo transparente la actualización de la arquitectura al desarrollador.
Servicio de descubrimiento
El descubrimiento de servicios es uno de los pilares de una plataforma de aplicaciones escalable moderna. En un sistema cloud, se puede desplegar una función o servicio en cualquier equipo, y el resto de elementos del sistema son notificados, funcionando todo correctamente en pocos segundos. Algunas aplicaciones IT que proporcionan esta funcionalidad son etcd, consul o zookeeper.
En System Platform, las engines y los objetos permiten que el programador escriba el código desconociendo en qué servidor correrá luego. Esta funcionalidad permite alcanzar grandes cotas de mantenibilidad y escalabilidad del sistema, haciendo posible que para ampliar el sistema tan solo debamos disponer de una nueva máquina, instalar la platform, y mover de servidor la app engine. En cuestión de segundos todas las máquinas de la galaxia estarán informadas sobre este nuevo “servicio” y el sistema funcionará normalmente.
Gestión de fallos y redundancia
Para conseguir la redundancia de servicios en system Platform (app engines), tan solo deberemos seguir los siguientes pasos:
- Establecer una conexión de red dedicada en el host
- Configurar una única dirección en la plataforma
- Marcar el checkBox de habilitar redundancia en la Engine
- Asignar la Engine a un host primario y uno secundario
Una vez desplegado, después de un fallo, el sistema conmutará automáticamente.La única funcionalidad que se puede echar en falta es que las engines se inicien en varios hosts, y no en un único host de backup.
Gestión de los entornos software y del rendimiento
El sistema de logs y alertas de System Platform es uno de sus grandes fuertes desde el punto de vista de ayuda al desarrollador, o para resolver problemas una vez el sistema está en producción. Si se quiere conocer la carga actual, rendimiento o consumo de tiempo para cualquier componente lógico, se puede visualizar desde el Object Viewer. También se puede almacenar esta información en un log para su estudio y análisis con tan solo marcar algunos checkbox. Incluso se puede configurar el envío de alertas si se superan los máximos establecidos, incluyendo la posibilidad de que estas alertas contengan una lógica mediante scripts.
Hasta no hace mucho, en el mundo IT, todas estas funcionalidades se debían resolver con aplicaciones de terceros o sistemas complejos de logging.
Despliegue de código
Una de las características de un PaaS es que el desarrollador escribe el código y luego lo envía a un entorno compartido donde se compila, se despliega y se pone en ejecución de manera automática (Heroku es un ejemplo de esto).
En un desarrollo de aplicación clásico, el desarrollador debe escribir y compilar el código. Después debe generar el ejecutable o librería y desplegarlos en el entorno de producción.
Con System Platform, estamos condicionados a desarrollar en un único lenguaje de programación (QuickScript.Net), pero con la posibilidad de aprovechar todo el framework .NET, permitiendo la importación de DLLs.
En un desarrollo con System Platform se escribe el código y el sistema se encarga de compilar, enlazar dependencias, desplegar y ejecutar la aplicación.
Diagnosis y Log
Para determinar cómo de difícil es disponer de una herramienta de gestión de Logs o trazas, tan solo hay que ver las empresas especializadas en este tema, y que existen 3 o grandes formatos diferentes donde estas empresas implementan sus librerías. Si lo que se quiere es disponer de registros de rendimiento de algunos datos, esto se trata de forma muy diferente.
En contraste, en System Platform, todo se maneja con mensajes de log:
LogMessage (“This is a Message”);
Eso es todo. Siempre funciona, siempre sabemos dónde ir a buscarlo, y disponemos de herramientas de filtrado y exportación para analizarlos mejor.
Las plataformas actuales de PaaS disponen de herramientas que facilitan la gestión de logs y trazas, de modo que el desarrollador no deba escribirse las suyas.
En el caso del registro de rendimiento de datos, en System Platform tan solo deberemos buscar el parámetro que queremos monitorizar y marcar un check. Si estamos en un entorno donde no podemos desplegar un engine o una platform, podemos crear un objeto y utilizar una I/O extensión para enlazar con ese parámetro e historizarlo.
Como hemos podido ver en este artículo de Oasys Outsourcing Automation Systems, muchos de los conceptos y funcionalidades actuales de las Plataformas como Servicio (PaaS) se estaban utilizando desde hace años en el software industrial, ya sea con el ejemplo que hemos visto con System Platform de Wonderware o con los denominados DCS (Distributed Control Systems).