Etiqueta: DevOps

¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services? (y ii)

Posted on by ecardenas

El articulo anterior dejo las bases respecto a como ha ido la evolución de las tecnologías de contenedores, y el contexto en que se ubican los Azure Container Apps (ACA), pero creo que falta precisar un poco respecto a los casos de uso en que se puede aplicar esta tecnología o sus “hermanos” en Azure.

Empezare con algo que puede que ahora luzca menos glamoroso, pero que si que causo impacto en el momento de su lanzamiento: los Azure Container Instances, como mencionamos en su momento, esta tecnología surge para evitar el tener que lanzar los contenedores dentro de un cluster o de una MV, en ese sentido, que se puede hacer ahora con ellos:

  • Lanzar servicios de “servidor” basados en contenedores, que no requieran una orquestación ni escalamiento, como puede ser un servidor SFTP en la nube
  • Experimentación individual, en desarrollo, de un contenedor que luego se integrara como parte de una plataforma de microservicios.
  • ML, si, esto es algo que aprendí mientras preparaba mi certificación en Azure AI, resulta que algunos modelos sencillos de ML se pueden desplegar en Azure Container Instances, interesante la verdad.
  • Dar soporte a un escalamiento sencillo a los clusters AKS, creando virtual nodes en escenarios en que no es conveniente escalar el cluster hacia nodos “reales”, ojo este modelo tiene algunas limitaciones por lo que toca revisar si es la solución para nuestra necesidad en concreto.

Como se puede ver, los ACI aun dan mucho juego, pero de nuevo vamos a la pregunta respecto a los casos de uso que corresponden a AKS y ACA, y esto ya entra en los terrenos del mal llamado “juicio de experto” que son tan subjetivos, pero trataremos de delimitar la cancha: Finish Reading: ¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services? (y ii)

¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services?

Posted on by ecardenas

Aquí de vuelta, y me complace comentar que he sido renovado por séptima vez como Microsoft MVP para Developer Technologies y Microsoft Azure, reconocimiento que es a la vez un reto que motiva a seguir compartiendo conocimiento, así que vamos a ello.

Hace unas semanas tuve una conversación respecto a las diferencias entre ACA, ACI y AKS, lo cual me hizo pensar que si, puede haber cierta confusión ya que los servicios no nacieron en el mismo tiempo, así que para entender su contexto repasemos un poco de historia.

Muchos recordamos el boom de Docker y los Contenedores durante 2015 y 2016, y si, en ese momento significo toda una revolución respecto a como se desarrollaban y desplegaban las aplicaciones, no nos detendremos en eso, pues ya se ha escrito mucho al respecto, pero si anotaremos las consecuencias inmediatas de ese boom para entonces:

  • Impulso para el uso de Linux, ya que era el único Sistema Operativo que permitía ejecutar Docker
  • Se abrió el camino para el crecimiento de un patrón de arquitectura llamado “microservicios”
  • Lo cual derivo en la necesidad de ejecutar mas de un contenedor a la vez

Si pues, yo un usuario clásico de Windows de toda la vida tuve que desempolvar mis oxidados conocimientos de Linux (¡en una MV sobre Azure!)  a fin de poder practicar con Docker y así hacer mis primeras demos al respecto. Y claro, eso me dejo con la inquietud de “¿es conveniente desplegar una MV para tan solo un contenedor?”, claro eso me llevo a conocer y probar lo que era Docker Composer, y leer sobre algo llamado Docker Swarm.

Tiempos acelerados, y en ese momento los objetivos de Microsoft iban por dos frentes: integrar a Windows (Server) en el mundo de los contenedores y por otro lado ofrecer alternativas para simplificar el despliegue y la orquestación de los contenedores en la nube. Finish Reading: ¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services?

Y… ¿para que se usa DevOps? (o ¿como empezar en DevOps?)

Posted on by ecardenas

Estas conversaciones siempre terminan aflorando, pero casi siempre coinciden por la misma temporada, y en esta ocasión lo que me llevo a escribir esta nota fue la siguiente imagen que me paso mi enamorada:

La vi y dije «Upss ¿aun siguen con eso?», y es que si no es raro encontrar estas «guias» o recomendaciones para el que quiera iniciar su «carrera como DevOps», lo cual ya de por si esta mal porque recordemos que DevOps es una practica/filosofía/enfoque y no un rol, pero esta vez no ahondaremos en ello, sino nos centraremos en el entendimiento de DevOps y de lo que queremos lograr con su adopción.

Empecemos viendo el gráfico, y listemos las categorías:

  1. Lenguajes de Programación
  2. Administración de Servidores
  3. Redes y Seguridad
  4. Infraestructura como Código
  5. CI/CD
  6. Logs y Monitoreo
  7. Nube

