Pero… ¿qué es eso de Cloud Native?

Probablemente uno de los términos más usados últimamente en el mundo tecnológico es el de “Cloud Native”, pero a la vez también uno de los mas confusos de entender o con el que probablemente haya mala interpretación de su significado, que sí es una tecnología (¡contenedores!), que si es un tipo de aplicación, que sí es una forma de trabajo, que si tú proveedor te brinda esa facilidad, pero lo que haremos ahora es tratar de tener adquirir un poco de mayor claridad respecto a este concepto y ver cómo podemos adaptarlo en el día a día.

La primera vez que tome conocimiento del concepto fue fácil asociarlo con algo relativo a las aplicaciones cloud y entendí originalmente que Cloud Native eran aplicaciones que estaban hechas para sacar partido de las características inherentes a la nube: escalabilidad, pago por consumo, etc; pero de igual manera me dí cuenta de 2 cosas: que eso no era todo pero que el concepto de cloud native se había vuelto un comodín para promocionar cierto tipo de tecnologías en concreto, como veremos más adelante así que empecé a investigar. Finish Reading: Pero… ¿qué es eso de Cloud Native?

Tu estrategia cloud pasa por (re)aprender a comprar

El reciente anuncio de AWS , sobre el lanzamiento y futura disponibilidad de Aurora Serverless V2 , me ha hecho regresar a unas reflexiones, acerca de cómo la nube nos obliga a enfocar las compras de otra forma, pues de otra manera no sacaremos ventaja real de las innovaciones que trae esta tecnología, que (se supone) queremos introducir como parte de nuestra estrategia tecnológica y (sobre todo) de negocios.

Empecemos con la contextualización, en una forma simpática:

En este tweet Javi nos recuerda, de manera sencilla, los esquemas de trabajo usuales en Bases de Datos (y extrapolables a casi servicio de cómputo): para evitar quedarnos cortos de capacidad de proceso las organizaciones estiman “hacia arriba” la capacidad que necesitarán (usualmente servidores y número de cores) para cierto requerimiento, con lo cual damos “tranquilidad” a la organización si dicha aplicación es de misión crítica (al precio de tener capacidad sin usar durante buenos tramos de la operación); vamos, lo usual en el mundo on-premise y tiene cierto sentido porque el agregar, retirar, o cambiar de uso a un conjunto de servidores no es cosa sencilla. Claro, me dirán que la virtualización y tal, pero nos olvidamos que aún en un esquema virtualizado trabajamos con un “colchón” grande para ir asignando sucesivamente la capacidad demandada, por lo que para este análisis prescindiremos del modelo de virtualización gestionado por la organización.

El caso es que el anuncio de AWS pone el foco en dos factores claves de lo que ha sido la “propuesta cloud”: escalabilidad y pago por uso. Sí pues… lo que hemos venido escuchando en los últimos 10 años “arranca con un servidor y escala automáticamente según la demanda y sólo paga a fin de mes por lo realmente consumido”; sí, el argumento no es nuevo y no deja de ser cierto, la diferencia es que usualmente este argumento ha sido orientado a las aplicaciones (generalmente web), no a las BD.

En ese sentido, esto continua la senda de los últimos dos o tres años: más ofertas de bases de datos serverless como SQL Database, la v1 de Aurora Serverless, y hace poco Cosmos DB. Estos movimientos de la industria deben indicarnos por dónde van las tendencias; que el viejo modelo de mirar sólo el número de servidores, nodos o cores a desplegar debe cambiar ya; que además de considerar PaaS y Serverless para el desarrollo de aplicaciones (como ya hemos hablado antes), no podemos ignorar ese rumbo de la industria.

A todo esto, si quieres entender un poco mas sobre el modelo serverless (y en este post hablaremos mucho de el), hace poco escribí la serie de artículos Serverless: Realidad y perspectivas (1), (2) y (3) que seguro te servirá.

Finish Reading: Tu estrategia cloud pasa por (re)aprender a comprar

¿Psicosociales en el mundo de los contenedores? Kubernetes depreca a Docker

