 ¡Hola! ¿Cómo estás? ¡Portuñol de Calidad ahora! Sí, sí, directo de Barcelona como mi colega. Y feliz por estar hablando un poco de español. Pero es un poco difícil hablar con ustedes en español un poco. Entonces, por tu catañón. ¡Oh, Dios mío! Ahora el Portuñol está completo. Sí. Y yo estoy muy interesada en tu talk a respecto de OpenShift. Tú vas a cubrir todo lo pack desde lo desarrolló, ¿Until lo deployment? Sí, un poco. Sí, voy a hablar un poco más abstracto de OpenShift y arquitectura. No tengo una demo tan interesante como las anteriores en el punto de vista técnico, pero creo que muchos gaps y cosas que a veces la gente no conoce de contenedores, de OpenShift y de well-architected son conceptos que se casen muy bien en la plástica. Sí, ok. Ok, muy bueno. Entonces, ¿puedes comenzar tu talk? Nosotros estaremos aquí en el backstage. Gracias, Karina. Entonces tengo una experiencia muy místa. También esta es una charla muy personal de una suma de experiencias que tengo con Amazon, con Red Hat, con ustedes que hace más de 10 años que he trabajado con Cloud y trago aquí un poco de perspectiva. Entonces, me llamó Julio, Ferman J. en Twitter y bueno, tengo dos trabajos, como una gente doble. En un colectivo llamado Caravana Cloud hay unos desarrolladores con el próximo paso en sus carreras de tecnología. Entonces hacemos pláticas todas las semanas juntos. Hoy, por ejemplo, trabajamos en un algoritmo de grafos, después hablamos de entrevistas reales y problemas que no son solamente técnicos, pero también como inglés, como ansiedad, como comunicación, comportamiento y todo lo que pasa en este tema de la mayoría de carreras. Eso en caravana.cloud. Y en Red Hat, soy ingeniero de software principal en el time de OpenShift, en un equipo que se llama Platform Specialists que intentamos mejorar la experiencia de uso de OpenShift, nuestra plataforma de contenedores, en plataformas específicas, en mi caso bien reaccionado con Amazon. Entonces, es natural que voy a hablar un poco de este mundo y de entornos en Amazon, pero también en otros contextos de qué sentido hace hablar de OpenShift y también algunas buenas referencias. A mí me gustó mucho la idea de libros, también en la próxima charla voy a hacer de una iniciativa de referencia. Me gustaría empezar por entender exactamente por qué usar Kubernetes hoy y qué sentido hace. Tengo muchos amigos que me preguntan por qué si tenemos la capacidad de usar cualquier proveedor de nube que sea sin tanta complexidad que sentido hace tener contenedores de Kubernetes hoy que no sea solo con discusiones vacías o que sentido técnico realmente hace. Entonces, mismo yo teniendo del cloud para mí fue difícil entender qué tipo de entorno de eso hace sentido. Bueno, entonces hay algunos puntos que creo que son importantes. Uno, que realmente es la nube. Sus servidores, sus racks, sus servicios, eso es parte de computación en nube, eso cuenta como computación en nube y para mucha gente sí, hay, seguro que hay empresas que pueden cambiarse a un entorno totalmente de nube pública y ya está y felices con Amazon, con Azure, lo que sea, pero también mucha infraestructura particular en bancos, en telecomunicaciones en un montón de entornos que a veces no son tan sencillos de migrar porque por ejemplo a veces tienen hardware dedicado o que ya son una inversión en tecnología muy grande que hay que sacar provecho. Entonces, eso es también parte a veces de una solución de nube. Y hay que pensar en más que servidores, en más que racks porque hoy tenemos arquitecturas diferentes en los sistemas operacionales diferentes. Entonces, en la última versión de OpenShift, empezamos con OpenShift para ARM, para arquitecturas ARM y para Windows de Bring Your Own Hosts y también seguro de los tradicionales sabores de Linux y todo más. Entonces, miramos que para muchos clientes hace sentido pensar en nube como siendo más lo que servidores virtuales y también alcanzan otros tipos de workloads. Y si pensamos en más que aplicativos y móviles, tenemos también necesidad de computación en entornos que nos leveran a repensar totalmente que significa el entorno productivo o production. Mira que en escenarios de 5G, por ejemplo, si miren las especificaciones y cómo funciona por dentro del 5G, las latencias y las necesitudes de baja latencia son tan fuertes que el servicio no se puede ejecutar físicamente lejos de a veces las antenas y los radios y hay que tener la gestión de clusters ahí mismo. Y también pasa parecido con sistemas de satélite, con sistemas de IoT, con coches o que a veces el software, el deployment y objetos gerenciados están en este tipo de infraestructura tan rara. Entonces pensando en estos tipos de entornos hace sentido pensar en coberrentes, en strength, entonces el caso más directo es que podemos pensar en utilizar las mismas herramientas de gestión de contenedores que tenemos en servidores, en máquinas virtuales, en antenas, en coches guiados y todo tipo de servicio de computación. Pero eso causa un dilema en una situación difícil porque al mismo tiempo hace sentido hacer coberrentes de todos y todos que sean todos coberrentes. No creo que sea verdad para muchos clientes. Entonces, por ejemplo, si miramos en Amazon hay centenas de servicios, centos de servicios, no sé, que se puede utilizar y que serían muchísimos trabajos de hacer manualmente uno a uno, por ejemplo, si quieres un servicio de media a veces no hace sentido desarrollarlo todo el cero, mismo que con coberrentes. Pero eso es un caso fácil y base de datos, es mejor tener la base de datos dentro del cluster de coberrentes o en el servicio de Amazon RDS, Aurora, Postgres, lo que sea. Entonces, esta es una una tarea, una decisión difícil hoy para muchos directos. Yo pienso que en muchos casos Amazon, por ejemplo, tienen una experiencia y productos geniales de base de datos como Aurora y no hace sentido para la aplicación ante toda la complexidad de redundancia, tolerancia, files y cosas así para la aplicación. Pero seguro que hay entornos tengo clientes, por ejemplo, de gobierno que no es una opción ejecutar una base de datos para determinados workloads fuera de sus raids. Entonces, esto es muy difícil de acuerdo con cada entorno, cada opción, cada proyecto. Pero una qué sentido hace, entonces, pensar en diferentes tipos de coberrentes porque cada proveedor de servicio, cada proveedor de nube puede ofrecer ventajas diferentes y tipos diferentes de coberrentes en funcionalidades diferentes. Entonces, es un poco importante entender que hoy es muy difícil decir de coberrentes vanilla o coberrentes standard porque todo proveedor tiene sus capas de seguridad de autorización de valor de cosas que se van a añadir a coberrentes para entenderlo. Una fuente genial de contenido, es LearnCates. LearnCates es una institución que es de terceros, de amigos que hacen estas pesquisas de comparación y un montón de cursos y contenidos de coberrentes que, seguro que merecen la pena. Y bueno, y eso también es verdad para Red Hat OpenShift. Es totalmente baseado en coberrentes. Es la misma compatibilidad y los mismos recursos y los mismos comandos de CubeCityL y todo funciona como hemos visto en las charlas las charlas interiores, como en las charlas de Alex todo eso sigue igual. Y en su entorno como en la nube, como en entornos híbridos. Entonces, esto es una parte muy importante de la idea del valor de Red Hat OpenShift que tiene el mismo Red Hat OpenShift con la misma compatibilidad los mismos recursos en Amazon o por ejemplo en el servicio de ajuntes, de arnos o en tuya infraestructura con VMware. Por ejemplo, entonces la idea es que si hoy trabajas en una empresa que usa VMware mañana en una que usa Azure en el otro día una que usa Amazon y no Red Hat OpenShift en todas estas plataformas puedes mantener la compatibilidad no solo de la tecnología pero de su conocimiento como administrador de sistemas como desarrollador sin tener que aprender de nuevo al ser al entorno de Amazon con las herramientas de Amazon o de Microsoft o de VMware. Entonces, es una propuesta de valor muy buena para todos los desarrolladores. Bueno, seguiendo los principios de software libre de Red Hat sigue la misma lógica de desarrollo de productos de Red Hat en el caso de OpenShift a la distribución de Kubernetes Open Source se llama OKD entonces trabajamos también con toda comunidad de OKD en desarrollo de nuevas socialidades nuevas ideas que después son parte del producto de OpenShift entonces es la misma manera que tenemos con Quarkus, con Red Hat Linux con Ansible, con muchos otros productos Open Source es parecido con Red Hat OpenShift y OKD pero eso no te resuelve todos los problemas claro, no es posible no existe una única plataforma que se adapte a todo una única talla entonces, siempre es importante hablar del well-architected porque empezar y hacer un micro-kates start y hacer un deploy sencillo es tan fácil que siempre quedamos pensando qué falta, qué hay que pensar después qué preguntas tengo que hacer después de hacer el deploy del Hello World y en un cluster de Kubernetes que es sencillo entonces, para eso hay muchas respuestas una que me gusta mucho es el programa que se llama Well-Architected qué significa una aplicación Well-Architected es una aplicación que atende sus requisitos en el punto de vista no funcional no importa mucho qué hace la aplicación pensamos que eso está correcto si es una aplicación de banco o de gasolimera o de tienda que funciona con calidad, con seguridad con configuridad, con performance con bajos costos y cosas así este es un concepto que viene de un programa de Amazon que tengo que mostrarles un minuto aquí entonces se llama Well-Architected Framework y en la página del programa tienen este documento que también voy a compartir están los recursos es un documento actualizado por Amazon es un programa mantenido por AWS y lo que trae muy interesante es que para cada uno de esos guilares seguridad, configuridad, performance no te dice exactamente las respuestas pero sí las preguntas que son importantes para cada cosa por ejemplo, diríamos aquí en Security, Identity y Access Management aquí tenemos una pregunta muy importante se llama Security 2 ¿Cómo manejas identidades para las personas en las máquinas? ¿Cómo hace gestión de identidad? Entonces aquí puede decir para contestar con A y usan el banco de datos usan el DAP usan Amazon Cognito usan un Kiko por ejemplo muchas maneras de decir pero hay que pensar es una cosa que hay que pensar igual para reliability por ejemplo miramos de confiabilidad and change management bueno ¿Cómo se hace el monitoreo de resources? ¿Cómo se adapta a cambios de demanda si tiene más o menos usuarios o consultas? ¿Cómo se hace la implementación de mudanzas por ejemplo de cambios? ¿Hace como nos ha enseñado Alex ahora poco con Tektron o con GitHub Actions o como se hace? Entonces la importancia creo que lo que quiero decir y claro es que no hay una única respuesta una manera correcta de contestar pero lo importante es ¿Cuáles son las preguntas que tengo que contestar? Que no es una cosa de magia que no se sabe y el arquitecto superseñor que tiene una visión paranormal de cuáles son los requisitos todas esas preguntas se puede medir se puede testear se puede saber si estamos haciendo bien o no y bueno si no es todo lo que existe seguro que aquí hablamos de cinco requisitos no funcionales cinco grandes áreas cada una tiene ahí como una docena de preguntas y no es todo que existe en la computación pero ya es un buen punto de partida y ya tenemos donde empezar y pensar en unas cositas que a veces no tenía pasada de por ejemplo de gestión de costes o de seguridad vale entonces merece mucho la pena una mirada en Edelweiss Weller y no que sea una verdad universal pero unas buenas preguntas para empezar y añadir tu mismo tus propias ideas, tus propias preguntas no entender el framework como una caja pero una base para construcción bueno y el framework es bien grande y hay mucho que se puede decir de aplicaciones well-architected pero creo que estas tres cosas, este tres requisitos son un poco más importantes que los otros y como esta es una foto real de un lugar para decir que es el problema de falta de seguridad alta complexidad y dificultades de colaboración vale y bueno son las cosas que veo más como amenazadoras de nuestro trabajo de nuestras aplicaciones y entonces hay que tener y son no cosas tan separadas pero hay relaciones directas por ejemplo la complejidad más complejo más difícil de mantener y garantizar la seguridad de entorno y cuanto más dificultad de seguridad, más difícil de colaborar de hacer decisiones sobre que cambio si necesita, quién va a hacerlo y cosas así mientras eso el prejuicio al usuario final algo así entonces es tres factores creo que son así muy regresaque y de prioridad en tu evaluación de well-architected de todas las cosas del framework empezando con, yo prefiero empezar con seguridad la complejidad y como hacer esta colaboración y hay muchas maneras para renunciar ese tipo de cosas no es una verdad universal la idea es no llegar a un entorno que se quede difícil de manter la idea es crear entornos solamente que se ejecuten cualquier lugar de manera portable y que se pueda hacer cambios y evoluir con la misma seguridad que tenemos en entornos de well-architected y al nivel de automación seguro que a medida que vamos respondiendo a estas preguntas y mejorando la automación llegamos a entornos que pueden ser como el de netflix por ejemplo esta es una demostración de netflix que es una librería que se llama visceral construcciones gráficas y hacen un deployment son tres regiones en estados unidos y cuando hay una un un failure rate un algo de errado en una región pueden hacer cosas como a calentar las otras regiones con un poco de trajo hasta que tengan la capacidad de continuar el servicio hacer todo el renaje de una región y miran que netflix tiene más de 35% de uso de toda internet de estados unidos en prime time entonces estamos hablando de una cantidad muy significativa de datos y un failover y failback sin que tu percebas nada en house of cards que sea lo que ves entonces es un nivel de automación que a veces merece la pena de buscar bueno y y como hacerlo nuevamente algunas algunas sugerencias bueno kitops es una parte fundamental como hemos visto en la charla de alex primero por hacer la infraestructura como código declarar los recursos de infraestructura como se fuera código que nos permiten adotar las técnicas de ingeniaría de software que trabajamos hace tantos años para el mundo de infraestructura también la colaboración facilitada por por kit y por los servicios y herramientas de kit es una regga continua de software que no se quede a meses para un deploy pero siempre en un ciclo de mejoría continua entonces son las cosas que resuelven estos problemas de seguridad de complexidad porque eso nos permite adotar los cambios de manera mucho más fácil y no tener tantos errores y problemas por hacer las cosas manualmente políticas de seguridad más precisas y todo lo que automación nos posibilita entonces en el recente de la charla voy a mostrar algunos puntos que yo pienso que me ayudan mucho cuando yo hago eso en red hat en kits de red hat en proyectos de amigos entonces es una herramienta que creo que es valguable que es terraform terraform es el punto de partida para gran parte de las infraestructuras que hago en el caso de amazon hay un a veces hay un dilema de elegir terraform o cloud formation porque a veces hay mucho que ya tenemos creado que es una otra lenguaje para hacer esencialmente lo mismo que es la declaración de recursos entonces una una sugerencia que uso en algunos proyectos es el modelo de cloud formation dentro de terraform entonces ya tiene los recursos descritos en cloud formation o si cloud formation es mejor por cualquier motivo que sea en una situación también se puede disparar el cloud formation por dentro de terraform y una otra herramienta que son muchísimos se llama AWS Nuke AWS Nuke es un script que va a borrar todo de una cuenta de amazon o todo que tenga una tag o que tengan patrones de nombres puedes elegir como quieras pero ayuda a mantener los costos y no olvidar nada ahí en ejecución entonces puede pasar estos parámetros al otro template este es un ejemplo de template de cloud formation y usar variables parámetros para hacer nombres de recursos y referencias de templates para hacer lo que posible cloud formation otra cosa como Alex comentado y vital es la posibilidad de gestión de mudancias de cambios por git o por git hub o por git lab o por la herramienta AWS code comit o lo que sé que uses como como repositorio para que en tu equipo no se quede todas las discusiones en el chat que las cosas se queden en el mismo contexto de las mudancias que se puede votar revisar nuevamente todo lo que tenemos de bueno en la gestión de proyectos con git lo usamos lo probamos tenemos proyectos de gigantes como el kernel de linux o como tantos proyectos de OpenShift o de Kubernetes y tantos otros que tenemos en git hub porque no usamos lo mismo para las discusiones de infraestructura para los cambios de infraestructura pero donde poner la configuración donde voy a meter el tamaño de la instancia el nombre la clave de lapi de otras servicios que utilizo de Amazon o de otros proveedores bueno, esta configuración puede quedarse de muchas maneras y no hay una sola manera de hacerlo pero yo sigo esta lista de prioridades de posibilidades primero, si pueden usos simples, sencillos variables de entorno es un mecanismo que suporta siempre hay una manera de pasar variables y ahí se queda fácil otra son por convenciones de nomenclatura, por ejemplo por el nombre del branch se puede saber si es un entorno de Pro, si es un tipo específico de cluster con varias cosas así también pasen algunos problemas otra manera es por el contenido del repositorio del mismo repositorio puede tener ahí una carpeta infra, por ejemplo con sus llámenes, su configuración y aplicar desde ahí estos cambios otra, como vimos en el caso de algo CD es como hacer algo CD, Tectron es tener un repositorio en general separado, puede ser el mismo pero en general es separado con estos detalles de infraestructura o mismo un servicio de terceros como HashiCorp Terraform Cloud Vault, para segredos Systems Manager de AWS pero siempre pensando que el más sencillo mejor entonces si no hay necesidad de un servicio externo un repositor externo a veces es una variable de entorno algo mucho con GitHub Actions es verdad que era la plataforma que uso más y la posibilidad de hacer el trigger de sus automaciones por un montón de automaciones por ejemplo Scheduled, todas las noches usa AWS Nuke para hacer la limpieza de mi cuenta de práctica de Amazon por ejemplo o otra vez que hay un push en un branch hace el deploy del código de aquel branch si fuera un branch que se llama prod slash una cosa que se haga deploy en prod no se cuando tenga un release hace un commit de la tag y un push para los repositorios de imágenes en Docker Hub de MQI entonces con este o mismo manualmente alguna tarea que requiera una intervención manual se puede poner ahí como workflow run entonces creo que GitHub Actions tiene un soporte de eventos que se puede hacer con estos automaciones y eso es verdad que ayuda muchísimo pero no es la única posibilidad hay también AWS Code Pipeline Tectron como vimos y muchas otras maneras de declarar eso estos pipelines de verdad que al final son una secuencia de un montón de muchos son los backends de Terraform entonces Terraform utiliza archivos locales para generar el estado de su cluster pero con backends puede almacenar este contenido de Terraform en S3, en Terraform Cloud en DynamoDB un montón de proveedores externos entonces eso es importante porque el estado de una ejecución de Terraform en GitHub Actions por ejemplo o en un contenedor muchas veces se pierde después de la ejecución entonces como vamos a volver como saber el estado de la ejecución anterior de Terraform y su estado esos archivos etcétera esos son Terraform backends y AWS S3 utilizo mucho y recomiendo a todos de una manera muy sencilla de automatizar las tareas y porque el restante en general es cortar YAML y eso se puede hacer con cualquier tipo de herramienta noto aquí este repositorio que se llama creo que Fantastic Kubernetes IL Link con todas las diferentes posibilidades de herramientas simplos de uso y otras buenas dicas para Kubernetes yo siempre la idea es mantener el más sencillo posible muchas veces con la herramienta nsust que existen todos los sistemas Linux casi es parte del get text se puede cambiar variables del entorno en archivos texto y ya está pero eso no es al fin no es ahí que termine el github siempre es importante mantener la observabilidad y tracing y toda la cuestión de salud las métricas de salud de la vida las informaciones de tracing en general comentado de metering las informaciones de performance y observabilidad en las herramientas que se usan para eso se puede usar kibana datadog promitio un montón de cosas pero es importante saber que es el normal para su entorno y cuando las cosas están ahí fuera del normal y la única manera es con observabilidad y tracing eso es una gran ventaja de cuarcos que con cuarcos y k-nade y las herramientas de observabilidad y tracing que van desde la plataforma hasta el kernel de Linux se puede saber exactamente que ha pasado con una petición con HTTP con consultas de base de datos con duros es la idea porque no es solo hacer el deploy de cluster y olvidar y ahí está tu automación debemos que mejorar la maturidad de estas automaciones entonces la primera cosa normalmente que se piensa es ir mutable sin cambiar las versiones en los recursos de hardware pero hacer un deployment paralelo y cambiar el tráfico para poder volver o cambiar de manera sencínea el uso de la aplicación y cuando tenemos esa capacidad podemos pensar bueno puedo hacer entonces no solo versión A y B pero A, B y C y D al mismo tiempo tener experiencias diferentes testes diferentes usuarios diferentes y cosas así y a veces es por seguridad por ejemplo voy a tener el entorno nuevo con la versión nueva con sólo 10% de los usuarios hasta que me quede seguro que puedo cambiar más y más usuarios así que la aplicación toda es de ahí o con otros criterios por ejemplo a mi me gustaría hacer una prueba solo para usuarios beta o solo para usuarios que trabajen en la empresa o cosas así entonces esta cuestión de deployment inmutable will be in canary hasta el cerco deployment no es como un otro pero veo como una evolución de materialidad y para eso lo que nos falta creo que es pensar mucho más en entornos multi cluster entonces veo que mucha gente intenta mantener con uno dos o pocos clusters de Kubernetes cualquier que sea el tipo pero eso es muy difícil porque cuando se tiene muchas aplicaciones en el mismo cluster es que era difícil de hacer upgrades de hacer cambios de hacer cosas así un otro punto muy importante es separar por cualquier que sea el criterio los más comunes son los tiers o purples, si es un entorno de base de datos, de red de computación, de machine learning cada uno puede tener su clase de medicano por grade o por database un entorno de desarrollo, de staging, de prod o obsoleto o sea que sea y a veces como decimos por círculos, por la respeta, versión nueva por suares premium por quality assurance hay varios motivos que se puede usar deployments en círculos separados dependiendo del tipo de software que maneja tu empresa pero en general la idea es tener más clusters más pequeños es mejor que tener cluster gigantes que se quedan difíciles de mantenernos pero si tenemos tanto trabajo a veces para mantener un cluster o dos imagina mantener una centena de clusters por eso es tan importante el concepto de operators entonces el operator es la automación dentro de Kubernetes para hacer todas esas cosas de self healing de auto scaling, de reacción a cosas que se detecta en el monitoreo que muchas veces tenemos que hacer manualmente pero nos gustaría automatizar entonces en muchos de esos casos se crean operators para cada tipo de problema de seguridad, para iniciamiento para aprovisionamiento cada funcionalidad de OpenShift o de muchas distribuciones de Kubernetes son nada más que operators entonces al final Red Hat OpenShift es un conjunto de operadores ya testeados, homologados y proyectados para funcionar bien con esta distribución de Kubernetes es una cosa que es abierta entonces no es una tecnología exclusiva de Red Hat hay un operator SVK no me pueden desarrollar tus propios operadores y como cualquier tipo de código hay operadores que son más sencillos básico y otros que cuidan de tareas de escalado de self-healing, de seguridad de un montón de cosas al nivel central en el clustering y creo que hay también más exigencias de maturidad cuando hablamos de operadores más críticos como el de seguridad o de funcionamiento por eso que este trabajo de Red Hat de mantener la calidad y la compatibilidad de operadores en una distribución de Kubernetes es también importante eso que hacemos y por eso que tiene tanto valor bueno para comentar algunos ejemplos en el Red Hat OpenShift Platform en su forma más completa hay no solo el OpenShift como los he descrito pero también Advanced Cluster Management porque no hay una herramienta para gestión de múltiples clusters el Kubernetes es de defecto entonces es un operador que permite enunciamiento de clusters de clusters vamos a decir así hay una cluster del cero en una sustitución distribuida y con la seguridad con los roles con toda la integración y automatización que se necesita también Advanced Cluster Security con verificación de imágenes control de binarios control de ecución y cosas así el Red Hat Quay para almacenamiento de imágenes y binarios y la distribución de sus aplicaciones que se puede ejecutar dentro del proper cluster dentro de tu infraestructura sin acceder a un servicio de terceros bueno y eso al final permite cosas muy interesantes en los manentos nocibros como Zero Touch Provisioning en muchos casos como éstas que se encende en una máquina y automáticamente se puede ejecutar ahí un cluster o en el caso de serverless que pueden tener en torno de nube que sea con Amazon o con Microsoft o con VMware o cualquier OpenShift que tengas las funcionalidades que tienen en un entorno de serverless como Lambda o como Azure Functions y cosas así entonces una idea que para muchos desarrolladores hace sentido yo tengo un repositor de Caravan Cloud que se llama Github's Blueprints donde tengo una pequeña colección de ejemplos con ACS con OpenShift y ahí colaboramos en el programa de aventuría un recurso que haya sido mencionado pero me gustaría reforzar es el Interactive Learning Portal de OpenShift entonces desde el básico de comandos y profesionales de clusters la parte de Github's, la parte de datos la parte de mensajería todo se puede conocer sin costes en learn.openshift.com y a quien quiera conocer un poco más de Red Hat es un lugar excelente para trabajar como desarrollador y como muchos otras oportunidades que tenemos y aquí everywhere es una charla de Bob McRitter que con Rio hace un poco de tiempo pero mostro mucho de cómo funciona eso de trabajo distribuido y cultura y equipos con colegas en todo el mundo y trabajando por el Gith con todos los deployments y todo este nivel de locomoción que hablamos entonces eso es una cosa que te interesa recomiendo mucho que miren la charla de Bob y se apliquen en las web de Red Hat me encantaría rodarles pueden me llamar en twitter siempre la gente con indicaciones encontrar las posiciones miren also in Kubernetes en Red Hat Spain.com un guía un repositor excelente con mucho más lo que puedo mostrarles aquí en una hora y también hay algunos otros recursos de Learn que en OpenShift.com mucho más en Youtube bueno creo que estamos casi en el tiempo si tienen alguna pregunta o cualquier cosa que yo pueda ayudarles lo hago con mucho gusto ahí estamos y Karina que tal se entiende wow great talk thank you gracias