Si, lo mas obvio es que (como de costumbre) la lista es de herramientas, y nada de practicas, pero es que aun tratándose de herramientas, faltan categorías relevantes, por ejemplo… donde ¿están Selenium, Cypress, PlayWright y otros? (Testing) ¿Se ha considerado la relevancia de herramientas como LaunchDarkly, Optimizely o App Configuration? (feature flags).

Con esto entendemos el problema en su verdadera magnitud, no solo es que al hablar de DevOps se piense solo en Automatización y Herramientas, sino que el dialogo DevOps ha sido monopolizado por un enfoque IT Pro, en el cual las practicas quedan acotadas a el funcionamiento de la infra (importantisimo, ojo, no se malentienda), donde es mas fácil conseguir hablar de estrategias de ruteo en redes que de experiencias en Feature Flags o el impacto del branching en tu estrategia. Finish Reading: Y… ¿para que se usa DevOps? (o ¿como empezar en DevOps?)

Hablando de Azure Load Testing (preview)

Posted on by ecardenas

Una de las cosas que no he comentado por aquí es que desde hace pocos meses he estado probando el nuevo servicio Azure Load Testing, el cual podríamos considerar como la evolución del proyecto (ya deprecado) Load Testing Pipeline with JMeter, ACI and Terraform, que también estuve probando a mediados del año pasado, ambas herramientas tienen como propósito la gestión automatizada de infraestructura para ejecutar pruebas de performance sobre nuestras aplicaciones, basándonos en un modelo estándar como es JMeter

La verdad lo que trae el nuevo servicio es alucinante: monitoreo en paralelo de los recursos de Azure involucrados, comparación de resultados entre tests previos, integración con Azure DevOps y GitHub Actions, etc, por lo que para conocer con detalle las novedades y lo que podemos hacer con Azure Load Testing hace poco tuve la oportunidad de participar en el Meetup mensual de la comunidad DevOps Perú, así que les comparto el video, mi participación esta desde el minuto 1:21.


Aprovecho para comentar las ideas fuerzas principales alrededor de este servicio:

  • A la fecha de escribir este post, el servicio aun esta en preview, pero eso no debería ser limitante para empezar a configurar nuestros planes de prueba y ejecutarlos, pues si bien no hay un SLA definido, considero (muy personalmente) que el riesgo es menor que con un servicio que si se publica de cara a nuestros usuarios.
  • Debemos recordar siempre de escribir nuestros scripts .jmx considerando que van a correr dentro de un entorno Linux, lo cual implicara una ligera adaptación si nuestras pruebas actuales están configuradas para ser ejecutadas desde PCs con Windows.
  • El limite de cada engine es de 250 hilos por segundo, por lo que si queremos golpear nuestra app a 1000 veces por segundo deberemos provisionar 4 engines simultáneos.
  • Otro detalle a considerar es que en esta preview el numero máximo de engines que se pueden provisionar en paralelo es 45.
  • Y la consideración mas critica, en este momento, es que el servicio no asigna un controlador para los engines inicializados, esto significa que si en la prueba subo un archivo .csv (para pruebas con data) de (digamos) 100 filas, y lanzo 2 engines, las filas se enviaran en su integridad a los dos engines, con lo cual tendremos 200 llamada a la aplicación a validar, si contáramos con un controlador, cada engine hubiera recibido 50 filas, pues el controlador estaría repartiendo la carga entre sus hijos. Esperemos que Microsoft mejore este detalle, pero por mientras debemos tener en cuenta la limitante que esto representa.

Bueno, espero que el video les haya sido interesante y que ya empiecen con sus pruebas! Ya saben dejen un comentario con sus opiniones que serán bien recibidas.

Actualizando sobre las Managed Identities

Posted on by ecardenas

Como mencionamos en nuestros posts anteriores, esto de las Managed Identities va en constante evolución por lo que este articulo se cala de maduro para actualizar unas cuantas cosas respecto a lo comentado anteriormente, así que vamos a ello:

Nueva forma de asignar permisos en el portal de Azure

En el articulo interior incluía varios pantallazos de como asignar un rol sobre un recurso (KeyVault/Azure Storage) a otro recurso (Function/Web App), pues bien, la forma ha cambiado ligeramente, pero esta vez para resumirlo he creado un pequeño video, aquí va:

Mejoras en el soporte para Service Bus

Como comentábamos anteriormente si uno quería usar Managed Identities en un Service Bus como trigger para un Azure Functions, tenia que usar la «sintaxis keyvault» desde los Application Settings, pero con la limitante de que esto solo funcionaba para Azure Functions Premium, pues bien ahora ya es posible usar MI como mecanismo de conexión/seguridad entre Azure Functions y Services, quedando la configuración así:

Dos detalles a considerar: Finish Reading: Actualizando sobre las Managed Identities

Desplegando Static Web Apps con Azure Pipelines

