Etiqueta: Azure

Agregando HTTPS a tus Azure Web Apps… gratis!

Posted on by ecardenas

Siempre es bueno revisitar uno de los servicios mas queridos de Azure para mi: Azure Web Apps, con ellos (y SQL Database) empecé mi camino hacia la nube, fue blanco de mis primeros experimentos en lo que ahora se conoce como DevOps, y además… es el servicio donde tengo este blog, así que vamos a compartir experiencia que espero les sea de utilidad para configurar los sites que tenemos en este servicio.

Contextualizando, originalmente yo tenia este site en Blogger, el cual mude a WordPress con Azure Web Apps ya hace 8 años, cambiando su base de datos MySQL de clearDB hacia Azure hace 4, lo que no mencione es que originalmente este site solo uso el protocolo “http” por un buen tiempo, por lo que, como es sabido, terminaría siendo penalizado a nivel de SEO en los buscadores y generando desconfianza del lector, lo cual seria todo un problema de cara a los objetivos de divulgación de este sitio.

En ese sentido a poco de ingresar al programa MVP empecé a utilizar el beneficio de los certificados digitales de prueba que Digicert ofrece a la comunidad MVP, de esta manera ya tenia un certificado digital que podía vincular a mi site, indicando que la comunicación y el usuario viaja de manera segura, y… todo ha ido bien, pero este año decidí hacer una prueba cuyos resultados estoy probando y compartiendo ahora.

Top 10 Standard (DV) SSL Hosting Companies

El detalle es que el proceso de generación de un certificado SSL en DigiCert es tedioso y poco claro,al menos hasta hace dos años se apoyaba en herramientas de apariencia casi 90era y no generaban de manera directa los archivos PFX que son los que acepta Azure Web Apps para instalar un certificado, así que este año cuando mi ultimo certificado de DigiCert cumplió sus dos años de vigencia, decidí probar una funcionalidad que Microsoft anuncio el 2019: los certificados SSL gratuitos para Azure Web Apps, funcionalidad que brinda un gran beneficio para sites sencillos como este pues existen algunas limitaciones, como por ejemplo el no poder usar wildcards (*), pero de todas maneras es una gran ayuda para el que tiene su dominio y quiere brindar seguridad a sus sites.

Ok, el caso es que yo usaba previamente un certificado wildcard de DigiCert, y todo estaba configurado alrededor de este esquema, tanto en Azure como en mi registro de dominios (en este caso Network Solutions) por lo que contare mas o menos como lo fui solucionando, esperando que le sirva tanto al que va a migrar como el que va a aprovechar esta funcionalidad por primera vez. Ojo, estoy dando por sobreentendido que ya se tiene la titularidad de un dominio, ya sea en GoDaddy, RCP, NetSol, etc, así como acceso a su respectiva consola y obviamente una subscripción en Azure.

Finish Reading: Agregando HTTPS a tus Azure Web Apps… gratis!

Lo que se trajo el Microsoft Build 2022: ACA, gRPC, GraphQL y mas…

Posted on by ecardenas

Y si, llego otra edición del Build, el evento de Microsoft orientado a los desarrolladores donde anuncia sus novedades tecnológicas de la temporada, en esta ocasión ya se nota un regreso progresivo a lo presencial pues en Simultaneo se están realizando eventos en diversas ciudades del mundo, siendo la mas cercana a nosotros Buenos Aires.

Ah, y este servidor también estuvo presente con estos #TableTopic, que espero les sean de interés:

