¡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.

 

 

“Poquitecto” ¿realidad, broma o necesidad?

Desde hace un tiempo, en un grupo de amigos desarrolladores, bromeamos acerca de como uno de nosotros tiene el rol de “Poquitecto“, la razón de esta broma deriva del hecho de que nuestro amigo tiene el rol de Product Owner, siendo que esta adscrito a un departamento de Arquitectura en su organización, y claro en esta época de “cargo cult agil” nunca esta de mas hacer una broma respecto a que nuevo rol puede inventarse dentro de las organizaciones…

La verdad es que esto no hubiera pasado de una broma o anécdota, si no fuera porque la conversación me hizo recordar que ¡Yo trabaje con un poquitecto!, ¿como así?, bueno, resulta que hace poco mas de un año el equipo en que me encontraba paso por un cambio radical de Product Owner, pasando de alguien con mucho enfoque en la funcionalidad de negocio a agregar y la facilidad de uso respectiva (vamos, un PO “clásico” *), a uno con fuerte base técnica (pero involucrado en la organización y el producto por varios años) que priorizaba y enfocaba las Historias de Usuario con un claro enfoque hacia la arquitectura de la integración tecnológica de nuestra aplicación con otra que estaba siendo desarrollada por otro equipo.

Y claro, las reuniones incluían conversaciones respecto a lo que implicaba el conectarse con la otra aplicación, el como estaba construida nuestra aplicación, diálogos en los que nuestro nuevo PO se implicaba directamente; cabe agregar que nuestro Scrum Master era uno de los que te acompañaba en la depuración de código cuando había que meter un cambio radical a lo que ya se tenia desarrollado y en producción.

¿Que cual de los dos perfiles de PO es el mejor? pues, a riesgo de hablar como consultor daré la respuesta clásica: “depende”, pues en una etapa del ciclo de desarrollo se requería un enfoque totalmente orientado al negocio y a la funcionalidad a agregar, pero en otro estadío dicha visión tecnológica era de gran utilidad (y hasta de necesidad) para lograr orientar adecuadamente los cambios esperados.

Desconozco los detalles del rol de nuestro amigo, pero esta experiencia me indica que a veces puede ser necesario que haya una “fusión” entre las actividades correspondiente a un Product Owner y las de un Arquitecto, tenga esta mezcla el nombre que tenga (llámalo poquitecto si quieres), que en un momento ese nombre se consolide… depende de como siga el cargo cult en nuestras organizaciones(**).

(*) Ya lo he mencionado antes, personalmente creo que es imprescindible que un Scrum Master tenga un conocimiento del ámbito técnico en el que se va a mover con su equipo (sin llegar a ser experto), requerimiento que no considero mandatario para un Product Owner.

(**) Las cuales hablan de la importancia del Agile Technical Coach (si, otro cargo) y de la excelencia técnica, pero a la hora de la verdad no efectúan las acciones reales.

Agilidad al borde del nuevo año

El 2019 se cumplirán 10 años que estoy metido en estos temas de la agilidad, escena/movimiento que ha ido cambiando y readapatandose con una velocidad asombrosa, cayéndose, aprendiendo sobre la marcha, generando cuestionamientos, así que este fin de año es una buena ocasión para repasar algunas de las cosas que se han visto en este año en este entorno y comunidad.

Una de las cosas que afecto la escena agil mundial en los primeros meses del año fue el asesinato de Mike Beedle, firmante del Manifiesto, el cual poco antes había publicado esto

 

Reflexión totalmente valida (sumada a otra en la que proclamaba “arreglar” Scrum para seguir avanzando *) en un contexto en el que se hizo énfasis el ver la agilidad como algo solo organizacional y/o cultural, olvidándose de que el pilar técnico es importante el proceso de desarrollo de software, lo cual de la mano con el omnipresente “cargo cult” derivo que el rol mas demandado el año pasado y principio de este fuera el de Agile Coach y derivados, es que claro, si se quiere seguir escalando ser Scrum Master ya no es suficiente.

La consecuencia de ese boom fue que se empezó a dar una imagen de que para lograr hacer cambios hacia la agilidad lo importante era tener buenos coaches (externos, claro esta) y Scrum Masters, que no tenían porque entender (que no es lo mismo que ser expertos, ojo) las complejidades del desarrollo de software en un problema en concreto, sino en procurar la búsqueda de la felicidad de los equipos, y si al final del PI se tenia un bonito tablero frente al que sacarse fotos, mejor que mejor… y claro, este fenómeno se replico en las comunidades y eventos, generando una saturación del tema coach y relacionados, olvidándonos de como hacer bien software (en un momento en que todos p. ej. quieren hacer microservicios porque esta de moda, y no hay quien les pare la mano).

Este problema, porque hay que reconocer que es un problema, derivo en otros dos fenómenos relacionados, por un lado los mas hardcore empezaron a sentir que ya no tenían su lugar en la agilidad por lo que procuraron consolidar espacios para hablar en profundidad de los temas de software, y por otro lado el empezar a apuntar que algo esta mal, lo cual se hizo mas evidente con el ya famoso discurso de Martin Fowler en Australia, donde básicamente instaba a afrontar los siguientes retos:

  • Get rid of the Agile Industrial Complex and the idea of imposing stuff on teams. Let teams work out the way they should work themselves.
  • Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital, and
  • organize around products.