Posted on by ecardenas
Invitado especial: Bitbucket.

Hace unos meses comentábamos aquí acerca del lanzamiento de las Static Web Apps, las cuales ofrecen la facilidad de gestionar en un único servicio el backend mediante la tecnología de Azure Functions, así como el front end apoyándonos en los servicios de CDN que ofrece Azure, pero con una gestión muy sencilla, aunque seguro se habrán percatado que el despliegue se hacia con GitHub Actions y no con Azure Pipelines, por lo que, apenas este servicio se puso disponible, hubo buena demanda hacia Microsoft para conseguir el soporte hacia nuestro motor CI/CD favorito, y finalmente Microsoft lanzo el soporte y la guia para poder lograr el despliegue usando Azure Pipelines:

Tutorial: Publish Azure Static Web Apps with Azure DevOps

Y, la verdad es ocioso repetir paso a paso lo que se explica bien en la documentación, pero si que podemos profundizar algunas cosas que nos pueden ser de interes a la hora de intentar repetir este proceso, por lo que, a diferencia del tutorial, en lugar de usar un «Hola Mundo» decidí probar con una aplicación sencilla, como la que use para la demo que ven en el video que compartí hace un tiempo, así que .. no me enrollo mas:

  • El hecho de poder usar Azure Pipelines para desplegar las SWA, nos permite usar repositorios Git diferentes a GitHub, e inclusive a Azure Repos, de hecho la prueba la hice usando Bitbucket (!!), y funciono perfectamente! De igual manera, esto nos pemite valernos de la estructura de trabajo de Azure DevOps que ya conocemos bien Team Project-> Repos.
  • Lamentablemente de momento no podemos usar las características de creación de entornos temporales bajo demanda, como demostré en el vídeo, ojala lo incluyan en el mediano plazo.
  • El pipeline usado como ejemplo es muy «plano» (pero funciona) por lo que decidí acomodarlo un poco para que trabaje usando el flujo de stages y jobs propio de los YAML pipelines, el resultado lo comparto aquí, para que les sirva de base en sus trabajos, esto permite ver como logramos un flujo como el de esta imagen.
  • Hay que estar atento (como nos indica la documentación) a los parámetros  app_location, api_location, output_location, pero también a routes_location, y en este proceso puede haber cierto prueba y error (a la hora de probar alguno de los ejemplos disponibles) en mi caso me di cuenta que en el código fuente había una carpeta routes, así que tuve que pasar el parámetro respectivo, lo bueno es que el editor de Azure Pipelines nos brinda una gran ayuda para editar la task AzureStaticWebApp@0 en nuestro YAML.
  • El modo de conexión entre Azure Pipelines y las Static Web Apps es mediante un token, como se indica en la documentación, y no mediante un Service Connection (basado en RBAC/service principal), que es el mecanismo usual para poder enlazar nuestros pipelines, en este momento hay publicado un issue que pide desarrollar esta opción, asi que seria bueno darle un like para motivar a Microsoft a desarrollar esta solución.

Y bueno, como les comente, hice las pruebas usando Bitbucket en lugar de Azure Repos (que es lo que usa el ejemplo de Microsoft), ya que justamente una de las ventajas que nos ofrece Azure Pipelines es usar diversos repos Git de manera transparente, por lo que explicare como lo hice. Finish Reading: Desplegando Static Web Apps con Azure Pipelines

¿YAML Pipelines? Si, ¡facil!

Posted on by ecardenas

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.

 

 

En el Microsoft Ignite 2018!!

Posted on by ecardenas

Estas semanas han sido muy intensas para mi pues tuve la ocasión de participar en el Microsof Ignite, que se realizo en Orlando el pasado Septiembre, y si, era la primera vez que iba a un evento de estas dimensiones, pero la emoción era mayor pues participaba como speaker al haber sido aprobada mi ponencia DevOps is about people, beyond automation, reto grande, ya que si bien es un tema que me es familiar significaba mi primera vez como orador en ingles, por lo que me pase un buen tiempo ensayando todos los días para estar a la altura del evento.

Domingo 23, MVP Preday donde nos dieron los ultimos tips para la presentación.

Ya en el evento en si, arrancamos con el Keynote de Satya Nadella, y tuve la suerte de poder ver de cerca la presentación.
Y antes de mi charla aproveche para visitar el stand de libros donde hojee dos de los libros que tuve la suerte de revisar para Manning

Y llego el momento, lunes 24 en el Expo Theater 6, tocaba presentar el material, felizmente todo salio bien ante mas de 100 asistentes.

Aquí con la gran Jessica Deen, de la League!!

Ya en los siguientes días, trate de aprovechar el evento con calma, pero primero atendí a una entrevista con el equipo de Microsoft Latam!!.

Ultimo día, mis pasos se dirigían con cierta pena al OCCC, pero contento por todo lo aprendido.

