Dell Technologies World 2018 (dia 4 – fin)

4 mayo, 2018 — Deja un comentario

[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 plataformaKubernates.
  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…A las 10:00 seguimos con una repetición de una charla a la que no pude asistir el lunes, el gran Fabio Chionidi (Director de Marketing para nuestro gupo de DotNext … aunque un geek en un interior como él mismo mencionó) habló sobre “Cloud Native Application, Containers, Microservices, Platforms, CI-CD…Oh My!” y no defraudó.

El objetivo de esta interesante charla era poner en perspectiva los términos asociados a este nuevo mundo de las CNAs e ir demostrando su uso con varias demos.

Arrancando intetando definir lo que son las CNA, “Aplicaciones que no requieren de una infraestructura resilente” y “Aplicaciones que están diseñadas para ser gestionadas por Software y no por humanos”, fueron las definiciones ganadoras.

Siguió explicando las famosas 4 fuerzas o elementos que han impulsado ahora el mundo de las CNA:

  • Contenedores: que centra su valor en cómo poner de la forma más segura una aplicacicón en producción.
  • MicroServicios: que centra su valor en el diseño de la aplicación y cómo minimizar sus fallos y hacer más sencillos los cambios.
  • Agile: que no es sinó la nueva forma de desarrollar para poder trabajar más cerca de las necesidades y minimizar los fallos derivados de requisitos mal entendidos.
  • DevOps: lo mismo que Agile, pero aplicado no sólo al desarrollo sino también a la operación.

Así que según esta charla, todo el mundo de las CNA se basa en desarrollar más rápido, seguro (desde el punto de vista de ser más rápido en arreglar problemas) y acorde con las necesidades cambiantes… y los beneficios parecen merecer la pena:

Los porcentajes en azul indican los beneficios generales de la apróximación CNA, y en verde los añadidos al trabajar con la plataforma Pivotal Cloud Foundry de Dell Technologies. Que algo de Mmarketig había que poner (palabras de Fabio, no mías :-)).

Pasó luego Fabio a hablar de diferentes conceptos que todas las empresas, y no sólo los Unicornios están aprendiendo a poner en práctica respecto a las CNA:

  • El concepto de TDD (Test Driven Development), que básicamente consiste en primero desarrollar las pruebas que un código debe pasar para ser correcto, y luego empezar a escribir el código en sí.
  • Conceptos como CI-CD (Contiuous Integration – Delivery/Deployment) que se centra en automatizar todos los pasos intermedios desde el desarrollo del código hasta la puesta en producción, añadiendo las fases de pruebas necesarias en cada paso. Una imágen vale más que mil palabras:

Tras está parte inroductoria, arrancó demo de gestión de servicios sobre Google Cloud Platform, de código Python y Flask para que unos servicios Honeypots realizaran unas peticiones que más tarde se visualizarían desde logs, todo ello desde una arquitectura construida sobre Kibana & elastic & logtash. La primera parte de Honeypots corría sobre Dockers y la plataforma de logs y visualización sobre Kubernates. Ambas partes se comunicaban a través del gestor de servicios etcd. Como demo para ver cómo todo funcionaba de forma sincronizada fue bastante útil.

Luego pasó a hablar de la complejidad del ecosistema de aplicaciones rodeando a las CNA:

Y luego lo organizó de izquierda a derecha mostrando las diferentes aplicaciones/sistemas disponibles para trabajar, sólo en CNCF en las diferentes fases de la vida de una CNA:

Pero el gráfico es una versión reducida… mira lo que se puede encontrar en busquedas más generales al respecto sobre DevoOps en general:

En este documento se puede leer un análisis muy interesante del ecosistema.

Luego pasó Fabio a hablar de cómo las empresas están gestionando estas cargas y las clásicas: microservicios, contenedores, funciones como servicio (las famosas “serverless”) y por supuesto aplicaciones de gestión de datos clásicas, o incluso procesos batch… no hay ninguna opción mejor que otra, la cuestión es desarrollar con lo que tenga más sentido en cada momento.

El problema es que cada una de estas tipologías puede requerir de infraestructuras diferentes, con niveles de abstracción diferentes que es lo que require el desarrollador:

  • Application Platform (PaaS) para las aplicaciones clásicas que ahora son la mayoría.
  • Osquestador de Contenedores (CaaS) para el nuevo cuño de aplicaciones “containerizadas”
  • Serverless Functions (FaaS) para la siguiente generación.