Como decía, aparte de la visión de liderazgo que nos dan lideres como Satya Nadella, Donovan Brown o Scott Scott Hanselman, el plato fuerte es conocer los nuevos servicios o funcionalidades que se encuentran disponibles a partir de hoy, y claro, cada uno tiene sus preferencias pero las mías son:

  • Disponibilidad (GA) de los Azure Container Apps, esta era la noticia que mas estaba esperando desde el pasado #MSIgnite, donde conocimos a este nuevo servicio que viene a representar una alternativa mas sencilla de administrar la orquestación de contenedores que la proveida por Kubernetes, que seamos francos, con toda su potencia no siempre es lo que hace falta cuando tienes aplicaciones pequeñas o medianas, sumale un soporte directo a KEDA y escalamiento mas sencillo y ya tenemos una herramienta destinada a tomar un lugar relevante en nuestras arquitecturas.
  • Mejoras en Azure Kubernetes Service (AKS), de todas maneras K8s seguira siendo la opción de referencia para varios despliegues, y en ese sentido AKS ahora incluye soporte a Draft 2 para el despliegue de aplicaciones contenerizadas a Kubernetes. De igual manera se estan incluyendo dos nuevos add-in uno para facilitar el ruteo de aplicaciones Web hacia internet, y otro para KEDA, sera motivo para probar ese ruteador.
  • Mejoras a Azure App Service, ok, se ha anunciado el preview de nuevas capacidades de migración entre SKUs  y un nuevo Landing Zone (documentación y automatización) para AppService 3, pero la verdad es que lo mas esperado era el soporte para gRPC, el cual finalmente esta en preview, lo cual nos permitirá usar el protocolo HTTP/2 para facilitar y mejorar la performance de la comunicación entre el frontend y el backend.
  • Novedades en Azure API Management, Azure API Management es un servicio que usualmente damos por sentado, pero cubre un rol muy importante en las organizaciones al exponer nuestras APIs, las cuales tradicionalmente han sido de tipo RESTful, pero en los últimos años ha ido creciendo el uso de APIs basadas en GraphQL, en escenarios que requieren flexibilidad en el conjunto de datos que se recuperan de las consultas, por lo que era cuestión de tiempo que Azure API Management le diera soporte, el cual hoy pasa del modo preview a la disponibilidad general (GA).
  • Novedades en Azure SQL Database, si esta vez se han anunciado varias cosas incluyendo su conexión con Synapse, pero en este caso lo que nos interesan son las novedades para desarrolladores siendo la mas importante el anuncio de actualizaciones en el soporte a Azure Functions, lo que permitirá (en adición a C#) que lenguajes como Python o JavaScript se conecten a SQL Database reduciendo la complejidad en el acceso a la base de datos; de igual manera ahora contamos con un entorno local de desarrollo contenerizado que nos da a los desarrolladores una experiencia de trabajo lo mas cercana posible a la versión en la nube, en un entorno que nos brinda Visual Studio Code y extensiones de Azure Data Studio que nos permite generar un workflow completo de diseño, desarrollo, test y despliegue de nuestra base de datos.

Si, hay muchas otras novedades como las que trae Cosmos DB en sus mejoras para el modo serverless, o el cambio de nombre de Azure Spring Cloud a Azure Spring Apps, el nuevo MySQL Flexible Server Business Critical, etc, pero con esto tenemos lo esencial para ir aprendiendo en los próximos meses viendo las diversas sesiones ¿Cual es tu novedad mas importante? Espero tus comentarios en español, que de eso se trata este blog ;).

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

Presentando las Azure Container Apps

Posted on by ecardenas

Una de las novedades por las que estaba mas expectante en este #MSIgnite de hoy era el anuncio de las Azure Container Apps, el nuevo servicio de Azure que hoy sale en Preview y que ya había tenido ocasión de probar en las ultimas semanas, pero … ¿por qué es tan importante este anuncio?

Para entenderlo hay que contextualizar como ha ido la evolución del mundo de los contenedores desde el boom iniciado por el querido Docker:

  • Los contenedores se ejecutaban de uno en uno dentro de una unica computadora (generalmente una MV)
  • Eventualmente se logra tener una pequeña orquestación de varios contenedores mediante Docker Composer
  • Rápidamente surge la necesidad de orquestar y escalar “en serio” y a través de varias máquinas (un cluster), por lo que surgen diversos orquestadores tales como Mesos, Swarm, pero el que gano (para bien o para mal) fue Kubernetes.

Entonces ¿problema resuelto? pues no, ya que si bien Kubernetes nos brinda un contexto en el cual podemos desplegar nuestros contenedores y hacer que estos vayan escalando según la demanda, nos plantea una situación de la que debemos ser conscientes: la capacidad base (numero y tamaño de nodos del cluster) siempre esta encendida y hay que pagar por ella, lo cual nos puede derivar a escenarios de recursos de computo no aprovechados.

De esta forma… ¿qué hacer cuando nuestros requerimientos son pequeños y solo queremos lanzar UN contenedor? Pues bien para esa circunstancia se facilito el desplegar contenedores en Azure Web Apps, y surgieron los Azure Container Instances (ACI), de los cuales ya hablamos en nuestra serie sobre serverless, tecnología muy interesante que permitió el surgimiento de KEDA, servicio el cual facilita a un cluster de Kubernetes escalar de manera elástica sin agregar nuevos nodos (mediante un esquema orientado a eventos similar a Azure Functions), solo contenedores “autónomos”, ayudando a un objetivo que se vuelve recurrente; “escalar a 0”, que no es otra cosa que si deja de haber demanda sobre un pod/contenedor su numero de instancias en ejecución pase a ser 0. Nada mal esto de KEDA ¿No?

