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)

Serverless: Realidad y perspectivas (1)

Aquí de vuelta al ruedo con el nuevo año, en este tiempo de ausencia desde el Microsoft Ignite, le he prestado atención a un tema muy apasionante cuyo uso e interes ha ido creciendo en los últimos años: computación serverless, así que visto el estado actual repasaremos donde estamos y hacia donde podemos ir mediante el uso de esta tecnología, especialmente con las mejoras introducidas en Azure.

A estas alturas se han dado muchas definiciones sobre lo que implican los componentes serverless, pero es mejor basarnos en lo que debería componer usualmente una arquitectura/componente serverless:

  1. Abstracción sobre los servidores utilizados. Que si, al final todo proceso computacional requiere tener hardware (servidores) por detrás, pero la diferencia es que tanto nos abstraemos sobre ellos, no que no existan; nuestras queridas amigas las Web Apps ofrecen un buen nivel de abstracción (ya no tenemos que tunear el Sistema Operativo, por ejemplo), pero con serverless damos un paso mas allá, esencialmente lo que nos importa es tener donde ejecutar nuestras porciones de código.
  2. Basado en eventos. Este tal vez sea uno de los componentes mas difícil de entender, pues para lograr efectos similares, a lo que estábamos acostumbrados es a tener procesos que cada x porción de tiempo validaban si una condición se había efectuado o no, para con ello invocar la ejecución de una acción o programa. Con este modelo basicamente vinculamos una acción sobre un recurso (una escritura de archivos, una petición HTTP, la escritura sobre una cola, un timer, etc) con un programa, y listo, sera la propia infraestructura cloud la que se haga cargo de invocar nuestro programa cuando la condición se cumpla.
  3. Escalamiento inmediato. Esto es mas sencillo de entender, si tienes muchas peticiones o uso de computo sobre tu aplicación serverless, el sistema debe ser capaz de agregar las instancias necesarias para cumplir la demanda requerida, y claro reducirla cuando el pico termine.
  4. Pago por uso. Bueno, eso es lo que se tiene mas claro cuando se trata de nube, en este caso significa solo pagar cuando nuestros programas sean invocados, aunque esto tiene algunos matices como veremos luego.

Finish Reading: Serverless: Realidad y perspectivas (1)

Actualizaciones …

Pues si, he tenido desatendido este blog, pero no quiere decir que haya estado inactivo, así que resumamos brevemente lo que ha pasado en este tiempo.

Lo primero, obtuve mi segunda renovación como MVP en Developer Technologies, lo cual me motiva para seguir contribuyendo en las comunidades tecnologicas, especialmente en los temas de DevOps y Cloud 🙂

Por otro lado en septiembre tuve la oportunidad de viajar a Argentina a participar en el Ágiles 2019  donde asisti a diversas charlas, y felizmente se pudo ver cierta esperanza respecto al rumbo del movimiento, debido a que hubo varias charlas tecnicas, siendo las que mas me impactaron las facilitadas por la Gente de Grupo Esfera, bien ahí! Y ahora a esperar lo que haran nuestros amigos uruguayos para el 2020, ya que ellos se llevaron el reto de hacer nuevamente el evento en su hermoso país, siendo que en esta ocasión hay un compromiso internacional de apoyar remotamente al proceso de organización.

Y la noticia fundamental, y parte de la razón de mi ausencia, es que nuevamente tendre la ocasión de asistir al Microsoft Ignite en Orlando, donde presentare dos sesiones la primera titulada “Azure Pipelines: Evolving from Designer to YAML“, donde hablare con mas detalle lo que ya hemos visto en posts previos acerca del cambio que involucra el uso de YAML para la definición de nuestros pipelines de despliegue, el proceso de preparación me ha tenido algo alejado de este blog, pero apenas regrese compartiré el video y la sesión respectiva.

La otra sesión sera una desconferencia titulada “Sharing experiences: In the end, how do we put our stuff in production?” donde facilitare la conversación (en ingles) entre los asistentes, a fin de compartir las diversas experiencias que hemos tenido en nuestros diversos procesos de despliegue de aplicaciones a la nube.

Doble reto, pero ahí esta la diversión.

 

¿YAML Pipelines? Si, ¡fácil! (2)