El día de ayer, buena parte del mundillo informático se sacudió con una noticia, que si bien ya se veía venir, por el lenguaje utilizado causo revuelo y preocupación, veamos:

Docker support in the kubelet is now deprecated and will be removed in a future release.

Esta nota formaba parte del log de cambios de Kubernetes, lo cual iba en la línea de un anuncio anterior donde se anunciaban este objetivo por parte de Kubernetes.

Obviamente las preguntas saltaron, ¿ya no podre seguir usando Docker si quiero trabajar con Kubernetes? ¿Qué pasara con el soporte para contenedores en Windows?, y la verdad la respuesta tardó algo en darse, y de eso hablaremos aquí, pero antes contextualicemos un poco.

Primero, veamos la parte técnica, a estas alturas en el mundo informático ya el concepto de contenedores esta mas o menos establecido, que la equivalencia con los contenedores usados en el transporte marítimo, que es una unidad de software con lo mínimo para ejecutar en un entorno destino y asi asegurar la portabilidad, las diferencias con las máquinas virtuales etc. Dicho esto, si que debemos repasar cual es el ciclo de trabajo que la mayoría de nosotros usamos al trabajar con contenedores, por simplicidad he quitado los componentes DevOps para enfocarnos en los contenedores, Docker y Kubernetes.

  • Tenemos un archivo llamado Dockerfile que define los componentes de software que queremos empaquetar y algunas acciones alrededor, este Dockerfile actúa como “receta” para que el comando “docker build” construya una imagen que la llamaremos X.
  • En este momento la imagen X esta en nuestro equipo, por lo que ya podríamos ejecutarla usando el comando “docker run”, o publicarla en un Registro tal como Docker Hub, Elastic Container Registry o Azure Container Registry, para lo cual usaremos “docker push”.
  • Con la imagen X subida en uno de estos Registros, ya esta lista para ser usada en diversos ambientes (generalmente en la nube), tales como Azure Container Instances, una máquina “convencional, Elastic Beanstalk y… Kubernetes, para lo cual este entorno destino deberá hacer un “pull” contra el Registro respectivo.

Entendiendo este gráfico podemos ver el porque de las dudas, si hemos subido nuestras imágenes apoyándonos en las funcionalidades de Docker… ¿quiere decir que en un futuro ese flujo va a cambiar?, bueno… para responder esta pregunta toca revisar un poco el como hemos llegado hasta aquí. Finish Reading: ¿Psicosociales en el mundo de los contenedores? Kubernetes depreca a Docker

Azure Upward: Advanced DevOps Hands On Workshop (materiales I)

El día de hoy estare participando en el Azure Upward: Advanced DevOps Hands On Workshop, organizado por Microsoft, donde hablare sobre Azure DevOps, Web App for Containers y algo sobre microservicios, y para esto he preparado una demo que basicamente consiste en contenerizar un proyecto web, desarrollado en .Net Core, publicarlo en el Azure Container Registry, y desplegarlo en dos slots de Azure Web App for Containers.

Para la demo me he basado en el código fuente de la segunda edición libro Entity Framework Core in Action de Jon P. Smith, asi que he hecho un fork para que ustedes puedan replicar la demo en sus casas, siendo así los archivos que he agregado al código original son los siguientes:

.dockerignore
azure-pipelines.yml
BookApp/Dockerfile

Como mostrare en la sesión la idea es crear un pipeline en Azure Pipelines, basandonos en un repositorio GitHub, por lo que tienen dos opciones hacer un fork del código original de Jon y agregarle una copia de los tres archivos mencionados, o hacer un fork de mi fork, queda al gusto de ustedes.

Como es logico, es necesario contar con un Azure Web for Containers, un Azure Container Registry, y enlazarlos adecuadamente a nuestro Azure DevOps, pero creo que eso me da para un video corto que voy a preparar, de momento les comento que para poder usar el pipeline es necesario definir unas variables, como se indica en este grafico, pues de lo contrario el pipeline no se ejecutara.

Bueno, espero que la sesión les sea de utilidad, cualquier consulta me la dejan en los comentarios por si hay algo que falta precisar. Feliz despliegue!

 

 

 

 

Presentando las Static Web Apps