Y debajo de todos estos tipos de plataformas por supuesto debe haber una solución de IaaS capaz de responder al mismo nivel de automatismo…

Tras esta visión de hacia dónde van las plataformas, retomó la demo y le fue añadiendo más y más capas, a partir de aquí ya no pude seguir la demo de forma coherente, tendré que probar a hacerlo yo desde el contenido disponible en GitHub con las demos de Fabio:

http://github.com/dotnext/training

Fue acabando la charla enlanzadola con la propuesta de valor de Dell Technologies. Si antes mencionaba que hay diferentes tipos de XaaS para ejecutar diferentes necesidades de los clientes, pero que todas deberían poder coexistir, está claro que ahí deberíamos aportar valor. Esto aplica para la mayor parte de los clientes Enterprise, siempre habrá “Unicornios” que prefieran hacer todo pieza a pieza.

Eso es lo que hace Pivotal Cloud Foundry, que dispone de:

  • Pivotal Application Service (PaaS)
  • Pivotal Container Service – PKS para los amigos (CaaS) sobre K8s.
  • Pivotal Function Service (FaaS)

Y todo ello sobre BOSCH que permite la gestión adecuada del IaaS subyancente.

Si queremos ver como encaja todo desde la capa de infraestructura, está es la foto, añadiendo las soluciones HCI de Dell EMC como la mejor forma de definir nuestra infraestructura hardware:

Y con esto y alguna demos de FaaS acabó la charla. La mejor técnica de todo el evento, pero aún nececito pegarme mucho con estos conceptos en un laboratorio para acabar de ser capaz de entender al 100% todas las relaciones.


A las 11:30 saltamos a ver Pivotal con una charla de Dan Baskette y Glen Campbell (de los equipos de Pivotal & VMware centrados en MicroServicios) sobre “Pivotal & Dell EMC guide to containers & microservices: Future Server Platforms for ‘serverless’ computing“. También muy interesante y que cerraba con un broche de oro las charlas anteriores.

Arrancó la charla muy interesante explicando que no tiene sentido esperar el nuevo gran cambio que vendrá de IT, sino que es una secuencia de pequeños los que están liderando el futuro. Los nuevos modelos de desarrollo nos permiten adaptarnos más rápidamente a toda esta secuencia de cambios.

Analizó los cambios en los modelos de desarrollo de los últimos años:

  • Aplicaciones que trabajaban directamente contra el HW.
  • Luego se pasó a la abstracción del OS.
  • Y Luego a la abstración total de la infraestructura con la máquina virtual.
  • Se perfección esa abstracción para únicamente consumir los recursos necesarios, los containers.
  • Y ahora se ha llegado a la abstracción de consumir los recursos necesarios, únicamente cuando son necesarios: el FaaS.

El proceso al final ha permitido refinar el acceso al consumo de recusos, centrandose en lo más necesario , sólo cuando es necesario.

Explicó la composición de un Container, no sin antes dejar claro que la discusión Contenedores Vs máquinas virtuales no tenía sentido, y que ambas pueden y deben coexistir.

Lo primero que destacó de la explicación es que si bien se suele habla de vitualización de recursos del OS, no es así, con tecnicas de aislamiento y contención lo que realmente hace sobre recursos del sistema operativo:

  • cGroups.
  • Namespaces
  • Capacidades
  • Seguridad
  • Sistema de ficheros de unión con el resto de elementos del OS.

Y sobre esto el interfaz de gestión con el gestor y orquestador de containers y también con el Hardware subyancente. Al fial esto no es nada nuevo, se hacía desde los 90’s con las zonas de solarias y otros muchos medios.

Si lo que queremos es analizar que hace exactamente del runtime de contenedores, de nuevo mejor una imágen que mil palabras:

Tras esto la verdad es que se mostraron slides muy interesantes, pero algo desconectadas de un hilo conductor, o quizás yo me perdi algo.

La siguiente slide  pasó a hablar de comos los entornos cada vez más heterogeneos, en todos los ámbitos de la infraestructura, cómo GenZ para los futuros sistemas “memory centric”, o Redfish para la gestión del IaaS.

Me recordó mucho esta slide a la visión futura del Computing con arquitecturas de tipo “Composable Architecture” que permitirán alinearse al 100% con los nuevos modelos de desarrollo sin estado, y a su vez con todo el stack desarrollado sobre CNCF (ver primera charla del día).