Pues si, KEDA es de gran ayuda, pero pero pero… aun necesitas tener un Kubernetes, y toda su complejidad añadida, para lograr el efecto, así que ahí entran las Azure Container Apps, que es la propuesta de Microsoft para lograr la simplicidad en el despliegue escalable de contenedores para que de esta manera nos enfoquemos en el desarrollo de nuestras aplicaciones, y no en la infraestructura, infraestructura que por detrás esta soportada por el Control Plane de AKS, pero eso es transparente para nosotros.

Y..¿Qué tipo de contenedores podemos desplegar? pues esencialmente: Microservicios, APIs HTTP, Proceso de Eventos, y procesos backend de larga duración.

Esta es la definición pero… ¿como esto se lleva a la practica? Para entenderlo trataremos de conocer los elementos fundamentales de esta tecnología, así que les muestro un Grupo de Recursos, donde ya tengo desplegado unas ACA:

Finish Reading: Presentando las Azure Container Apps

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

Posted on by ecardenas

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)

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

Posted on by ecardenas

Seguridad, palabrita omnipresente en este mundo tecnológico pero que tantas confusiones trae a quienes de alguna manera tienen que lidiar con ella, ya sea estableciendo infraestructuras seguras, o desarrollando aplicaciones que no sean vulnerables a malos usos o ataques, y claro… con la nube hay cosas que toca revisitar, y … a eso vamos.

Este articulo no pretende ser una guía de como implementar la seguridad en Azure, pero si que espera contextualizar el entorno en que nos encontramos, como hemos llegado hasta el y una (entre otras) forma adecuada de gestionar la seguridad de nuestras aplicaciones en la nube.

En todo caso tenemos que partir de dos conceptos esenciales (otros son los relativos a la categorización de los recursos a proteger) en este rubro: Autenticación y Autorización.

Grosso modo, Autenticación es la capacidad de garantizar que quien quiere acceder a un recurso (sistema, dato, infraestructura) es quien dice ser, y esto se ha ido logrando mediante: contraseñas, biometría, tokens físicos, etc. Por otro lodo la Autorización se enfoca en la asignación correcta de los permisos respecto a que se puede hacer con el recurso en cuestión, dependiendo del rol o perfil de la persona ya Autenticada.

Hasta ahí todo claro, ahora reflexionemos como hemos trabajado con estos conceptos, supongamos que tenemos una BD llamada “Negocios” con dos tablas: “Productos” y “Ventas”, y supongamos que se necesita que Juan, pueda mantener el catálogo pero que solo pueda consultar las ventas realizadas, empecemos poco a poco.

Pues bien, para esto será necesario que Juan se autentique ante la BD, ya sea mediante usuario y password manejados por la BD, o que la BD “acepte” la autenticación que Juan ha hecho ante el Sistema Operativo, ya sea local o el de la organización, y por otro lado aplicar un GRANT al usuario “Juan” para que este solo puede hacer SELECT sobre la tabla “Ventas”, y además un GRANT para que este mismo usuario pueda hacer INSERT, SELECT, UPDATE y DELETE sobre “Productos”, pero no permisos para borrar la tabla o modificar su estructura, hasta aquí nada fuera de lo común, y con la misma lógica podríamos dar GRANT más generosos a Elena para que haga operaciones de mantenimiento sobre ambas tablas.

Esto de manera muy simplificada, en un entorno real y mas ordenado, lo usual es que se creen “roles” preestablecidos con las diversas combinaciones de permisos y de esta manera a Juan se le podría asignar un rol ya existente que tenga los permisos ya mencionados sobre “Ventas” y “Productos” (en este caso Rol1), siendo que luego a alguien nuevo se le asigne ese mismo Rol1, simplificando la administración en lugar de asignar los permisos de manera individual, como se ve aquí:

Permisos y roles sobre BD Finish Reading: Conociendo los modelos de seguridad en la nube con Managed Identities (I)

Pero… ¿qué es eso de Cloud Native?

Posted on by ecardenas

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

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

Tu estrategia cloud pasa por (re)aprender a comprar

Posted on by ecardenas

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

Presentando las Static Web Apps

Posted on by ecardenas

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.