Un stack de desarrollo integrado para la creación de aplicaciones frontend estáticas, pero apoyadas en un backend basado en Azure Functions, sumado a un ciclo sencillo de trabajo y despliegue basado en GitHub Actions, eso es lo que nos ofrecen las Static Web Apps, presentadas hoy en el Microsoft Build, que como todos saben se ha llevado a cabo de forma online debido a la situación actual.

Ojo, el termino “estático” puede llevar a confusión, pero los desarrolladores de JavaScript entenderán que se hace referencia (*) al modo de trabajo usado para desarrollar SPA (single page applications) donde si bien solo se envian recursos estíticos al browser del usuario, la aplicación en si ofrece mucho dinamismo e interacción, pues bien esta nueva tecnología otorga a estas aplicaciones (basadas Angular, Vue o React) la posibilidad de contar con el poder y escalabilidad del serverless como backend de una forma integrada, esto basado en el patrón Jamstack que nos propone una abstracción respecto a los servidores para lograr una mayor eficiencia operativa.

De esta manera logramos tener un único repositorio de GitHub, donde estarán todos los recursos y servicios necesarios para nuestra aplicación, que sera el punto de partida para el ciclo de despliegue en minutos.

Bueno, eso dice la teoría, pero si quieres ver esto en acción… aquí te dejo el video para que veamos el potencial de esta nueva plataforma:

Bueno ¿què tal les ha parecido? a mi me ha gustado mucho esto de poder trabajar tanto tu backend y frontend como un proyecto integrado y lo fácil que es desplegar y jugar con las ramas.

De momento el proyecto esta en Public Preview, por lo que puedes empezar a probarlo ya, para lo que te dejo aquí el enlace a la documentación.

(*) Esta tecnología también es aplicable para generadores de sitios estáticos como Hugo, Jekyll o Hugo, con los cuales recién me estoy topando, por lo que no puede describir como seria su experiencia de integración con las Static Web Apps.

Aprendamos Azure Pipelines (con videos)

Curiosamente una vez que esto de la cuarentena se hizo que las comunidades se adaptaran y empezaran a proponer eventos online, así en Agile Perú organizamos, junto al a comunidad Agile Uy, el meetup “Retros remotas desde las trincheras”   que cubrio temas muy interesantes de como enfocar nuestras retros cuando los equipos no estan juntos, situación que durara por un buen tiempo, y que creo que cubrio varias de las dudas que mencione en mi post anterior, si no han visto el video, haganlo, Camila se lucio en este meetup.

Y por el lado de las comunidades Microsoft, las cosas han estado muy activas, tan asi que el 25 de abril participe en dos eventos el Virtual Azure Community Day, organizado por el Microsoft Users Group Perú, y en el Global Azure Latinoamerica, organizado la Comunidad Xamarin en Español; en el primer caso hable sobre “Despliegue de Aplicaciones Serverless con Azure Pipelines y Azure Functions“, para luego exponer “Mejora la seguridad de tus despliegues con Environments en Azure Pipelines“, la verdad es que estaba nervioso, la expectativa sobre los eventos era alta, pero felizmente todo salio bien y además hubo algo que aprovechar….

Resulta que en mi sesión sobre Environments (tema del que ya he comentado en este blog) se me pregunto por la disponibilidad del YAML que use para mi demo, y luego me recomendaron hacer un paso a paso de como crear un multi-stage pipeline, como un paso previo a los conceptos de seguridad que explicaba sobre Environments, así que prepare este video sobre como crear tu primer multi-stage pipeline en Azure Pipelines:

Y como es lógico también comparto el YAML usado en esta demo, la cual es efectivamente una preparación para ver lo explicado en la sesión sobre seguridad y Environments:

Y ya como bonus track les dejo mi presentación sobre serverless y Azure Functions.

Espero que les sea de utilidad!! Ya en breve estaremos hablando de las novedades que se trae el Build!

Nuevamente en las trincheras del trabajo remoto

Si pues, de momento dejaremos nuestra tónica habitual dedicada a la nube y DevOps para comentar algo que, junto a la cuarentena, ha sido uno de los tópicos en estas semanas: el teletrabajo, trabajo remoto, home office, y similares, que no son lo mismo, hay matices, pero no son sujetos de lo que vamos a ver.

Digo de vuelta, porque para mi no es la primera vez que tengo que pasar por estas circunstancias de desarrollar mi trabajo lejos de mis colegas/clientes/proveedores etc, que es básicamente la situación en la que nos encontramos ahora, para lo cual me basare en mi experiencia personal, que si bien no es la fuente de la verdad única me ha permitido extraer algunas conclusiones que espero sean de utilidad.

Mi primera experiencia fue cuando, transicionando entre proyectos, se me pidió hacer una propuesta comercial para la consultora española en la que me encontraba, me tomo alrededor de una semana el completarla, y la primera vez si que fue complicado, pues estar en mi habitación ponía cerca la disponibilidad de reposar un rato y no enfocarme en mis responsabilidades, pero aun así el documento salió adelante y le gusto a mis jefes, pero desde ese entonces me quedo clara la importancia de separar el ambiente de trabajo del de tu reposo, solo que entonces no era posible pues alquilaba habitación.

La segunda situación, intermedia, correspondió a cuando, al regresar a España desde Sudafrica, tuve que hacerme cargo de un equipo de desarrollo en Madrid, pero por la naturaleza del proyecto, se tenían que hacer coordinaciones con el equipo en Joburg, en ese momento las cosas estaban bastante limitadas:

  • No había nube
  • Las transferencias por VPN eran lentísimas
  • Los servicios de voz por IP eran poco fiables

Aun así, logramos adaptarnos, los correos eran muy fluidos, y eventualmente tenia llamadas interdiarias con el QA en Joburg, pero lo de compartir pantalla sencillamente no era viable. Felizmente esas limitaciones ya son historia, pero queda como punto claro la importancia de la disponibilidad de buenos canales de comunicación para los equipos.

La tercera experiencia fue cuando me tuve que hacer cargo de gestión y mantenimiento de varias aplicaciones para la sede española de una multinacional de investigación de mercado, en este caso sí que estaba en la sede del cliente coordinando con la gente de infraestructura y los usuarios, pero tenía que coordinar y asignar tareas a alguien trabajando en la India, el problema es que las formas de asegurar el entendimiento por ambos lados nunca se formalizaron, ya que tiempo después me di cuenta de que cuando preguntaba “Do you understand?” la respuesta de “yes” casi nunca era cierta, amén de que habiendo posibilidad de usar Webex para efectuar las comunicaciones, o chat para cosas urgentes, mi contraparte prefería llamadas por teléfono convencional (con menor calidad de audio), lo cual sumado al hecho de que estaba en un proceso cross o multiprojecto, no permitía un flujo adecuado en el desarrollo de nuestras actividades, esto, en retrospectiva hace clara la importancia de definir o setear los “protocolos” y canales que se usaran para las comunicaciones, y en todo caso generar “actas” que aseguren el entendimiento común de las conclusiones de la reunión.

En los siguientes años la experiencia fue mas frecuente, de la mano con mi regreso al Perú y al trabajar en la mayoría de los casos en proyectos que trataban de seguir marcos agiles, pero con la peculiaridad de que nuestros clientes estaban fuera del Perú, no siendo raro que la mitad del equipo estuviera en Lima, y el resto en otro país (Costa Rica, Argentina, España, USA) solo que en este caso se mezclaba la peculiaridad de ir unos días a la oficina, y a veces trabajar desde casa, por lo que las lecciones en este caso son variadas:

  • Si quieres poner a tu equipo en una sala (para hablar con la otra mitad del equipo), asegúrate que has validado bien el alcance de tus dispositivos para no tener a tu gente gritando.
  • Tener dos pantallas es bueno, pues por un lado ves a tu contraparte, y en la otra pantalla están ambos haciendo el code review o similar.
  • Por otro lado, una segunda pantalla también tiene el riesgo de que ayuda a no ponerle total atención a la reunión en curso.
  • Saber que tienes a tu contraparte a un clic de distancia para tener un chat, y de ser necesario una llamada, ayuda mucho a generar una sensación de equipo pese a la distancia.
  • Una cultura de Pull Request y aprobación/rechazo rápido ayuda mucho, mucho.

Mención aparte es un problema sobre el cual no he tenido mucha respuesta que ayudara en algo, y es el tema de las Retrospectivas cuando tienes equipos distribuidos (ya sea en casa o en distintas sedes de trabajo), pues cuando empecé con esto de los marcos ágiles, casi todas las dinámicas que se enseñaban o comentaban partían del supuesto de tener todo el equipo en un mismo sitio (recuerdo un libro de varias dinámicas muy interesantes, pero ninguna orientada a equipos distribuidos), que si, que habían herramientas para ayudar en el tema, que básicamente te permitían escribir tus comentarios (Que se hizo mal, Que se hizo bien, Como mejorar) de manera oculta y luego destaparlos, lo que ocasionaba que las retros terminaran convirtiéndose en un Dia de la Marmota.

Si recordamos lo que aprendimos en agilidad, mucho se basa en el ir aprendiendo, evolucionando, mejora continua y todo eso, siendo que si una actividad se vuelve repetitiva… poca ganancia se puede sacar. Una de las pocas mejoras que conseguí en un equipo fue que se rotara al facilitador, lo cual logro que el diferente “estilo” cada vez lograra un mayor dinamismo por parte del equipo, pero eso no es suficiente; así que en esa época en la comunidad consulte a diversos coaches, y gurúes que venían a compartir sus conocimientos y experiencia (en algunos caso muy valiosos), obteniendo generalmente miradas al techo… y alguno en algún arranque de sinceridad me dijo que siempre en sus clientes había trabajado con todo el equipo de manera presencial, y claro es que los equipos que trabajamos offshore nunca habíamos sido el “blanco” de sus actividades, situación que ahora veo que cambia a toda prisa, debiendo improvisar en campos en los que no habían incursionado, ojala que en esta ocasión se escuche a quienes han tenido experiencia real en este aspecto y que hayan podido resolver este impedimento (*).

En todo caso, lo que he comentado hasta el momento tenia una peculiaridad muy muy fuerte, y es que estos equipos en los que participaba estaban orientados hacia un único proyecto/producto, por lo que siempre se tenia el foco de manera clara, pero mi situación actual es diferente, y se podría decir que estoy en un proceso de aprendizaje.

¿Por qué? Desde hace un tiempo he asumido un rol de arquitecto cloud, lo cual por su naturaleza obliga a trabajar en varios frentes de batalla a la vez: revisión de iniciativas para su aprobación, apoyar proyectos en curso, coordinar actividades con otras áreas para establecer algo en conjunto, etc., un reto interesante que obliga a tener otro tipo de orden, en el cual te acostumbras a las charlas de pasillo y a sacarle partido a ellas para aprender mas de los distintos contextos con los que hay que lidiar.

El detalle es que cuando pasas de golpe a un escenario de Home Office colectivo, todos pasamos a un proceso de aprendizaje, reinventando reglas, nuevas formas de coordinar, a lidiar de otra manera con el context switch, con la gestión de las agendas, es un camino que vamos empezando, del cual espero dar conclusiones u opiniones mas definitivas como las he dado para mis escenarios anteriores.

¿Y uds? ¿Qué experiencia o buenas practicas pueden compartir respecto al trabajo distribuido o remoto?

(*) Me comentan que en los últimos dos años han surgido herramientas que ahora si apoyan el poder hacer una buena retro con los equipos distribuidos, soy todo oídos.

¡Añade aislamiento a tus despliegues con Environments!

Regresando, en plena cuarentena, a las arenas del CI/CD para hablar algo que curiosamente ayuda a lograr cierto aislamiento a tus recursos en la nube al momento de desplegar: Los Environments en Azure Pipelines, así que vamos a ello.

Repasemos un poco, cuando hemos tenido pipelines usando Designer Mode, hemos definido el despliegue (en este ejemplo hacia un Web App) mas o menos así:

Y en el caso de Multi-stage pipelines, el paso de despliegue se define así:

Si nos fijamos en ambos casos, veremos que corresponde al Pipeline definir el recurso “destino” donde haremos nuestro despliegue:Subscripción, Grupo de Recursos y Recurso (en este caso una WebApp), o sea que toda la responsabilidad recae sobre el pipeline y quienes tienen acceso a desarrollar sobre el.

Si, es cierto que podemos establecer una cierta seguridad si, cuando enlazamos nuestro Team Project contra los recursos de Azure, lo hacemos contra Grupos de Recursos acotados y no contra toda una Subscripción, algo de eso lo vimos anteriormente, pero lo que vamos a ver proporciona una abstracción adicional y funcionalidades que nos ayudaran al seguimiento de nuestros procesos de despliegue. Finish Reading: ¡Añade aislamiento a tus despliegues con Environments!

Serverless: Realidad y perspectivas (y 3)

Bueno, llegamos al final de esta serie de reflexiones sobre Serverless en el contexto actual, y empezamos dejando algo claro:

Serverless no es solo Functions as a Service.

Y ¿eso por qué? Porque si bien la referencia  a Serverless nos hace pensar en Azure Functions o AWS Lambda, debemos valorar el concepto de manera adecuada, asi que de manera preliminar digamos que Serverless es un servicio cloud en el cual no tenemos “conciencia” de cual es el servidor o servidores que nos proveen la funcionalidad deseada (lo cual no quita que podamos tener una URL referencial, ojo).

En ese sentido, pues si, un Event Hub, un Service Bus, un gestor de APIs o servicios DNS calzan dentro de la definición de Serverless, de hecho en un pasado Microsoft Ignite, el orador decía que el servicio Serverless mas usado era … Azure Storage, y claro tiene sentido bajo la premisa inicial que hemos hecho ¿no?.

Ok, la definición puede ser laxa y por eso a veces me veo el lios para establecer una definición, así que para el resto del articulo hablaremos de Serverless en tanto servicios de computo en el que podemos ejecutar el código de nuestras aplicaciones abstrayendonos totalmente de los servidores (fisicos o virtuales) que dan soporte a la operación, razón por la cual cabria considerar como tales a las Logic Apps pero no a nuestras viejas cómplices las Web Apps (y mucho menos Elastic Beanstalk de AWS). Finish Reading: Serverless: Realidad y perspectivas (y 3)

Serverless: Realidad y perspectivas (2)

Bueno continuando con esta revisión respecto a la plataforma Serverless, veamos algunas consideraciones para entornos de trabajo y como enfocarlo de la mejor manera.

Para empezar debemos recordar que nuestras aplicaciones, por lo general, viven en un contexto, teniendo interacciones con otros sistemas, fuentes y consumidores de datos, sistemas externos, etc, los cuales al momento actual en su mayoría se encuentran en entornos on premise, lo cual nos lleva al reto de como hacer que nuestras aplicaciones en la nube se integren con los componentes on premise. Si nuestro ecosistema nació íntegramente en la nube (sin que eso implique ser cloud native) no es que no haya retos, pero son diferentes y a ellos nos enfocaremos en otro momento.

Lejanos son los tiempos en que las organizaciones podían tener todo un conjunto de direcciones IPV4 publicas a todos los equipos de sus organización (si, yo viví esa época en tres de mis primeros trabajos), ahora la escasez de direcciones IPv4 como las necesidades de asegurar los recursos frente a ataques e intrusiones, nos ha llevado de manera natural a un escenario en que los recursos criticos de computo de nuestras organizaciones hagan uso de direcciones IPv4 privadas, y claro, con segmentos de red dedicados y protegidos detrás de un firewall, dándose “confianza” de acceso solo a equipos dentro de la red propia de la organización (la excepción, claro, se da cuando es necesario exponer servicios al publico o a agentes externos).

Entonces cuando se aborda el crecimiento hacia la nube, un paso natural y conveniente es tratar (con las limitaciones de ancho de banda) de considerar a la nube como una continuación de nuestras redes privadas, para lo cual se habilitan VPNs, enlaces dedicados, nuevas reglas de firewall, se asignan segmentos de red (en el caso de Azure se denominan VNETs y en AWS VPCs), pero… Finish Reading: Serverless: Realidad y perspectivas (2)