Centrando la charla en los microservicios se empezó cómo no con una definición, con la puntualización de que se “criticó” la definición canónica (en negro) con puntualizaciones muy interesantes (en los cuadros naranjas).

Se aprovechó también para criticar el concepto de arquitecturas “stateless” con la famosa frase de que “There’s no such thing as a stateless architecture, its just someone else’s problem“. Indicando que este tipo de arquitecturas ligadas a microservicios lo que hacen es delegar la complejidad en otros puntos de la arquitectura… y que está complejidad puede aumentar mucho debido al elevado numero de instancias y al grado de automatización, cómo dice la cuenta de humor @devops_borat “To make error is human. To progate error to all server in automatic way is #devops

Como se mencionó en la charla anterior, minimizar esta complejidad es parte del valor de Pivotal:

Y de nuevo se mostró la relación con las diferentes piezas que lo componen. PAS, PKS, PFS y la parte de BOSCH para la gestión del IaaS, independientemente de la infraestructura on-premise u off-premise sobre la que se despliegue.

Se pasó al detalle de las diferentes piezas de Pivotal como PAS:

PKS:

Y la parte de Pivotal Function Service – PFS tras definir un poco mejor de que se trataba cuando se hablaba de Functions as a Service, centrando su definicion en las característicass de que se encuentra gestionado por eventos, con una vida muy corta, sin estado y auto escalable.

Un claro ejemplo podría ser funciones (desplegadas encima de K8s y estos a su vez residiendo sobre la plataforma que sea) que se encargan bajo demanda de recoger información de sistemas IoT en el edge y pasarlos a un backend que los procesa tipo Analytics. Estas funciones sólo estarían disponibles en caso de necesidad/uso, siendo breves en vida y pasando los datos al sistema de backend cuando son procesados, por lo que se quedaría stateless… 

Se cerró las charlas cómo las anteriores relacionandolas con los modelos de desarrollo y despliegue sobre Pivotal. Siempre recomendando VxRail como plataforma ideal.

Una charla muy interesante, aunque poco hilada en algunos aspectos.


Y la última charla … y probablemente la más floja de las que pude ver, empezó a las 13:00 sobre “VxRack Flex: Architecture Overview“, a cargo de Doran Tal, del equipo de producto.

Centró su charla úncamente en VxFlex OS, el antiguo ScaleIO y sus características y funcionamiento:

Honestamente no se aportó nada sobre una presentación estándar de ScaleIO, y admás el ponente era horroroso, así que fue más una secuencia de slides que nada más…

Se habló de los componentes de ScaleIO:

  • SDC: pieza software que permite el consumo de almacenamiento. Habrá tantas como nodos de consumo de storage se necesiten.
  • SDS: pieza que aporta almacenamiento al sistema. Habrá tantas como nodos que provean de storage se necesiten.
  • MDM: pieza única (o con la redundancia que se quiera) que gestiona el cluster de almacenamiento que conforma ScaleIO digo VxFlex OS.

Luego explicó las características de cada uno de los tipos de nodos y ejemplos de lo que sucede ante operaciones de lectura y escritura, recalcando laa escalabilidad de la solución ,el rendimiento que proporciona etc:

Tras esto se habló de los diferentes modelos de arquiecturas disponibles en modelos HCI dónde los nodos sólo consumen o adhieren almacenamiento (modelo tradicional de 2 capas), mixto, o la aproximación moderna en la que todos los nodos tienen los dos roles.

Se continúo con un par de ejemplos del rendimiento que proporciona la plataforma:

E incluso una comparativa contra un Array clásico HPe 3PAR:

Y continuando con las caractterísticas del producto, se explicó su modelo de paridad para la protección de la información:

Y cómo se comportaba:

Así cómo la flexibiidad del sistema ante fallos, rebalanceos, etc.

Y cerró la tediosa charla hablando de los dominios de protección.

No fue el final ideal para las charlas técnicas, pero como repaso de ScaleIO no fue mal…


Y con esto y un bizcocho (literalmente había brownie a la salida de la charla), acabamos las sesiones del DTW 2018. En breve otro post con las conclusiones finales.

[Y cierro está edición desde el avión cruzando el Oceano, esto de la tecnología es la leche]

No hay comentarios

¡Se el primero en comenzar la conversación!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.