Hablando de Azure Load Testing (preview)

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.

Conociendo los modelos de seguridad en la nube con Managed Identities (y II)

En el artículo anterior revisamos las bases del nuevo concepto de seguridad en la nube, recursos identificados a los que se les da autorización sobre otros recursos, y… eso ¿Cómo se implementa? Pues lo usual hasta hace pocos meses ha sido trabajar con los llamados “Service Principal”, los cuales la verdad (como lo pudimos comprobar en un post previo) son bastante engorrosos de utilizar, hay que crearlos explícitamente (aunque algunos se crean automáticamente tras bastidores) y mediante estas entidades es que se pueden manejar la asignación de permisos entre recursos.

Llegado este momento toca presentar a las Managed Identities, en las que básicamente como desarrolladores se nos permite asumir que los diversos recursos de Azure cuentan con identidades de pleno derecho, casi casi como si fueran usuarios humanos, para empezar veamos como nos lo propone Microsoft:

Finish Reading: Conociendo los modelos de seguridad en la nube con Managed Identities (y II)

La nube es híbrida… y no nos habíamos dado cuenta…

En los últimos años ha habido un fenómeno, sutil, pero no por ello menos real, la convergencia entre lo que conocemos como la nube pública y el “viejo mundo” del on premise. Es que la verdad sea dicha, a menos que seas una startup, es muy probable que tengas una buena cantidad de aplicaciones desarrolladas para el on premise, con sus servidores, centros de computo y todo eso, algunas muy bien hechas y bien optimizada, otras legados que están de mirar y no tocar, y claro el viejo que se resiste a morir, el mainframe.

El caso es que con la penetración progresiva de la nube, algunas cosas empezaron a ocurrir en las organizaciones cuando pasaron de la prueba de concepto:

  • Adoptar una política de Cloud First para las nuevas iniciativas
  • Darse cuenta de cuán conveniente es el “estilo cloud” de provisionar y desplegar aplicaciones
  • Descubrir las potencialidades del Serverless para desarrollar nuevos tipos de aplicaciones
  • Percatarse que por muy en la nube que esten tus apps, van a tener que consultarle información a aplicaciones que (aún) no se migraran a la nube
  • Tropezar con el hecho de que comprar servicios en la nube requiere un reaprendizaje
  • Considerar el “cloud native” (con o sin contenedores) como parte de tu estrategia

Entonces casi por inercia empezaron a darse soluciones a dos problemas: ¿como llevar las ventajas de las tecnologías cloud al on premise? y ¿como mejorar la integración entre ambos mundos? Finish Reading: La nube es híbrida… y no nos habíamos dado cuenta…

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

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

 

 

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

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)

Agilidad ¿responsabilidad de todos?

Si, por aquí de nuevo, luego de unas semanas muy ajetreadas, donde pudimos organizar el Global DevOps Bootcamp, renové mi participación en el programa Microsoft MVP (gracias por la confianza!) y se organizo el Ágiles Perú 2018 con motivo del décimo aniversario de nuestra comunidad.

El evento se realizo en la UTEC, y pese a todo lo acelerado que pasamos como comité organizador fue todo un éxito, mucho interés del publico por las charlas de los asistentes y varias propuestas interesantes en el Open Space.

 

En todo caso la jornada me dejo algunas anécdotas que están derivando en reflexiones, que comparto con uds. Finish Reading: Agilidad ¿responsabilidad de todos?

¿Una Imagen vale más?

En esta ocasión cedemos el espacio a una amistad de la comunidad que prefiere permanecer en el anonimato, pero tiene algo valioso y crudo que contar.

La famosa frase que dice “Una imagen vale más que 1000 palabras” ¿Realmente calza en todos los entornos? Porque lo que percibo en mi mundo laboral, mi entorno el desarrollo de Software, Aplicación de Negocios, y Mejora de Procesos, etc. Realmente esta frase solo engaña.  L

Mi comentario, es que ahora lo que se ve más por los pasillos son lindos posits  de colores e imágenes bonitas de equipos que aparentan la mejor calidez y que nada malo pasa por ahí.

Hasta que se tienen resultados. Finish Reading: ¿Una Imagen vale más?

¡Mudanza en MySQL

Tal vez algunos recuerden pero hace un tiempo migre este blog de Blogger a un servicio WordPress alojado en Azure, ha sido un buen tiempo desde la migración pero lo que no comente plenamente en su momento es que para poder funcionar WordPress requiere contar con una base de datos MySQL, siendo que al momento de la migración Azure no proveía un servicio manejado de MySQL por defecto se nos ofrecía una base de datos gratuita proveída por ClearDB, lo cual nos hace tener que administrar ese servicio en “otro lado”.

El caso es que entre las muchas novedades lanzadas por Microsoft en el Build del año pasado estaba el lanzamiento de una versión manejada (o sea que no tenemos que instalar un servidor Linux) de MySQL, por lo cual una de las cosas que pasaba por mi cabeza era migrar de ClearDB a Azure Database for MySQL, pero por una razón u otra siempre lo postergaba (aun cuando ya había creado una instancia en la misma zona geográfica y Resource Group que este blog!)

Y como suele suceder a veces es un hecho externo el que te hace pasar a la acción y en este caso fue la decisión de ClearDB de descontinuar los servicios gratuitos que estaba ofreciendo, dando como opción hacer un upgrade dentro de sus nuevos planes, pero como supondrán decidí hacer lo contrario y hacer pleno uso de mi BD en Azure, para lo cual seguí las instrucciones detalladas de este excelente post, con un salvedad que paso a contar:

El autor da las instrucciones para que una vez que, vía MySQL Workbench, nos hemos conectado a la BD destino y origen invoquemos un Wizard que efectúe la migración por nosotros y así lo intente, pero por alguna razón el efectuar pruebas consume el numero de conexiones que se pueden hacer hacia ClearDB, por lo que decidí jugar con otra opción: usar el backup que te ofrece ClearDB y tratar de restaurar en Azure, para lo cual entre a la consola web de ClearDB y exporte el ultimo backup disponible.

Una vez descargado el .zip exportado lo que tuve que hacer fue:

  1. Desempaquetar el archivo .sql que esta dentro del .zip (¡Si toda la base de datos esta en un archivo SQL!)
  2. En mi BD de Azure crear un schema con exactamente el mismo nombre existente en la instancia de ClearDB (para mas seguridad pueden copiar el comando de creación desde la BD origen)
  3. Seleccionar nuestra nueva bd/schema y ejecutar el SQL en cuestión.

Luego toca proseguir con las instrucciones del post respecto a la configuración de seguridad y conexión en nuestra Azure Web App de WordPress, pero adicionalmente es necesario editar el archivo wp-config.php de nuestro site, a fin de que todos los parámetros estén actualizados completamente, y claro luego de eso verificar que funcione adecuadamente, lo cual como pueden ver, va perfectamente.

Asi que … ¡gracias ClearDB, hola Azure Database for MySQL!