Ah si! porque me olvide de algo, es que durante este tiempo (junto a los coaches) no falto quienes se subieron al carro para venderles a las empresas (ansiosas de comprar, hay que decir) el como volverse ágiles, pero para variar, aplicando estrategias top down que generalmente dejan intactos los esquemas, pero claro, queda muy bien decir que se esta muy involucrado con la agilidad por ir contratando varios SM y coaches.

El discurso de Fowler tuvo su impacto (por ejemplo la respuesta de Uncle Bob) a nivel global y debate a nivel de la comunidad, en la que si por un lado se paso a revalorar (**) la importancia técnica en el desarrollo de software, por otro lado se ha dado una vuelta de tuerca con el mensaje de que “Agilidad no es Agile”, que Agile solo es a nivel de software, que agilidad va mas allá, “esto no lo logras  en la agilidad de equipos”; todo este nuevo buzz me parece que puede salirse de control, pues empuja la idea de que esto de lo que hemos tratado de hablar en estos años solo corresponde al “nivel estratégico”, lo cual termina dando un carácter secundario a objetivos como los de empoderar a los equipos y sus miembros o valorar el trabajo real sobre la imagen … , suma esto al hecho de afirmar que los coaches requieren “espacios seguros” para perfeccionarse, y tenemos una receta perfecta para segmentar a una comunidad que debería empujar un proceso de construcción colectiva.

Hay esperanzas, por un lado algunas organizaciones ya no están cayendo en la búsqueda de coaches (o SM) al peso, sino valorando sus meritos per se, aunque claro… el cargo cult terminara buscando nuevas figuras para asegurar la relevancia cuando un termino ya dejo de ser cool; por otro lado esta nuestra responsabilidad y consciencia de asegurar que los tópicos vinculados a la excelencia en nuestros ámbitos de dominio sigan presentes, y eso es tarea de todos en la que seguiremos.

(*) Lo cual hace inevitable recordar el como hay quienes saltan diciendo “eso no es Scrum” cuando ven que algunos equipos han evolucionado a practicas que les son mas eficientes en su contexto, pero que ya no siguen Scrum al pie de la letra.

(**) Por ejemplo en el HT #PorfaArgentina salto la importancia de asegurar espacio para el contenido técnico en el próximo Ágiles 2019.

 

Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

Por aquí ya hemos hablado una vez y otra sobre como gestionar los datos sensibles (como las cadenas de conexión) de nuestras aplicaciones, porque, claro, nadie debería de poner los datos de producción en el código fuente que grabamos en nuestro repo, ¿verdad?

Anteriormente las opciones pasaban por efectuar mezclas/transformaciones de tal manera que en tiempo de compilación se generara un archivo final con los datos sensibles correspondientes a cada entorno, lo cual si bien nos daba simplificación para colocar la clave correcta en el paquete y entorno correcto, nos obligaba a seguir versionando las cadenas de conexión en el código fuente (por no mencionar que había que compilar mas de una vez); la otra opción pasaba por gestionar dentro del entorno de destino (en nuestros ejemplos: WebApps) sobrescribiendo de esta manera los valores que vinieran desde el código fuente.

Dado que ni nuestro repositorio ni nuestra herramienta de integración/despliegue deberían contener datos sensibles, usaremos un servicio de nube que nos da la seguridad necesaria para gestionar nuestras credenciales, el Azure KeyVault, el cual nos permite almacenar de manera segura y granular ya sea certificados digitales como data sensible, pudiendo restringir quienes pueden acceder a que datos y a que no (aplicando Control de acceso basado en roles: RBAC). Un mecanismo usual de accesos a estos recursos sensibles es programar dentro de nuestra aplicación un código que lea los valores en tiempo de ejecución (procurando no releer el valor a cada uso, sino hacerlo una única vez), en este caso usaremos un enfoque distinto que consistirá en leer los valores almacenados en KeyVault durante nuestro pipeline de despliegue, alterando secciones del archivo appsettings.json (porque nuestro ejemplo se basara en .Net Core) que se alojara en nuestra Web App destino (aunque también funciona perfectamente en un despliegue sobre IIS).

Así que estos serán los pasos que seguiremos:

  • Crear un KeyVault
  • Crear un “Secret” dentro de nuestro KeyVault, ahí sera donde almacenaremos una cadena de conexión a la base de datos
  • Identificar el “Principal” mediante el cual nuestro Team Project se conecta a Azure
  • Dar los permisos sobre nuestro KeyVault a dicho principal
  • Identificar en nuestra aplicación las secciones a modificar en tiempo de ejecución
  • Enlazar nuestro TeamProject contra el KeyVault, fijando el scope respectivo
  • Configurar el reemplazo de valores en el appsettings.json
  • Validar que nuestros cambios han sido desplegados en el entorno destino

Para esta demo asumiremos que tendremos tanto un pipeline de Build como de Release, de una aplicación en ASP.Net Core, en nuestro ejemplo usare la aplicación de ejemplo del libro de EF Core in Action (excelente libro que tuve el honor de revisar) cuyo código fuente se puede descargar aquí, y claro, como es usual el despliegue lo haremos contra una Azure Web App.

Para el primer paso seguiremos las instrucciones dadas en la primera parte de este articulo, en mi caso he usado estos nombres: RG_DevmoVault01 para el Resource Group y ErnestoDemoKeyVault para el KeyVault, como en este caso la creación la hemos hecho vía linea de comandos verificaremos que podemos revisar este recurso en el Portal de Azure, así:

Finish Reading: Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps