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

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?

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?)

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)

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.

Nunca es tarde si la dicha es grande: edición sencilla de templates en Azure Pipelines

Bueno, con algo de retraso debo compartir una noticia que era muy reclamado por los usuarios de Azure Pipelines, la capacidad de contar con el editor visual de nuestros YAML pero… en la edición de templates, lo cual hace mas sencillo la inserción de pasos en nuestros YAML sin saber del todo los parámetros en las Tasks disponibles en la herramienta. Pues bien, en mayo se anuncio la capacidad, por un descuido mio no me di cuenta a tiempo, pero apenas lo vi, decidí que la mejor forma de compartirlo era mediante un video, que espero sea de utilidad:


Para que vean, Azure Pipelines sigue evolucionando.

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

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)

¿Psicosociales en el mundo de los contenedores? Kubernetes depreca a Docker

El día de ayer, buena parte del mundillo informático se sacudió con una noticia, que si bien ya se veía venir, por el lenguaje utilizado causo revuelo y preocupación, veamos:

Docker support in the kubelet is now deprecated and will be removed in a future release.

Esta nota formaba parte del log de cambios de Kubernetes, lo cual iba en la línea de un anuncio anterior donde se anunciaban este objetivo por parte de Kubernetes.

Obviamente las preguntas saltaron, ¿ya no podre seguir usando Docker si quiero trabajar con Kubernetes? ¿Qué pasara con el soporte para contenedores en Windows?, y la verdad la respuesta tardó algo en darse, y de eso hablaremos aquí, pero antes contextualicemos un poco.

Primero, veamos la parte técnica, a estas alturas en el mundo informático ya el concepto de contenedores esta mas o menos establecido, que la equivalencia con los contenedores usados en el transporte marítimo, que es una unidad de software con lo mínimo para ejecutar en un entorno destino y asi asegurar la portabilidad, las diferencias con las máquinas virtuales etc. Dicho esto, si que debemos repasar cual es el ciclo de trabajo que la mayoría de nosotros usamos al trabajar con contenedores, por simplicidad he quitado los componentes DevOps para enfocarnos en los contenedores, Docker y Kubernetes.

  • Tenemos un archivo llamado Dockerfile que define los componentes de software que queremos empaquetar y algunas acciones alrededor, este Dockerfile actúa como “receta” para que el comando “docker build” construya una imagen que la llamaremos X.
  • En este momento la imagen X esta en nuestro equipo, por lo que ya podríamos ejecutarla usando el comando “docker run”, o publicarla en un Registro tal como Docker Hub, Elastic Container Registry o Azure Container Registry, para lo cual usaremos “docker push”.
  • Con la imagen X subida en uno de estos Registros, ya esta lista para ser usada en diversos ambientes (generalmente en la nube), tales como Azure Container Instances, una máquina “convencional, Elastic Beanstalk y… Kubernetes, para lo cual este entorno destino deberá hacer un “pull” contra el Registro respectivo.

Entendiendo este gráfico podemos ver el porque de las dudas, si hemos subido nuestras imágenes apoyándonos en las funcionalidades de Docker… ¿quiere decir que en un futuro ese flujo va a cambiar?, bueno… para responder esta pregunta toca revisar un poco el como hemos llegado hasta aquí. Finish Reading: ¿Psicosociales en el mundo de los contenedores? Kubernetes depreca a Docker

Azure Upward: Advanced DevOps Hands On Workshop (materiales I)

El día de hoy estare participando en el Azure Upward: Advanced DevOps Hands On Workshop, organizado por Microsoft, donde hablare sobre Azure DevOps, Web App for Containers y algo sobre microservicios, y para esto he preparado una demo que basicamente consiste en contenerizar un proyecto web, desarrollado en .Net Core, publicarlo en el Azure Container Registry, y desplegarlo en dos slots de Azure Web App for Containers.

Para la demo me he basado en el código fuente de la segunda edición libro Entity Framework Core in Action de Jon P. Smith, asi que he hecho un fork para que ustedes puedan replicar la demo en sus casas, siendo así los archivos que he agregado al código original son los siguientes:

.dockerignore
azure-pipelines.yml
BookApp/Dockerfile

Como mostrare en la sesión la idea es crear un pipeline en Azure Pipelines, basandonos en un repositorio GitHub, por lo que tienen dos opciones hacer un fork del código original de Jon y agregarle una copia de los tres archivos mencionados, o hacer un fork de mi fork, queda al gusto de ustedes.

Como es logico, es necesario contar con un Azure Web for Containers, un Azure Container Registry, y enlazarlos adecuadamente a nuestro Azure DevOps, pero creo que eso me da para un video corto que voy a preparar, de momento les comento que para poder usar el pipeline es necesario definir unas variables, como se indica en este grafico, pues de lo contrario el pipeline no se ejecutara.

Bueno, espero que la sesión les sea de utilidad, cualquier consulta me la dejan en los comentarios por si hay algo que falta precisar. Feliz despliegue!

 

 

 

 

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!