[Disclaimer: todas estas notas son personales, bajo mi libre interpretación y en ningún caso es un resumen oficial de Dell EMC o similar. Las notas las fui tomando durante las charlas, si he metido la pata de alguna forma… pues es lo que hay :-). El día anterior no sólo se agotó la batería del portátil sino que mi cargador murió, si no es por un compañero (mil gracias de nuevo Edorta) me quedo sin portátil hasta el lunes. Lo pude recuperar pero hasta el final de las charlas no pudé cargar el portátil, por lo que tomé las notas a mano y muchas fotos, a ver como queda la trascripción]

Para celebrar el último día del DTW 2018, de nuevo a las 8:30 arrancamos con una charla sobre “Understunding The CNCF Cloud Native Landscape: It’s more Than just Kubernates“. Charla muy interesante que empezó con poca gente y se fue llenando poco a poco (la hora era horrorosa).

El objetivo de la Cloud Native Computing Foundation es extraer el valor de toda la forma de operar de los “unicornios” de Internet y hacerlo disponible de una forma razonable a cualquier empresa. Una pregunta interesante con la que arrancó la charla fue el porqué si las CNA son tan maravillosas como todos decimos, no las adoptan de forma másiva todos las empresas, y la respuesta es básicamente porque desarrollar una CNA también es complejo.

Hay algunos problemas sobre está complejidad ya resueltos como la portabilidad de aplicaciones solucionada con dockers. Está complejidad viene de que las CNA requieren herramientas y telemetría para añadir automatización a la operativa “clud” de la aplicación.

Si pensamos en una Cloud Native Application, el gráfico inferior (que en la presentación “trocearon” en varias slides) indica los pasos a dar del más básico al complejo:

1. Aislar y hacer portable la aplicación (conteinarizarla).
2. Automatizar la integración en su integración y despliegue (CI-CD).
3. Gestionar el ingente numero de instancias* que puede haber de contenedores (eso es Kubernates, el único proyecto del CNCF en estado “grduado”, el resto están en estado  de incubación).
4. Una vez las instancias de contenedores están orquestadas, es necesario analizar como se comportan y controlar sus logs (monitoring-tracing).
5. Y luego permitir que los servicios de los contenedores hablen entre ellos con funciones de automáticación de red (el nº 6 en la imágen).
6. Y con gestores de servicios para el regitro y descubrimiento de los mismos (el nº 5 de la imágen).
7. Luego podemos añadir Bases de datos para la gestión de información persistente. Una puntualización interesante que hizo el ponente en este punto es que si no tienes claro que tipo de base de datos usar (relacional o de tipo no sql) adoptes la tradicional, dado que la forma de entender la persistencia de información es más sencilla en un entorno ACID que en una base de datos de otros tipicos…
8. y cuando la arquiectura crece, necesitaremos gestión de colas de mensajes.
9. Ya por último podemos automatizar el runtime.
10. Y como paso un tanto “experiamental” aún, el despliegue de software. Este punto es curioso y trata de asegurar en modo “notario” que los requisitos de un container que has pedido son los que te han dado, y de forma análoga que el código que espera ejecutar el contenedor es el adecuado. A título personal me pregunto cuanto tardará Blockchain en meterse en esta discusión.

Cómo se ve en el gráfico de la CNCF, la fundación tiene proyectos para todos los pasos, varios en algunos puntos. Se puede ver un gráfico bastante intuitivo e interactivo sobre los diferentes paquetes, uso y grado de desarrollo en: https://landscape.cncf.io/

Contínuo la charla explicando paso a paso cómo se iría constuyendo una CNA con las soluciones de CNCF:

1. Creando un container en formato estándar OCI desde el sistema de control de versiones que cada uno uso (SVC) que corre en un SSOO.
   • Ese container tiene:
     • Una definición del sistema de ficheros.
     • Los límites de consumo de CPU, RAM, etc.
     • El namespace de procesos que puede ejecutar.
     • La configuració de puertos, entorno, links … y también iría aqui la definición de volumenes a usar.
     • Por último el comando de inicio.
2. A esto se le añade un Runtime de containers que lea la imágen antes generada. Además este runtime puede correr en varios entornos (cada un con su OS).
3. Luego se añade el coordinador de containers que va a hacer de plataforma… Kubernates.
4. Cómo cada contenedor puede ser requerido o requerir de otros servicios que no conoce, hay que añadir un servicio de registros.
5. Y cómo entre todos ellos pueden comunicarse, hay que añadir un servicio de comunicación.
6. Para poder actuar sobre algo y mejorarlo, hay que medirlo (por cierto esto lo dijo Ashton Kutcher ayer en su charla), así que añadimos un servicio de métrica, gestión de trazas etc.
7. Y por si nececesitamos persistencia de datos una BBDD adaptada al mundo de los Contedores.

Después la charla paso a versar sobre cómo se crea una plataforma. ¿Por qué una plataforma? porque (como se comentó en una charla posterior) los desarrolladores y operadores (DevOps) no quieren tener que pegarse con la integración de diferentes soluciones puntuales, por lo menos en el mundo de negocios genéricos (los Unicornios y demás empresas de ese pelo puede que si mientras le de una ventaja competitiva)…

Un caso particular dentro de la plataforma de Dell Technologies es BOSCH. Uno de los valores diferencias de Pivotal Cloud Foundry, que se encarga de toda la gestión del IaaS que no es objetivo clave de CNCF u otros proyectos similares, dado que cuentan con abstraerse de lo que hay debajo o directamente asumen correr sobre alguna Cloud publica tipo Hyperscaler (Amazon, Azure o Google Cloud platform).

Acabó la charla, cómo no podía ser de otra forma, con una demo, centrada en JAEGER el sistema de control de trazas de micrcoservicios de la CNCF. Muy espectacular la verdad y demuestró por un lado la complejidad derivada de una CNA “dummy” y como de necesarias son las diferentes piezas de CNCF para gestionar el entorno. Además sobre el ejemplo fue análizando los logs del sistema evaluando potenciales problemas/mejoras de la app…. muy útil la verdad.

(*) Sobre el numero de instancias, en otra charla posterior se mencionó que mientras sobre un servidor con catacterísticas genéricas se podrían correr hasta unas pocas cientos de maquinas virtuales, el numero podría ser de varios miles en el mundo de los contenedores… de ahí su éxito y también la complejidad en el manejo de instancias, que es exponencial incluso respecto al de máquinas virtuales.

Cómo nota final, al margen de la charla: vobre la parte de persistencia de Kubernates, hubo una presentación muy buena a la que no pude asistir, pero el contenido está aqui para descargar: link a pdf.

Después vino la charla técnica más interesante de todo el evento… Continuar leyendo…