Si, la evolución de Azure Pipelines hacia el mundo YAML sigue su marcha, lo cual quedo determinado con el lanzamiento de los multi-stage pipelines en el pasado Build, lo cual es un avance pues permite incorporar al modo YAML las capacidades de despliegue que ya hemos conocido desde hace buen tiempo, pero mientras este camino continua ¿como logramos que el usuario final se sienta confortable trabajando con YAML? pues la verdad sea dicha, a muchos de nosotros el trabajar a puro texto no nos hace sentir cómodos; así que (como ya vimos anteriormente) a la capacidad de agregar snipets de texto, desde el editor de tareas, hacia nuestro editor de texto, ahora se ha incorporado una ayuda que apenas Tom la menciono me encanto inmediatamente, así que vamos a ello.

Repasemos, si nosotros usamos la capacidad de agregar porciones de texto luego de parametrizar una tarea, nos vemos en la siguiente situación ¿qué hacemos si luego resulta que queremos editar la tarea y sus parámetros?, si es solo cambiar un parámetro de texto (una ruta por ejemplo) no hay mucho problema, pero si queremos cambiar mas de un parámetro dentro de una lista de opciones la cosa cambia un poco, así que lo que hasta hace poco hacía era pegar una nueva tarea con los parámetros actualizados y según correspondía reemplazaba o toda la tarea o solo la sección afectada, y a seguir adelante.

Pues bien ahora en los últimos sprint del producto se ha liberado la capacidad de editar una tarea ya existente en nuestro pipeline, para lo cual debemos fijarnos en las letritas que dicen “settings” sobre una sección de tipo task en nuestro YAML:

En este caso he elegido una tarea que me vino con la extensión para soportar Terraform (¡Si! ahora tenemos una extensión oficial para incluir despliegue de recursos cloud usando Terraform), hago clic sobre las letritas de settings y….

Listo, ya podemos editar totalmente la tarea y actualizar los parametros que hagan falta.

Espero que esto les sea de utilidad para ir avanzando en la creación de mas pipelines YAML, a estar atentos en las novedades que vendran saliendo en cuanto a los multi-stage pipelines.

¿YAML Pipelines? Si, ¡facil!

Durante este tiempo, he estado explicando como construir Pipelines (antes Build definitions) en VST.. digo Azure DevOps, y para esto he mostrado como ir agregando diversas tareas a nuestro pipeline, para lo cual nos hemos apoyado en el diseñador gráfico que facilita la herramienta, algo que facilita la productividad y la curva de entrada para empezar a desplegar automáticamente, pero claro, pese a la facilidad había una objeción recurrente, el como poder versionar y/o editar en modo texto nuestros pipelines, claro, existe la posibilidad de exportar las definiciones como JSON, pero la verdad ese modo sufre de dos problemas: no esta integrado con el repositorio de código fuente y lo mas importante, no es leible fácilmente por humanos.

En base a este problema, desde el año Microsoft introdujo la opción de editar nuestros pipelines en formato YAML (usado también por Kubernetes y otras herramientas CI/CD) lo cual fue bien recibido por la comunidad de usuarios, pero este cambio involucraba el pasar a solo editar un archivo de texto en el repositorio, perdiendo los asistentes de las tareas y el tener que saber como escribir los diversos parámetros de las tareas a usar, bueno… eso esta cambiando desde ahora.

Primero, casi desde un primer momento se ofreció la opción de exportar nuestros Build Pipelines existentes como YAML y así tener un punto de partida para empezar el versionamiento, como se puede ver en las siguientes pantallas:

El gran paso viene dado ahora, pues al editor tradicional de puro texto, se le agrega un asistente que permite usar un formulario para configurar de manera visual los parametros de una tarea, que es lo que veremos a continuación.

En este caso lo que ya tenia es un YAML que compilaba una solución en .Net Core, siendo que me interesaba que una vez que la compilación se efectuara, tuviera disponible (para el posterior paso de release) una carpeta de la solución con el codigo ARM de la infraestructura que alojara la solución a desplegar, por lo que lo que tenemos que hacer es editar nuestro YAML y elegir la tarea respectiva:

Ya estamos en la tarea deseada “Publish and Build Artifacts”, asi que pasamos a editar los valores necesarios:

 

Damos clic en Add, y listo, ya tenemos la porción de código de la tarea en nuestro YAML!

Ahora toca seguir las novedades del Build donde seguramente veremos mas avances sobre como Azure Pipelines nos puede ayudar en nuestros ciclos de despliegue.