Con la promesa de regresar!!
Gracias OCCC y hasta la próxima!!!

Comparto mi sesión, esperando sus comentarios sobre estas visión de DevOps.

Presentando Azure DevOps

Posted on by ecardenas

El día de hoy Microsoft anuncia Azure DevOps, que a primera vista podría ser un nuevo rebranding de VSTS, pero la realidad detrás de este cambio es mucho mas compleja, así que trataremos de explicarlo haciendo un poco de historia.

Team Foundation Server es presentado el 2005 como una solución integrada para las necesidades ALM de la época, en que se empezaba a buscar herramientas que apoyaran la gestión interactiva de proyectos, así como ir desarrollando los conceptos de Integración Continua y Gestión de Pruebas, rápidamente el producto fue adoptado por buena parte de las organizaciones que ya estaban trabajando con .Net como su plataforma de desarrollo de software, las versiones 2008 y 2010 fueron una mejora incremental que fueron simplificando el trabajo de los equipos, pero aun así el configurar un proyecto de Integración Continua requería pelearse con componentes de terceros y editar archivos XML.

El primer punto de quiebre se produce 2011 con el lanzamiento del preview de Team Foundation Service (que luego seria renombrado como Visual Studio Online) que al inicio era una implementación basada en Azure de los servicios que ofrecía TFS (y que me entusiasmo mucho apenas saque mi cuenta), pero que además de proveer al publico de una infraestructura ALM sin depender de la instalación de un servidor, permitió a Microsoft acelerar sus ciclos de entrega de novedades y pruebas de nuevas funcionalidades, siendo que la versión 2012 de TFS incluía como novedad esencial (al menos para mi) un nuevo modelo de creación de Builds Definitions, basado en XAML, que efectivamente hizo mas sencillo el proceso de despliegue… si usabas las plantillas proveidas en el producto! y es que la idea original era posibilitar la creación de plantillas personalizadas para diversos tipos de entorno (recuerdo que por ahí encontré una plantilla para facilitar el despliegue con ClickOnce, pero que nunca pude hacerla funcionar), para este año ya era mas que notorio el crecimiento de Git y GitHub como plataforma preferida de los desarrolladores, así que la versión 2013 de TFS incluía su propio repositorio Git (al igual que el entonces llamado Visual Studio Online), pero los cambios recién empezaban… Finish Reading: Presentando Azure DevOps

Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Posted on by ecardenas

Pues si, de vuelta… ya tocaba tener algo que compartir con ustedes, y en esta ocasión algo nuevo que sea de utilidad para quienes despliegan sus aplicaciones en servidores, pero… mejor contextualicemos.

Cuando originalmente empece a hacer mis pruebas de despliegue automatizado de aplicaciones en .Net tuve que hacerlo sobre servidores Windows, y para lograr eso se tenia que hacer varios pasos, instalar Web Deploy, asignar usuarios, activar servicios, pre configurar los WebSites o Aplicaciones Web, exportar un perfil, usar ese perfil dentro de la configuración de nuestro despliegue XAML, etc.. de hecho la cosa era tan tediosa que tuve que escribir una documentación de varias paginas para mi antiguo trabajo explicando como se hacia el proceso, y bueno… esa en parte fue la razon por la cual me he enfocado especialmente en lo que es despliegue sobre Web Apps, pero claro siempre me quedo el bichito de como ayudar a optimizar las cosas si la necesidad es trabajar con servidores ya sea IaaS u On Premise.

Así que desde hace unos meses he estado leyendo sobre una nueva funcionalidad que te ofrece VSTS llamada Deployment Groups (ya disponible de manera oficial) que esencialmente permite que tu aplicación se despliegue de manera sencilla hacia un servidor o conjunto de servidores, esto lo logra mediante la ejecución de un script (que ya veremos luego) en la(s) maquina(s) destino que esencialmente instala un agente que facilita la ejecución de los diversos pasos necesarios para la configuración el despliegue de nuestra aplicación, y cuando me refiero a configuración me refiero a que es posible realizar de manera desatendida la creación del Website o Aplicación Web en los servidores destino. Mas aun, esta funcionalidad permite agrupar nuestros servidores de manera lógica, de tal manera que no sea lo mismo desplegar a los servidores de QA que a los de Producción.

Todo bien, así que lo que trataremos ahora es de desplegar nuestra aplicación a un conjunto de Maquinas Virtuales creadas en Azure, las cuales estarán detrás de un balanceador de carga el cual nos proveera de una URL o IP unica, siendo que a la hora de efectuar la petición o request la respuesta podrá provenir de cualquiera de las maquinas virtuales que hayamos desplegado, lo cual facilita mucho la disponibilidad de nuestra aplicación, pero que a la vez proporciona retos respecto al manejo de sesiones y recursos compartidos. Finish Reading: Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)