Solución de Intranet sencilla para áreas de BI

Pocos artículos atrás mencionaba la posibilidad de realizar una intranet basada en Blazor y framework de Blazorise, para distribución de información generada por áreas de BI, sin gran esfuerzo ni los sobrecostos de las soluciones enlatadas. Para el caso de grandes corporaciones probablemente cuenten de antemano con una intranet preexistente, pero en pequeñas y medianas organizaciones donde esto no suceda volcarse a productos tipo SharePoint puede ser un tanto excesivo para solo distribuir reportes.

En el ejemplo que muestro en el video, la intranet es muy sencilla: consta de un menú de navegación lateral y el resto de la página es área útil para desplegar el reporte. Esto no quita que se puedan agregar funcionalidades adicionales, dado que estamos en terreno de aplicaciones web donde las opciones no tienen límite. El mismo video muestra como una página específica permite configurar al usuario su propio menú de navegación dentro del mismo sitio.

Esto último, la personalización de navegación, es el plus por el que un sitio de este estilo gana a las opciones enlatadas. El paradigma general siempre establece una administración central y opciones de personalización casi inexistentes para la navegación. Esto es contraproducente para un área que debe centralizar y distribuir los reportes a toda la organización, dado que las páginas pueden crecer rápidamente hasta superar el centenar y la elección de las que interesan a los usuarios en particular suelen ser un fracción menor. La experiencia de navegar o registrar accesos directos en forma individual para acotar las opciones suele ser una experiencia por demás frustrante para cualquiera.

Si bien es cierto que una certera asignación de permisos puede reducir considerablemente las opciones disponibles, no deja de ser un problema hacer menú de navegación universales que consideren todas las combinaciones, por no decir que el mantenimiento de un esquema de menú múltiple genera un sobre esfuerzo importante que se podría emplear en temas más productivos.

Si bien el video no muestra la reducción por autorización de acceso, la misma existe acotando las opciones que se muestran como disponibles. Luego se muestra el menú subyacente genérico, desde donde un usuario puede optar por seleccionar las páginas y reportes que más le interesan y configurarlas en un menú de navegación personalizado.

Adicionalmente se despliega la posibilidad de implementar la solución en una Aplicación Web de Azure (Web Apps), con disponibilidad de ranuras que definen los distintos ambientes, en el ejemplo test, pre-producción y producción. Indico además el modo en que los ambientes de trabajo están separados, para facilitar el desarrollo de páginas nuevas por parte de un equipo desarrollador sin gran despliegue técnico.

Puede observarse que adicionar un reporte no implica demasiado conocimiento, si los componentes que sostienen cada página son genéricos y admiten configuración desde el mismo sitio. Esto facilita enormemente que un área de BI no se transforme en un área de desarrollo de sistemas, sino que los sistemas vengan al auxilio de las funciones del área, lo que debe ser un principio irremplazable si queremos un gobierno de datos exitoso.

Finalmente observo que el framework Blazorise, al igual que otros varios que existen, vienen a simplificar la experiencia brindando muchos componentes que enriquecen dramáticamente las opciones nativas de Blazor, permitiendo crear aplicaciones web modernas sin necesidad de profundizar en rutinas de jquery y java-script que terminan siendo transparentes y casi inexistentes para el equipo.

Sencilla Intranet de menú personalizable por usuario basada en Blazor

Arquitectura de aplicaciones en la nube

A través de los años que mantuve este blog, las arquitecturas estándar de aplicaciones .NET fueron presentando nuevos escenarios a medida que la infraestructura en la nube de Azure ampliaba sus posibilidades. Algunas se mantuvieron a través del tiempo y otras cayeron al olvido, veamos un poco los casos sobrevivientes, de acuerdo a una tabla de sugerencias de Microsoft:

La tabla debe leerse en filas el tipo de aplicación a desarrollar, mientras las columnas muestran los distintos tipos de recursos disponibles en Azure. El cruce nos indica entonces las mejores elecciones sugeridas. Sin barrer exhaustivamente con todas, haré mis comentarios en base a mi experiencia directa con esta tecnología.

Las aplicaciones monolíticas, o de N-capas indica que pueden apoyarse en las Web Apps de App Services, esto es la opción más recomendable teniendo en cuenta que la capa de presentación podrá mantenerse muy fácilmente además de ofrecer posibilidades de monitoreo en línea nativas más que suficientes. Los sitios web pequeños a medianos tendrán solucionado íntegramente en este servicio lo necesario, salvo la base de datos que puede residir en el servicio SQL de Azure, extrañamente no reflejado en esta tabla.

La posibilidad de usar Máquinas Virtuales, pueden alojar del mismo modo una solución completa, y hasta apoyados por una base de datos local aunque esta es la opción menos recomendable. Es ideal para una primera migración de aplicaciones on-premise a la nube, pero de todos modos no es la mejor solución de arquitectura definitiva por muchos motivos, desde la frágil seguridad hasta el costo operativo de tener un servidor completo dedicado a la aplicación.

El uso mixto de una Web Apps como capa de presentación, y la máquina virtual como capa de negocio mejora algunos aspectos de ambos enfoques, pero lo recomendable es dejar ser lado la máquina virtual y directamente exponer las Funciones Azure como interfaz de API para alimentar el sitio o sitios web que se necesiten, aunque en la tabla tampoco exponen esta relación con dichas funciones.

Con relación a las aplicaciones móviles no hay mucha variación sobre lo mencionado, salvo que la capa de presentación de una arquitectura de N-capas puede estar constituida perfectamente con este tipo de servicio, lado a lado con una sitio web y capa de negocio común. Estimó que la diferenciación respecto a la anterior en esta tabla responde a aplicaciones menores muy especializadas.

Respecto a los micro servicios, es coherente relacionarlo a Kubernets, pero del mismo modo que se malentendió en sus momento la definición de web services con servicios, no es una identidad. De hecho una solución que se base en un conjunto de varios servicios de Azure constituye conceptualmente también una arquitectura de micro servicios. Sí es de gran ayuda en este tipo de soluciones la orquestación que ofrecen las Azure Functions, auxiliando en procesos asincrónicos y orquestando los mismos como asimismo aquellos que por tiempos de ejecución deban realizarse en varios pasos.

Por último menciona los flujos de trabajo y orquestaciones de procesos como solución independiente, como si se cumpliera funciones de un middleware, pero que perfectamente puede ser la solución complementaria de cualquiera de las arquitecturas anteriores. Introduce recién aquí el servicio de Logics Apps, porque en realidad no son fácilmente invocables como auxiliar de otros procesos, en su lugar cubren esencialmente el rol de lanzar trabajaos independientes en forma programática o por eventos determinados con desarrollo prácticamente sin código (como ventaja compensatoria tiene unos fantásticos conectores a servicios y clientes de correo en forma nativa).

Por supuesto que esto es un resumen, y puede haber muchas variantes sobre lo que expongo, como siempre invito a dejar en comentario experiencias que complementen este artículo y ayuden a más arquitectos para tomar en definitiva la decisión más acertada.

Georeferencias en Azure SQL y mapas en PowerBI (Azure Maps)

Al trabajar con datos geográficos, para quienes no están especializados en el tema puede llegar a ser un tema bastante oscuro, y en ciertas ocasiones puede llegar a ser frustrante no tener información conceptual clara de los conceptos básicos. Para mostrar este tema de una forma sencilla les acerco una capacitación que di recientemente, donde vemos algunas definiciones elementales de cartografía, manejo de tipos geográficos en Azure SQL, cálculos de distancias e inclusión en polígonos, además de algunos ejemplos de representación en mapas como en Azure Maps.

Administración de bases de conocimiento auxiliadas por IA

En un artículo previo mostraba el uso práctico de un bot conversacional para apoyo operativo en una intranet, ahora vamos a desmitificar un poco sobre la trastienda de estos bot (Azure Cognoscitive Services), llamada la base de conocimiento. En efecto, cualquier bot se nutre de bases de conocimiento como fuente de datos primaria, más allá de las interpretaciones de léxico auxiliadas por inteligencia artificial (IA). De hecho hay dos etapas de intervención de la IA, vamos a detallar este proceso.

El tópico que estoy describiendo específicamente de este producto son los de reconocimiento del lenguaje, obviamente en castellano aunque la mecánica aplica a cualquier otro idioma disponible en la plataforma. El bloque principal y núcleo de la funcionalidad es la base de conocimiento, donde la primera acción a realizar es alimentarlo con nuestros documentos mediante archivos, o preferentemente enlaces URL (esta segunda opción es mejor porque enlazará directamente los enlaces de imágenes al contenido ofrecido, dado que se pierden desde los archivos documentales tipo PDF o Word). Aquí es donde interviene la IA por primera vez, dado que interpretará la documentación clasificándola por ítems de conocimiento, y creará un esquema taxonómico de preguntas y respuestas en forma completamente automática. El hecho de usar IA nos asegura que los resultados no solo serán satisfactorios sino que además mejoraran continuamente dado que el servicio está centralizado y no es particular de nuestra solución. El “Language Studio” permite hacer esta acción, además de presentar luego la serie de preguntas y repuestas que generó el servicio:

Ejemplo de conjuntos de preguntas-respuestas para un bot conversacional

Además de los documentos personalizados, permite agregar un conjunto de ítems de conversación casual (propiamente chat) que le dará una personalidad al bot más allá de materia que tratan los documentos. Por supuesto qué hay variantes de personalidad que le otorgarán un carácter más casual o formal según el elegido, y que más allá de ser un aditamento de prueba es conveniente adoptar por razones más psicológicas. El que un bot pueda tener un sencillo diálogo casual ayudará a la adopción por parte de los usuarios, que más allá de obtener las frías respuestas generaran una empatía natural para promover el uso de este tipo de elemento auxiliar de la organización. Estos diálogos también son evitables y se podrán adaptar mejor a las necesidades de la organización de estimarse conveniente.

Es que la base de conocimiento recién creada es completamente editable, la imagen muestra al administrador de los conjuntos pregunta-respuesta, que más allá de tratarlo como par tiene la opción de sumarle el conjunto de preguntas equivalentes que mejoraran la precisión de la respuestas del bot, y hasta ofrece la posibilidad de desambiguar la pregunta con una elección múltiple de respuestas (un ejemplo de ello se ve en la imagen). Aquí entra en juego la segunda fase de la IA al no necesitar taxativamente cada tipo de pregunta textual posible, sino los esquemas genéricos que mejor la representen, dado que el sistema de scoring o puntuación con el que trabaja puntuará el tipo de respuesta como la más factible según la distancia relativa entre los sintagmas de preguntas ingresados y disponibles de cada respuesta. Ahí reside la gran potencia del producto, y lo que la diferencia enormemente de versiones previas, el análisis de lenguaje que permite realizar esta puntuación con mucha más cercanía al significado que a la forma.

Otro elemento que ayuda notablemente es la definición de sinónimos, referida a la asociación de varios términos que representan el mismo objeto de la vida real. Obviamente no estamos hablando de los sinónimos lingüísticos, que la IA los maneja notablemente bien, sino a aquellos que son particulares dentro de la organización y que nos interesa se interpreten de un mismo modo, más allá que por fuera del ámbito de trabajo no tengan ese sentido específico. Eso permite integrar términos de la jerga laboral y ayudar al servicio a orientarlo al elemento gramático existente que deseamos asociarlo. Por ejemplo, si dentro del ámbito laboral un datawarehouse se puede conocer por su abreviatura como DW o acompañado de su versión como DW3, se pueden establecer como sinónimos ayudando al bot a interpretar el objeto concreto al que se hacer referencia.

Todos estos puntos nos llevan a justificar un punto clave que mencioné en el artículo previo, y es la necesidad de tener roles de documentadores específicos. Como toda solución nueva en su tipo, siempre se genera una nueva necesidad que se puede cubrir a veces con recursos existentes, aunque otras veces y como en este caso implica general un nuevo tipo de rol. Concretamente un área de administración documental será necesaria tanto como se quiera potenciar el uso de las bases de conocimiento. El reunir la información documental, darle la forma necesaria para mejor interpretación de la IA, administrar la taxonomía y actualización del material, y por último configurar los sinónimos y preguntas equivalentes son tareas ciertamente no menores que necesitan de personal a mi criterio especializado, pudiendo ser bibliotecarios por dar un ejemplo. Esto se potencia aún más dado que la IA detecta las nuevas preguntas de los mismos usuarios y ofrece la posibilidad de incorporarlas por los administradores asociándola a la o las respuestas que mejor acomoden, cerrando un ciclo de vida de mejora continua con la gestión documental sobre la base de conocimiento. Como siempre, la Inteligencia de Negocios es una materia de continuo crecimiento y cada vez más multidisciplinaria.

Por supuesto que todo esto dependerá de qué tan lejos se desee llegar en este tipo de proyectos, y el balance de costo-beneficio, que en muchos casos resultará positivo porque todo esto redunda finalmente en fomentar el autoaprendizaje, evitando posiblemente muchas horas redundantes de capacitaciones extra al contar con material de consulta permanente y dirigido a dudas concretas.

Uso de Chat-Bots privados como guías en la Intranet

Desde hace unos meses cobró un impulso inusitado el uso de chat bots públicos, y sus intenciones ambiciosas de intentar ser un reemplazo de los motores de búsqueda y enciclopedias en línea. Sin embargo los bots conversacionales son un recurso que tienen varios años de trayectoria y que podemos experimentar en web públicas, como por ejemplo para sacar turnos en línea de atención médica. Pero además creando los propios especializados y bien empleados podemos encontrarle útiles usos internos en las organizaciones. La pregunta que vamos a responder en este artículo es: ¿qué tan inaccesible es lograr hoy esto?

Para comenzar les muestro un video muy corto, menos de 2 minutos, de una prueba piloto que llevé adelante. Estamos en una página de la Intranet corporativa donde generamos un inventario de tablas del data warehouse, para auxiliar en la búsqueda de información dentro de los modelos dimensionales. Un artículo anterior habla más en detalle de esto. A pesar de que la página es funcional a la localización de la información pertinente a las tablas de hechos y dimensiones, el hecho de que la acceden personal no familiarizado específicamente con este tipo de modelos hace que falte algo de información de contexto, y ahí es donde el bot es de gran ayuda:

Prueba piloto de chat-bots privados

Trabajando en la modalidad de que el Data warehouse sea internamente accesible a áreas que generan su propia reportabilidad, no siempre se cuenta con personal especializado en modelos de datos, y aunque se hagan las capacitaciones, los conceptos tienden a olvidarse con el paso del tiempo. Aunque siempre se puede volver sobre la documentación de la capacitación interna, la rutina diaria hace que muchas veces se necesiten repasos de los temas, y que sean fácilmente recuperados sin necesidad de hacer búsquedas exhaustivas o usando buscadores de texto que no siempre interpretan el punto solicitado. Aquí es donde un chat bot maneja el contexto desde donde se hace la consulta, y accede a una base de conocimiento especializada en los temas sobre los que trata la página actual. En efecto, los chat insertados pueden alimentarse de diferentes bases de conocimiento según la página en navegación actual. La rapidez de encontrar información de esta manera asegura de por sí un aumento de productividad, y lo que es mejor aún, despejando el camino para que los colaboradores internos logren hacer sus tareas sin frustrarse en el intento por falta de asistencia directa. Estos son puntos muy importantes a la hora de evaluar una inversión de tiempos y recursos en poblar estas bases de conocimiento.

Ahora viene la parte más interesante, con la Inteligencia Artificial (AI) de los Servicios Cognoscitivos, combinados con el Language Studio, ambos de Azure, permiten mantener las bases de conocimiento necesarias, ciclo de vida incluido; y publicarlas desde un Servicio de Bot que las presente. Todo ello basado en microservicios con poco esfuerzo de infraestructura, lo que permite poner mejor el foco en la administración del conocimiento. El proceso de alimentación es muy simple, se cargan los archivos y páginas web como fuentes de información, y la AI se encarga de interpretar y crear todo el conjunto de preguntas y respuestas, usando uno de los servicios dedicado especialmente a este fin. El proceso total no tiene mayores complicaciones y está muy bien documentado.

Si bien para la versión del video se usaron las versiones gratuitas de todos los servicios asociados, los costos reales de los servicios de pago no son elevados, y las versiones más económica son por demás generosas para un uso interno. El punto a evaluar entonces es lo que implica auxiliarse de estos recursos.

Lo primero a considerar es que debemos disponer de una base de conocimiento de la organización, es decir una serie de documentos que expliquen la naturaleza de los procesos sobre los que deseamos que el bot ayude. El grado de madurez de la organización juega un rol importantísimo en esta instancia, dado que no disponer de documentación interna puede echar por tierra el proyecto desde un comienzo. En el caso que se cuente o se decida confeccionar documentación interna, el punto siguiente es tener personal dedicado a ordenar, y clasificar la información útil. Probablemente deban transcribirse en algunos casos los documentos si es que la AI no llega a interpretarlos correctamente, o si quedaron mal rotuladas las preguntas base corregirlas en el entorno de pruebas del Language Studio, para lo cual evidentemente necesitamos cubrir esas posiciones con documentadores. Como el ciclo de vida realimenta la base de conocimiento con las nuevas preguntas generadas por lo colaboradores, el proyecto no termina con el lanzamiento sino que además se mantiene con cierta frecuencia para mejorar las actividades de relación entre preguntas y respuestas que la misma AI aporta. Puede que todo este tratamiento evolutivo no necesite una ocupación total, pero la misma crecerá en función de la cantidad de bases de conocimiento generadas y la cantidad de información que maneje cada una.

Como comenté al inicio del artículo, el tema de chat bots está muy de moda, y esto genera un incentivo más para que los usuarios hagan uso de los mismos. Basado en mi experiencia anterior con el buscador de metadata SQL, este tipo de iniciativa puede tener en forma análoga un alto impacto positivo, dar confianza a los colaboradores, y finalmente una mejora productiva importante. Además tengamos en cuenta que las nuevas generaciones están muy acostumbradas a tratar con redes sociales, y aprovechar este canal similar como vehículo de transmisión de conocimiento garantiza que las aprovecharan naturalmente, y más confiados que con solo disponer de una interminable biblioteca de documentos electrónicos acumulados.

Como estoy en una etapa experimental de esta funcionalidad, son bienvenidas las opiniones de quienes hayan implementado soluciones de intranet similares.

Suscripción a eventos por Azure Event Grid

Un tema recurrente al diseñar los ETL, pieza fundamental de todo data warehouse, es la programación de lectura de orígenes de datos. Al trabajarlos especialmente desde sistemas transaccionales la frecuencia de lanzamiento no siempre es claramente pautada, generando una incertidumbre que atenta contra la rutina de horas específicas preestablecidas. El camino más fácil, y del que se abusa innecesariamente, es la ejecución iterativa dentro de periodos muy cortos de tiempo, algo que anteriormente comenté que es la salida más nefasta, la que causa más dolores de cabeza y sobrecostos evitables. Evaluemos este tema y una alternativa saludable para tomar de modelo dentro de una arquitectura de micro servicios en la nube.

Antes que nada, voy a fundamentar las principales desventajas de los procesos iterativos, además del evidente del costo extra de tener procesos haciendo comprobaciones o directamente leyendo una y otra vez las mismas fuentes al no poder detectar la llegada de información nueva. Consideremos que el enfoque más moderno de un data warehouse se basa en modelos multidimensionales, cuyas relaciones entre dimensiones y hechos obligan a leer los datos con un cierto orden. Sin hay incertidumbre sobre cuándo aparecen las novedades en los diferentes orígenes la orquestación basada en procesos iterativos se hace directamente inviable. Si a esto agregamos que se da cierto margen entre iteraciones, con un enfoque económico de una o dos veces a la hora, la orquestación de ejecuciones multiplicará la latencia entre las mismas por la cantidad de orígenes diferentes, llegando a tener horas de retraso por suma de tiempos muertos, y probablemente ello atente contra la oportuna disponibilidad de la información final. Finalmente el control de secuencialidad entre los procesos se hace tan engorroso que debilita la solución tanto por errores de detección como por solapamientos indeseados inevitables en este tipo de soluciones.

Ahora veamos una mejor alternativa, quienes programan aplicaciones modernas están familiarizados con el concepto de “eventos” que en un primer momento podría considerarse opuesta a la secuencialidad mencionada, sin embargo no son excluyentes. La idea es lograr la secuencialidad orquestada por eventos, e independizando todo lo posible los acoplamientos para minimizarlos. Cuando trabajamos en la nube de Azure, la herramienta más apropiada para integrar información es el Data Factory, sucesor natural de los servicios de integración de SQL aunque admita un motor de compatibilidad para permitir usarlos en los casos cuya funcionalidad aún no está cubierta por este nuevo producto. Aunque una de las ventajas que le hace ganar puntos es la facilidad de suscribir ejecuciones gatilladas por eventos (trigger).

Una posibilidad que aprovecho con frecuencia es la de detectar cambios en los blob de Azure Storage, principalmente la carga de un archivo que de manera inmediata ejecuta el proceso de integración por la canalización (pipeline). Si logramos que el sistema proveedor de los datos, o persona si es carga manual, deje el archivo a integrar en el storage tenemos resuelto el primer gran paso. Al final de cada bloque de integración se puede verificar en una tabla de SQL, o table storage alternativamente, los pasos que debe seguir ejecutando a continuación si un conjunto de archivos termina de completarse. Con esto se puede tener una orquestación que controle perfectamente el paralelismo.

Un segundo escenario se presenta cuando no tenemos la amable posibilidad de que nos alcancen los archivos en storage y debamos buscarlos. Esto es muy común en el ámbito financiero donde los bancos trabajan antiguos sistemas de mainframe que no acompañan los sistemas más modernos, y a duras penas disponibilizan carpetas FTP. Como en el caso de la integración desde una casilla de correo de un artículo anterior, las aplicaciones lógicas de Azure nos pueden auxiliar con la detección. Un paso detecta la llegada de un archivo nuevo a la carpeta ftp controlada y lanza un evento a la grilla personalizada a la que está suscrita la canalización del DataFactory.

Detección de eventos a través del Azure Event Grid

El método que utiliza es exponer webhooks que enlazan los eventos entre ambos sistemas. La canalización recibe el mensaje a través del callback, donde se le indica los datos de identificación del archivo detectado y su ruta dentro del FTP, para que pueda integrarlo inequívocamente. El éxito de las operaciones se puede monitorear dentro del módulo de administración del Event Grid como se muestra en la imagen anterior, aunque como en muchos otros servicios que utilizo jamás extravió o tuvo excepciones el gatillazo de un evento. En la parte inferior se muestran los distintos webhook que aprovechan los sistemas, algunos desde aplicaciones C# en servidores on-premise, siendo el último el dedicado a la detección de llegadas de archivos por FTP. El mismo evento puede estar asociado a diferentes tipos de archivos, y cada uno de ellos lanzará la respectiva canalización de DataFactory que los integra. Un ejemplo de estas secuencias la vemos en la siguiente imagen, desde el monitor de procesos del DataFactory:

Monitor de ejecución de canalizaciones en DataFactory

Como se puede apreciar en la secuencia, para la gran mayoría el orden diario de las ejecuciones no siempre es el mismo, dado que las integraciones de archivos desde el FTP dependen de la llegada desordenada de archivos a integrar. Para que se lancen las canalizaciones independientes en forma certera, hay un paso previo que es la copia del archivo desde el FTP a una carpeta auxiliar en blob storage, para lograr un mejor rendimiento copiando el archivo íntegramente para posteriormente integrarlo con su canalización dedicada.

Resumiendo, con un esquema de este tipo podemos aprovechar los recursos de microservicios en Azure de la mejor manera posible y para lo que cada uno esta especializado: Logics Apps para detectar colocación de archivos en FTP, Event Grid para transmitir por evento la identificación del archivo, y DataFactory para copiar e integrar los archivos desde Blob Storage a SQL a otros destinos (por ejemplo Azure SQL y/o Table Storage).

Como de costumbre, como puede haber más de un tipo de solución combinando microservicios, pueden dejar sus comentarios describiendo otras arquitecturas que les hayan dado resultado para solucionar casos similares.

Posibilidad de instalar una instancia de Reporting Services (SSRS) en la nube

Para no generar falsas expectativas con el título, debo anticipar que el producto en sí de SQL Reporting Services no admite su instalación cloud, sin embargo hay dos métodos alternativos que pueden prolongar la vida del producto soportado en la nube por varios años más. De hecho, a pesar de todos los rumores y recomendaciones en off de pasar a PowerBI como reemplazo, se siguen versionando junto al motor de base de datos (actualmente la 2022) y no hay planes a la vista de discontinuidad total del producto.

La primera explicación es quedar toda duda de su incompatibilidad con las tecnologías de nube: Reporting Services tiene casi 20 años de antigüedad y se desarrolló en una época en que el XML era un estándar muy aceptado, de hecho se usan rutinas programadas como extensión del lenguaje llamada XMLA, hoy en día considerado de hecho como algo obsoleto para nuevos desarrollos y con cero compatibilidad con los servicios cloud. Además de esto, su sistema de servidor trabaja como servicio local del sistema operativo de windows, interactuando de esa manera entre su portal web y la base de datos dedicada; de esta manera no hay plataforma dentro del ecosistema de micro servicios Azure que permita una arquitectura de ese estilo.

Descartada esta posibilidad, el único remedio que queda es crear una máquina virtual como servidor donde instalarlo, y publicar su portal desde dicho entorno. La máxima flexibilidad que nos da esta situación en la nube es poder asociar un directorio de autenticación Azure AD, y explorar las limitaciones que pueda tener este conjunto. En mi caso, enfrenté el tema con la situación poco feliz de no contar con autenticación Active Directory para los usuarios, sino que el log a los sistemas se hacen con autenticación por servicios de Google. Por favor no me critiquen por eso, no fue una decisión propia la de usar este esquema híbrido y tampoco lo recomiendo especialmente.

Ahora bien, con estos limitantes tenemos por un lado una máquina virtual servidor con autenticación básica por SQL a nivel de datos y cuenta de servicio de sistema operativo local para Reportes, mientras por el otro hay todo un ejercito de usuarios tratando a de acceder con sus cuentas Google. Pero a no desesperar que todavía existe una posibilidad y es la que vengo usando con éxito desde hace dos años: desarrollar un sitio web (intranet) como interfaz (o proxy si le cabe esta definición).

En efecto, se trata de un sitio de servicio o Aplicación Web de Azure, desarrollado para autenticar por Google, con autorización por roles y una series de páginas que muestran embebidos los reportes del SSRS. La tecnología de la intranet es ASPX con .NET 4.8/C#, dado que nos provee de un control nativo de SSRS para poder mostrar estos reportes (tanto en forma de frame como de página completa) ocultando la dirección original del servidor de reportes mejorando la seguridad. El servidor de reportes queda así protegido y pueden cerrarse todos los puertos que no provengan de la red virtual de Azure, siendo accedido solo desde a través de su ip interna en red virtual. En el caso que no pueda conectarse a través de la red interna, igualmente el firewall puede cerrar todos los puertos a orígenes que no sean del servicio de intranet. Esta aplicación web puede probarse sin inconvenientes en su versión de desarrollo que es gratuita, y si no es muy exigente el uso del sitio puede mantenerse definitivamente en ese nivel de servicio lo que abarata el costo del workaround.

Esta arquitectura tiene una serie de configuraciones qué hay que cuidar con sumo detalle para que funcione armoniosamente, pero nada que investigando un poco en la web no se pueda resolver. Tengamos en cuenta que tratamos de forzar un producto a entornos y plataformas en la nube nuevas que ni siquiera se soñaban en su época de desarrollo. Una alternativa a los sitios ASPX que también se están dejando de lado (se incentiva el uso de core 6/7 para servicios de Aplicaciones Web que tienen un mejor manejo de los nuevos modelos de programación basados en Inyección de Dependencias integrados a entornos cloud), es crear sitios web basados en Blazor. Estimo por lo que investigué que la versión que mejor acomoda es la de servidor (Blazor Server), sin embargo no hay controles nativos que permitan integrar Reporting Services en forma más o menos transparente, y usar los iframe francamente son un agujero de seguridad importante. Existen productos de terceros de pago que equivalen al componente de SSRS, pero mientras podamos usar ASPX no debería interesarnos, y hasta quizás haya otras y mejores alternativas para cuando debamos migrar obligatoriamente este esquema de solución a futuro. Ir migrando todo lo permisible a PowerBI es siempre una buena idea, para minimizar el esfuerzo de adaptar aquellos reportes que hoy nos impliquen sacrificar funcionalidades de cara al usuario por no tener equivalentes en PowerBI.

Para tener una idea de como opera el conjunto, podemos echar un vistazo al monitoreo de Application Insights:

Solución de Reporting Services combinado con un portal de autenticación Google.

En la figura, la instancia central representa al sitio web de la Intranet, una Web Application en su modo básico de configuración, que se conecta a un servicio de SQL Azure (en rojo) y usa internamente el servicio de sistema de claves (Key Vault) y Azure Active Directory (ambos en azul) para su funcionamiento. La autenticación por Google, al ser un servicio externo, no queda monitoreada por este esquema. Finalmente en amarillo se muestran dos conexiones al mismo servidor donde se encuentra instalado Reporting Services, una para el portal (protocolo http) y la otra a su servicio web gracias al cual el componente embebido recupera la información a desplegar de los reportes. Este último servicio web accede además al servidor de SQL señalado en rojo, pero que no puede monitorear el servicio de Insights por obvias razones.

Como pueden apreciar la solución se comporta perfectamente y la menor incidencia de errores que apenas se ve como el mínimo punto rojo en la instancia del sitio web, es debida a timeout por tiempos muertos en explorador de las páginas o al exportar grandes archivos a excel o PDF generalmente, lo cual es permisible y no generan reportes de incidencias específicamente por parte de los usuarios. Espero que el ejemplo les ayude a resolver situaciones similares, y con tan buenos resultados como los que obtuve apoyado en este esquema.

Una solución sencilla de integración poco ortodoxa por Aplicaciones Lógicas (Azure)

Un tema que será recurrente cuando describa arquitecturas distribuidas en la nube es el uso de micro servicios acoplados para otorgar esquemas simples y mantenibles de soluciones. El caso que abordamos hoy es el de una integración desde una entidad externa, un proveedor cuyo único medio que nos otorga para enviar datos transaccionales es el correo electrónico. Desde mi experiencia es la primera vez que me presentan un escenario de este estilo, y seguramente muchos profesionales que lean esto jamás se encuentren en su vida con una situación semejante. Pero lo interesante de todo esto es que los servicios en la nube nos dan todo lo necesario para resolverla.

El problema de interpretar el texto del cuerpo del correo no es relevante para estudiar el caso, en definitiva se trata de hacer una extracción de conocimiento de un texto. Para mi ejemplo el que tenga un formato generado automáticamente simplifica mucho hacer el análisis y extracción de información relevante, pero aunque sea texto libre que deba interpretarse por rutinas de IA no habrá ninguna diferencia, dado que lo podemos trabajar desde una rutina en una función Azure en Core 7, con toda la libertad que nos da el C# para realizar la tarea. El centro del problema es el detectar la oportuna llegada del correo, para iniciar la secuencia programada.

Particularmente soy adverso a crear rutinas de ejecución recurrente cada cierto tiempo, por lo engorroso de monitorear este tipo de procesos y especialmente porque genera muchas veces un sobrecosto innecesario desde el punto de vista de mejor aprovechamiento de recursos. Como expliqué en artículos anteriores toda ejecución en la nube implica un costo que se debe minimizar o aplicar a procesos útiles, y las rutinas iterativas con aprovechamiento mínimo entre serie de ejecuciones atenta contra una solución razonable en este tipo de entornos y solo debe recurrirse a ellas en casos que no haya más alternativa.

En este sentido las Aplicaciones Lógicas de Azure nos dan la posibilidad de suscribirse a eventos de llegada de correos electrónicos, no importa si el proveedor es Office365, Exchange o Google. En estricto rigor, el chequeo de recepción de correos se hace internamente a una frecuencia programable, en mi caso de 3 minutos, pero lo interesante de esto es que esa revisión periódica se hace en forma trasparente sin llegar a disparar el proceso de ejecución. La aplicación las lista en forma independiente como ejecuciones “omitidas”, dejando el monitoreo basado solamente en ejecuciones de procesamiento reales simplificando en gran forma el seguimiento y revisión posterior. El esquema comienza con este sencillo paso, y el diagrama de solución queda como muestra la imagen siguiente:

Detalle del diseño de una rutina de App Logic (Azure)

El módulo detecta y lee los datos del correo, incluyendo sus propiedades, pemitiendo como en el ejemplo guardarlos en una tabla de SQL auxiliados por un procedimiento almacenado, que dejará la auditoría del procesamiento y estados del cada registro accesibles para su control eventual. A continuación y orquestados por la misma aplicación lógica se inicia la ejecución de una Función Azure (otro micro servicio independiente) que hará el trabajo pesado en Core 7/C# basado en los registros de la tabla en SQL Azure. Para finalizar, en caso de éxito, se elimina el correo electrónico recibido. Esta solución básica dio un excelente resultado, y a pesar de contar con rutinas que la puede complementar con el manejo de excepciones en cada uno de los pasos, durante el año y medio que viene ejecutando jamás tuvo una situación de error, y este proceso no es tan crítico como para necesitarlas.

Como toda solución, hay muchas alternativas para abordarlas, reemplazar las tablas SQL por una cola o tablas en Storage por ejemplo, pero dentro del marco de soluciones entrelazadas existentes que aprovechan estos datos para diferentes contextos y contando con una base operativa de SQL funcionando como ODS (Operational Data Store) es la opción más sencilla que cumple funcionalmente la necesidad, y además la más económica (una batería de 10 Logic Apps de régimen similar 24×7 están generando actualmente un costo mensual inferior a los 15 U$S).

Para finalizar dejo un listado de ejecuciones tal y como lo muestra el servicio, que registra los pasos de ejecución y estados, como se ven en la figura superior. Espero que estos tips ayuden a orientar sobre el uso en el mundo real de micro servicios, y por supuesto cualquier experiencia similar que quieran compartir en los comentarios será bienvenida para dar más opciones.

Historial de ejecuciones y resultado de las mismas

Soluciones basadas en arquitectura de aplicaciones como servicio

Tradicionalmente implementar un sistema mediano de intranet era toda una inversión. Para abordar el tema seriamente se necesitaba un data center o servidor dedicado en instalaciones propias, mantenidas por personal de infraestructura, redundancia, plataformas adicionales de desarrollo, todo lo cual dispara sin remedio los costos en forma desproporcionada y solo justificada para informatizar los procesos. El desafío de fondo frente a este escenario es mejorar el rendimiento de este conjunto, y desde hace unos años surgió de la mano de las aplicaciones cloud una variedad de aplicaciones que no apuntan a abaratar los costos sino a cambiar el esquema de soluciones para no depender de la parafernalia tecnológica que soportaba aplicaciones muchas veces sencillas en comparación a los recursos utilizados.

Este cambio radica esencialmente a montar soluciones sin servidor, un concepto que se expresa en forma sencilla pero que implica todo un cambio en la forma de pensar y administrar sistemas de información. Las soluciones en la nube ofrecen hoy en día un abanico más que amplio para reemplazar las soluciones on premise, y a la vez mejorando los niveles de servicio a estándares impensados. Una arquitectura básica como por ejemplo un sitio de intranet montado en una base de datos sobre servidor y un servidor adicional para su interfaz web en la DMZ, firewall incluido hoy en día puede implementarse en un servicio de base de datos SQL, con un App Service de web en core 7 o .NET 4.8, conectados por una red virtual con firewall incluido, además de servicios adicionales opcionales de seguridad, redundancia geográfica de respaldos automatizados, sin dejar de mencionar su continuidad de servicio prácticamente ininterrumpida. Si a todo esto agregamos que el costo total es una fracción muy inferior a su equivalente on premise, aun sin llegar a los SLA en la nube, no deja lugar a dudas que esta es la realidad a la que deben sumarse todas las organizaciones hoy en día.

Monitoreo de un conjunto de aplicaciones en Azure

En la imagen superior muestro un ejemplo de aplicaciones que comparten una serie de servicios en común, constituyendo soluciones distribuidas, y la forma de monitorearlas en directo. En este ejemplo tenemos un sitio web de intranet, tres bases de datos SQL, almacenamiento auxiliar en tablas de Storage, uso de colas, manejo de eventos por EventGrid para orquestar procesos en diversos servicios, y hasta un cliente de API tomando datos de un servicio de proveedor externo (montado asimismo en Azure y por eso monitorea las invocaciones) . El sistema de monitoreo permite además revisar los errores de llamadas, aunque no todas fueran excepciones fatales, permitiendo optimizar aún más el conjunto viendo el detalle de los mismos. El esquema muestra además un servidor virtual, que ejecuta una instancia de Reporting Services (que trabaja en conjunto a una App Service como capa de presentación en ASPX con autenticación cloud), por si se lo preguntan, la tecnología de SSRS no admite su implementación en la nube sin servidor, de ahí que necesite su propia máquina virtual, pero todo coexiste de manera muy armoniosa mostrando la ductilidad de este tipo de esquemas.

Como conclusión y recomendación a arquitectos de sistemas, no estoy hablando del futuro sino que el presente es trabajar con servicios cloud para soluciones completas; y frente a la posibilidad de elegir, el quedarse hoy en día con plataformas on premise es un decisión que lamentarán más temprano que tarde.

Desarrollos en la nube y control de presupuesto

La adopción de servicios de infraestructura en la nube trajo como consecuencia que se ofrecieran de igual manera las aplicaciones como servicios. Hoy en día esto es común y las organizaciones que pasan a ritmo lento pero constante desde sus entornos propietarios a consumir de estos servicios deben adaptar sus métodos para adecuarse al nuevo escenario.

El principal cambio que se debe administrar es la transición de libre aprovechamiento de recursos, limitados por las capacidades máximas de la plataforma adquirida, a entornos en la nube con capacidades superiores prácticamente ilimitadas pero con costo por consumo. Si bien esto último no es enteramente cierto, gráfica bien la situación para mostrar el contraste. Este cambio de escenario se hace especialmente notable con los procesos masivos de los entornos de BI (Inteligencia de Negocios), donde realizar ejecuciones de horas de duración pasa de ser algo medianamente permisible en plataformas locales a un derroche de consumo en entornos cloud. La optimización para generar ahorro, o al menos un mejor aprovechamiento de los recursos utilizados, pasa de ser un deseable en segundo plano frente a la rapidez de desarrollos a un item de relevancia que puede condicionar el diseño completo de una solución.

El desafío por lo tanto es coordinar perfectamente las áreas de desarrollo de sistemas con la administración de costos de los recursos usados, algo para lo que las estructuras clásicas de las organizaciones no contemplan. Históricamente los equipos de desarrollo de sistemas trabajan en entornos asilados, preparados con plataforma mínima y finalizando las actividades con la puestas en producción. La estructura de trabajo en la nube, con soluciones distribuidas por servicios no solo hacen poco práctico este esquema, sino que puede acabar en un derroche aún mayor de recursos si se soluciona en todos los casos con un grupo aislado de recursos o hasta una doble suscripción a servicios cloud, situaciones que podrían funcionar con aplicaciones transaccionales pequeñas dejan de ser prácticas para soluciones de BI donde se trabaja en forma permanente con grandes volúmenes de datos que no pueden replicarse en entornos de desarrollo aislados.

Bajo estos considerandos, la opción restante es llevar adelante los desarrollos en la misma suscripción, orquestando los servicios de manera que se puedan intercambiar en caliente (swap) y siempre teniendo en vista los costos asociados a los recursos explotados¹. Por ejemplo en Azure esto se puede monitorear con el resumen de costos, en la figura siguiente se ve un esquema de costos de un ámbito pequeño dedicado principalmente a BI, y aplicaciones asociadas:

Análisis de costos y proyección mensual del consumo

El correcto uso del etiquetado permite discriminar los gastos incurrimos por área u otros ítem de interés, por ejemplo la zona azul del gráfico corresponde al conjunto de servicios asociados al sector de BI. Sumando a este despliegue la posibilidad de establecer la cota máxima de presupuesto se convierte en una herramienta que da control total de la evolución diaria de los consumos. Esta capacidad es la que permite además monitorear los consumos de los desarrollos en curso, validando que el rendimiento de los nuevos servicios sean positivos respecto de los beneficios que se esperan de ellos. Este último principio marca el camino que deben tomar los equipos de desarrollo de sistemas distribuidos en la nube, dado que lograr la optimización para un mejor aprovechamiento de la suscripción indica que el área de desarrollo de sistemas en su conjunto no debe estar disociado de los costos incurridos por sus nuevas soluciones.

Un buen control de los nuevos desarrollos pasa asimismo por el correcto etiquetado para monitorear sus costos particulares, y su paso a producción estará marcado asimismo por un re-etiquetado oportuno. Sumada la correcta administración de los servicios se complementa el análisis por la discriminación por tipos de servicios, en un gráfico como el anterior, o como el que permite su análisis comparativo como el siguiente:

Distribución comparativa del consumo según los servicios

El nuevo paradigma prácticamente obliga a los nuevos profesionales de sistemas a estudiar permanentemente en sus soluciones el rendimiento de las mismas, algo que en adelante será crítico para evaluar si una solución además de cumplir las expectativas es lo suficientemente eficiente para considerarla viable.

¹en un próximo artículo desarrollaré más a fondo el modelo de soluciones por servicios distribuidos en la nube