Microsoft Ready – Feb 2019. Day 3.

15 febrero, 2019 — Deja un comentario

Disclaimer: Es un evento interno con el contenido bajo NDA, así que compartiré los mensajes fundamentales “públicos”, pero no detalles o fotos. Adicionalmente recordar que este Blog expresa mis opiniones personales y en ningún caso supone una opinión formal de mi contratador. 

Este día me perdí la primera sesión por estar ocupado con cosas del trabajo, tampoco lo eche de menos porque era una sesión de mesa redonda con un CTO con el que ya había estado en la reunión interna del sábado, así quedado que este día no había KeyNote salté directamente a una charla de “Technical Overview of Azure Cosmos DB” impartida por un gran ponente, Luis Bosquez Gonzalez (Program Manager)

Inició su charla analizando los diferentes casos de uso del producto y ligándolos con casos de éxito de clientes (que por tema de NDA no puedo contar), dejo los casos de éxito en inglés para no perder contexto en la traducción:

  1. Need for highly available DB service
  2. Highly variable workload demand
  3. Need for failvoer replication systemm
  4. Unstructured no relational data modeling
  5. PaaS Opend Source – non relational DB like Apache Cassandra / Mongo
  6. Globally distribute data

Luego se analizó el Roadmap ejecutado en 2018, cosas ya disponibles actualmente en el producto cómo:

  • API para Cassandra.
  • Capacidades de Multi-Master.
  • Ancho de banda controlado a nivel de base de datos.
  • Más certificaciones de seguridad.
  • Mejoras en los exploradores de datos y de almacenamiento.
  • Mejoras en el API de Gremlin.

Y tras este breve resumen de novedades ya disponibles, se pasó a la definición de Cosmos DB (de nuevo en inglés): globally distributed, massively scalabale & multi model DB service.

Y todo lo anterior, garantizando latencias de 10-15ms R-W en el percentil 99 de las operaciones,y cuando se dice “garantizado” significa que hay un compromiso económico de Microsoft en caso de incumplimiento (si no lo entendí mal).

Permite diferentes modelos de almacenamiento:

  • Par clave valor
  • Columnas
  • Documentos
  • Gráficos

Dependiendo del interfaz que empleas:

  • Table API
  • Cassandra
  • SQL
  • Mongo DB
  • Gremlin (para gráficos)

Me quedó pendiente analizar la matriz que cruza los modos de almacenamiento con las APIs empleadas, pero algunas son obvias.

Hablando de la gestión de costes, uno de los logros del sistema es reducir dramáticamente el TCO, y en parte es por el concepto de “Request Units” para la escalabilidad de la solución. Luego se hablo de particiones y los problemas algorítmicos derivados del Skew (podría traducirse como “sesgo”) de la información dependiendo de la clave de partición.

Cerro la charla hablando de la globalización de la Base de datos, no porque fuera el tema menos importante sino porque es lo que todo el mundo asocia a Cosmos DB y quería recalcar que “sólo es una más” de sus características.

 

La verdad es que este producto parece realmente diferencial y tengo que profundizar en el, así que al día siguiente me apunté a otra charla 🙂


La siguiente charla del día fue sobre “Let’s talk about Kubernates as Infrastructure” por Gino Filicetti y Peter Laudati, ambos CSAs de la bella New York.

Los objetivos de la sesión eran explicar como funciona Kubrnates (en adelante K8S) y como puede ayudar a la escalabilidad y gestión de los entornos de producción. Y también demostrar el valor de AKS (Azure K8S service) simplificando la vida con K8S a través de un servicio gestionado para operacionalizar los despliegues de una forma más sencilla.

Arrancaron la presentación con la explicación clásica de que son Contenedores

Gracias a Dios no entraron en la discusión de “virtualización contra contenedores”, de hecho dieron por supuesto que los contenedores funcionan sobre una plataforma virtualizada. Por eso la imagen de arriba está mal; no he sido capaz de encontrar la correcta, pero realmente en el caso de la derecha (contenedores), también había un hipervisor, con una sola máquina virtual que contendría el motor de contenedores. De este modo aún logras aislarte de toda la complejidad de la infraestructura, sistema operativo etc, a través de su virtualización.

Explicaron en detalle un ejemplo de contenedor con Docker y su fichero de configuración. Tras ello pasaron a explicar el registro de contenedores, Docker Hub o Azure Container Registry.

Una vez que se ve el aumento de VM’s con más y más contenedores, ¡llega el caos! y surgen dudas  sobre cómo realizar el parcheado, cambios de versiones etc y de ahí así sale la idea de un orquestador de contenedores. Este orquestador se encarga de ver todas las máquinas virtuales y contenedores como 1 “Cluster” para su gestión. K8S es uno de esos orquestadores, el más popular.

K8S llama “Master” a cada uno (habrá muchos si quieres alta disponibilidad) de los orquestadores en si, y nodos a las máquinas virtuales que gestiona. AKS (Azure K8 Service) es la oferta en modo “As a service” de K8S dentro de Azure.

Con AKS el despliegue se puede hacer manualmente o a través de IaaC (Infraestructura como código) con un fichero YAML. Dentro de la arquitectura mencionar que los POD (configuraciones únicas de un orquestador, si no entendía mal) piden cuanta CPU y memoria necesitan, y luego el orquestador se encarga de proporcionarlos.

Hablando de escalado y alta disponibilidad:

  • Se puede escalar en PODs de forma vertical añadiendo mas nodos en cada POD.
  • Se puede escalar añadiendo más nodos. Esto era una tarea manual del operador, pero AKS puede automatizarlo..

Se habló de las contribución de Microsoft al proyecto Open Source que es K8S para acelerar el escalado horizontal y pasarlo de varios minutos (cuando añades más nodos) a segundos. Luego pasaron a hablar de como llevar a cabo actualizaciones y vueltas atrás. Impresionante ver los 2 modos de actualización, o poco a poco en cada nodo y añadiendo la nueva versión simultáneamente.

Y luego pasaron al almacenamiento. explicando el porqué de la necesidades de volúmenes en K8S y las tipologías existentes:

  • emptyDir
  • hostPath
  • Cloud Volumes
  • Persisted Volum Claim (PVC)
  • ConfigMap
  • Security

Cerraron la charla con conceptos de infraestructura:

  • Red: comunicación inter-POD. Hablaron del concepto de “servicio” para aislar de las redes internas de POD, los hay básicos o avanzados, cuando quiere interactuar con vNETs.
  • El siguiente paso sería hablar de la operacionalización por ejemplo con HELM, el gestor de paquetes de K8S mantenido por la CNCF.
  • Y por último se habló de la monitorización, dónde se tiene la opción de usar K8S Dashboard o Azure Monitor para AKS pero hay muchas heramientas más (Prometheus, HEapster, Datadog, New Relic, etc).

 

La última parte se me hizo cuesta arriba, pero en general me pareció una charla muy escalarecedora de lo que se está haciendo alrededor de K8S y como AKS ayuda con los retos de los mundos de los contenedores.


La última charla del día fue sobre “Serverless for the Enterprise” impartida por Matthew Henderson (Senior Program Manager) y Alex Karcher (PM de Azure Functions).

Los objetivos eran presentar y demostrar el estado del arte de las Azure Functions. Y también como diseñar soluciones que aplican las best practices de seguridad, DevOps y monitorización. Explicaron rápidamente los beneficios del mundo serverless y los soportaron con varios casos de uso:

  • Foco: centrarse en solucionar un problema de negocio, no un problema de la tecnología subyacente.
  • Eficiencia: minimizar el “time to market”, reducir los costes fijos por costes variables (de la ejecución de la función). Mejor estabilidad del servicio…
  • Flexibilidad: experimentación más sencilla, simplificación de la pivotación, escalado más sencillo.

Mostraron la plataforma de Azure Serverless para apps gestionadas por eventos*:

(*) Existen diferencias entre está imagen (pública) y la mostrada en el evento (bajo NDA). 

La idea principal es “Foco en el código, no en las tuberías”. La suma de los eventos y el código (Azure Functions) genera las salidas requeridas, de forma transparente a la plataforma que exista.

Los lenguajes que emplea ahora mismo son .Net y Node.js pero están ya en “preview” pública Java y Python, se espera en breve Powershell y muchos otros por llegar.

Así que, ¿Dónde lo desplegamos?, básicamente en cualquier sitio*, incluyendo entornos locales:

(*) Existen diferencias entre está imagen (pública) y la mostrada en el evento (bajo NDA). 

En la fase final de la charla se habló de los últimos anuncios cómo la versión 2.0 de Azure Functions, actualizaciones de seguridad, mejoras en la integración con el mundo Linux y más cosas.

Se explicaron los escenarios más habituales:

  • Desarrollo de aplicaciones móviles.
  • BackEnd de aplicaciones de IoT.
  • Procesamiento en tiempo real.
  • Automatización de infraestructura.
  • etc.

Y tras esto se pasó a hablar de detalle de arquitectura bajo NDA, dónde se bajo y mucho al detalle técnico.

 


Un día breve pero intenso dónde aprendí mucho de tecnologías que seguro que marcan el futuro de cómo se desarrolla en Azure en el futuro próximo!

 

 

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.