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.
Mientras que la infraestructura informática para soportar prestaciones de BI en sistemas on-premise se manejaban en departamentos informáticos especializados de manera más o menos independiente de las areas que explotaban la información, la realidad de la nube cambió de fondo el enfoque sobre el tema. En línea con artículos anteriores, el modo de entender la informática en la nube presenta una nueva forma de dividir las tareas, queriendo decir con esto que muchas funciones que se podían independizar, en la modalidad nube se solapan o hasta en muchos casos se pierden.
La esencia de estos cambios se encuentra en la desaparición de la infraestructura física desde el punto de vista de las organizaciones. Todas las cuestiones referentes a data centers, servidores físicos, instalaciones, seguridad material, alimentación ininterrumpida, y niveles de servicios básicos, etc., pasaron todas ellas a ser parte de los acuerdos de servicios con los proveedores. De esta manera solo resta administrar la plataforma desde la organización en su modo virtual, y su consecuencia directa es necesitar menos especialización de los recursos humanos implicados y simplificación de los procedimientos al punto de consistir en revisión de tableros de control, también virtuales.
La contraparte de ello consiste en que los diversos servicios necesitan configurarse con conocimiento de los desarrollos que se realizarían para satisfacer las necesidades de arquitectura de sistemas de inteligencia de negocios, algo que no se puede separar e implementar dado que se reducen a solo configuraciones entre estos servicios. Al no haber situaciones físicas implicadas, la tarea no solo es posible de realizar por los especialistas de BI, sino que se torna estrictamente necesario. Hacer equipos de creación de servicios y su conexión deja de tener sentido realizarlo con equipos mixtos, cuando todas las definiciones e implementaciones van a estar directamente definidas por esta áreas de negocio. Complementariamente se hace necesario a la par de crear estos servicios el monitorearlos y evaluar sus costos, lo que puede llevar a correcciones y hasta reformulaciones de la arquitectura de modo de cumplir con los presupuestos asignados, todas tareas administrativas complementarias que van de la mano y en la que necesariamente debe participar el equipo de BI, prácticamente con responsabilidad total.
Esta situación lleva a que un departamento de Inteligencia de Negocios deba estructurarse desde áreas de arquitectura, hasta de explotación y gestión de la demanda, pero todas coordinadas. Las áreas de servicios se reducen solamente a controlar la continuidad de las prestaciones, pero difícilmente puedan tomar alguna decisión más allá de eso que no involucre al departamento de BI. De igual forma los responsables del área de BI deben tomar la posta y comenzar a tomar esa responsabilidad que se incorporó hacia sus incumbencias básicas, algo que debe tomarse como una consecuencia positiva de la utilización de los servicios en la nube .
Llevamos un cuarto de siglo de la gran transformación del acceso de la información, inicialmente segmentada y limitada, a la llegada de la big data en forma generalizada. Suena impresionante lo del cuarto de siglo, sobre todo para quienes son de mi generación y acompañaron día a día estos cambios ahora parece demasiado tiempo, pero más impresionante es la transformación que obró dentro de las misma organizaciones a nivel operativo. Sobre este último punto, y qué tipo de decisiones toman los niveles directivos en consecuencia es de lo que trata el artículo.
Hoy cuesta imaginar una organización desconectada de la web, manejando información en ordenadores personales e intercambiándolas en soportes magnéticos físicos. Sin embargo esa situación era la que reinaba a principio del siglo XXI en organizaciones pequeñas a medianas. La llegada de internet y el reemplazo de las redes propietarias por la web se impuso rápidamente, obviamente por la economía de costos asociados al cambio, pero a la vez logró conectar por primera vez a cualquier organización montada sobre esta red universal. Los intercambios de información era prácticamente instantáneos en formato puramente electrónico, pero además de eso el costo de almacenamiento se abarató tanto o más, permitiendo que la información se acumulara históricamente en forma muy sencilla.
Para mitigar el manejo de los grandes volúmenes de información se masificó el uso de los almacenes de datos o datawarehouse, de los que hablamos ampliamente en artículos anteriores. Esto trae como consecuencia que cualquier área de una organización necesite acceder y revisar estos almacenes con frecuencia. De ahí viene la gran decisión a tomar desde el nivel Directivo de la organización: el permitir el acceso directo a los almacenes de datos, o solo manejarse en función de la reportabilidad que ofrece. Las dos corrientes tienen sus pro y sus contras, veamos por separado las principales características y diferencias.
El acceso democrático a los datos facilita que se alivien las áreas de Sistemas, dado que la característica de autoservicio permite que cada área organice la información que necesita en función de sus propias necesidades y construya sus propios informes o reportabilidad. Desde un punto de vista de costos aliviar el capital humano de Sistemas sigue en cierto modo la línea de minimizar la injerencia de las áreas de Sistemas en todos los ámbitos, tendencia que revisamos ampliamente en este articulo de recuento histórico, sin embargo obliga a que personal no relacionado a sistemas adquiera conocimientos y experiencia en herramientas de acceso y consultas a los almacenes de datos. Es decir que obliga a estudiar temas que exceden las incumbencias profesionales de los puestos diversos, como ser los contables o de ventas, para poder aprovechar los recursos de información con cierto éxito. Por otro lado, hay un conflicto en el acceso mismo a la información que por consideraciones de seguridad no puede estar disponible en su totalidad a todos los ámbitos, siempre se maneja un gran porcentual de información reservada para áreas específicas. Las soluciones de compromiso para superar estas dificultades son principalmente las siguientes:
Capacitar a personal en temas de leguaje (SQL o Python para consultas/data science principalmente) y comprender modelos de datos dimensionales. Esto trae aparejado el gran problema de tomar con liviandad un tema que de por sí es complejo dentro de carreras universitarias y ámbito laboral de los profesionales de sistemas, para preparar a personal sin conocimientos de base suficientes. Los resultados que se obtienen con esta táctica son generalmente pobres y con una curva de aprendizaje larga y costosa.
Adjuntar a las áreas auxiliares con conocimientos de informática como personal de apoyo exclusivo: esto mejora la carga operativa del personal del área en temas que no son su especialidad, pero trae un sobre costo por sumar colaboradores que no son específicos de estas áreas, que al ser auxiliares operativos tampoco tienen grandes conocimientos. Generalmente serán estudiantes o personal temporario sin compromiso, y con una alta rotación al estar asignados en áreas en las que no pueden desarrollarse o crecer profesionalmente en su especialidad.
Para restringir el acceso a la totalidad de la información, obliga a las áreas de Sistemas de Información o las que estén a cargo de los almacenes de datos a segmentar los permisos en forma minuciosa aumentando la carga administrativa de los accesos y esquemas de seguridad, cuando no debilitándola. El complemento lógico a esta rutina es generar tantos datamart como áreas necesiten acceder, para poder consolidar en forma más visual el conjunto de datos que deben manejar cada una según el área de destino, desviando la función de la arquitectura de un datawarehouse corporativo de optimizar sus esquemas de almacenamiento a replicar de manera redundante la información en los distintos datamart, desvirtuando la misión principal de los mismos por temas puramente administrativos.
Estos tres considerandos generalmente provocan que la idea original se convierta en algo desde inmanejable hasta directamente oneroso e insostenible en el tiempo. Solo pensando que la rotación de las áreas no informáticas obliguen a comenzar los ciclos de capacitaciones internas prácticamente invalida a la larga el primer punto, y las transformaciones de la misma organización que reorganicen cada cierto tiempo su organigrama provoquen situaciones de estrés administrativo sobre los almacenes segmentados, convirtiendo esta política inviable con el transcurrir del tiempo salvo contadas excepciones: en organizaciones de poca rotación y alta madurez estructural.
Veamos ahora la política alternativa, la de un almacén de datos centralizado en un área de información. Bajo este esquema, las áreas no conocen los almacenes de datos sino a través de sus reportes o extracto de datos periódicos obtenidos en forma controlada. El área que administra la información aplica la seguridad según la necesidad del volcado de reportes respectos de las diversas áreas, y no tanto en la administración de los accesos que serán internos de su área, limitados en cantidad y roles mejorando el gobierno de la información. Las áreas no necesitan contar con personal especializado en manejo de modelos de datos o lenguajes de consulta, pudiendo utilizar las herramientas más tradicionales de oficina para operar sin problemas. Este esquema tiene el inconveniente que cada área queda limitada al manejo de datos en cantidades que sean manejables por sus herramientas, no teniendo la oportunidad de explorar en profundidad los datos por fuera de reportes estandarizados históricos, o trabajar con la big data. Veamos cuales son las consecuencias de lidiar o mitigar estas dificultades.
El área de Información (sea una Gerencia de Sistemas o como en mi caso una dedicada a BI) debe tener la capacidad suficiente para poder proveer de reportabilidad oportuna a toda la organización. Es decir que deberá contar con un número de colaboradores que exploten la información a medida de la demanda que tenga de reportabilidad nueva o eventual que surja a través del tiempo. Sí implica hacer crecer en personal el área, pero la ventaja del esquema anterior es que estarán mejor aprovechados dado que satisfacen necesidades en forma transversal y no son dedicados a una área específica cada uno. Mejora la sinergia de equipo y minimizarán los tiempos muertos entre requerimientos. Asimismo al pertenecer a un área de información mejorará la calidad profesional de los colaboradores, bajando además su rotación por estar más incentivados.
Concentrará las tareas de data science, o creará los modelos a explotar por las áreas de negocio. Esto implica que necesitará personal especializado en técnicas emergentes de Machine Learning, IA, o modelos neuronales/cuánticos, lo que alivia a las áreas de negocio a incorporar estas especialidades cada vez más alejadas de sus funciones específicas. Como contrapartida de ello es que los profesionales dedicados a explotar la información por estas técnicas deban comprender muy bien las necesidades de las disciplinas a las que abastecerán con sus modelos, lo que excede las funciones de profesionales de sistemas convirtiendo el área de Información en un ámbito multidisplinario. Esto último no debe sorprender, en gran medida es la culminación de un proceso que se viene dado de hace largo tiempo.
Se perderá en gran parte la opción para las áreas de negocio de hacer su propio “data mining” o exploración intuitiva de datos, salvo para conjuntos de información parciales y perdiendo mucho del contexto general. El estudio de los comportamientos desde la información interna y externa de la organización adquiridas en los almacenes de datos residirá principalmente en el equipo de data science, que deberá dividir sus tareas en satisfacer los requerimientos programados y el apoyo en el estudio eventual de información junto a las áreas de negocio sin necesidad de anticipar un entregable definido. Esto obliga a tener una perfecta administración de los tiempos de proyectos y los de servicio adicional, para no atrasar unos no desatender los otros.
En definitiva, si un área dedicada de Información atiende estas necesidades el rendimiento general, y los resultados obtenidos, mejorarán ostensiblemente respecto a la política analizada previamente. La gran desventaja es que necesita de una gran inversión inicial en tiempo y personal para concretarla, mucho más visible a niveles de presupuestos involucrados en un sector que aparentemente otorga un soporte de funcionamiento de la empresa. Esta última visión es la que llevó a disminuir la importancia de lo que eran las Gerencias de Sistemas, como vimos en el artículo previo desmembrada y minimizada prácticamente a un sector menor de servicios, y que de algún modo se van revirtiendo a medida que aparecen nuevas tecnologías de la información que necesitan de personal ultra especializado para aprovecharlas y no dejar estancada al organización en esquemas obsoletos que tenderán a desaparecer. Para ello deben reformular las incumbencias, y dividir definitivamente los que es el soporte de infraestructura y comunicaciones/redes como Gerencia de Servicios, y rescatar las Gerencias de Sistemas como esqueleto fundamental del flujo de la información de las organizaciones, y ahora también del análisis masivo de datos. Un artículo que detalla en forma completa como una unidad de este tipo se conforma en grandes estructuras organizacionales pueden leerlo en esta página.
El área de Sistemas de Información, con todas las variantes en su nombre que recibió a lo largo del tiempo, sufre una transformación constante pautada no tanto por el desarrollo tecnológico sino como las organizaciones tratan de incorporarlas. Para saber hacia donde se dirige conviene hacer un rápido recuento del tratamiento que recibió en todo este tiempo.
Como vamos hacer un poco de historia no debidamente documentada, el artículo de hoy refleja subjetivamente lo que vi y viví desde mis experiencias las de mis colegas. Al mejor estilo de la tradición oral, la historia se cuenta de boca en boca y agrega, o en algunos casos quitas, pinceladas de lo que va ocurriendo. Pero como los pueblos que mantienen sus memorias, no se dejan llevar por los discursos del momento y comprenden por analogías la situación que los enmarca mucho mejor que aquellos que las pierden o se les oculta.
Como bien sabemos, la disciplina de Sistemas nace de la mano de L. Van Bertalanffy desde el ámbito de la biología hacia los años 40 del siglo pasado, para extenderse rápidamente por todas las disciplinas imaginables. Las primeras en las que toma envergadura son las relacionadas a los Sistemas de Información, asociados generalmente a la Informática y que por un tema temporal, quizás no tan casual, se incorporan de la mano en la grandes organizaciones. Departamentos Informáticos iniciales, casi experimentales, se insertaron vertiginosamente alcanzando en menos de veinte años el estatus de Gerencias por derecho propio. El manejo de la información no es un tema de estatus, sino que implica poder y las Gerencias de Sistemas los aprovecharon para posicionarse hacia los 70 del siglo pasado como pilares de la estructura organizacional. Del mismo modo que ganaron importancia, las principales consultoras financieras incorporaron entre sus habilidades las de asesoramiento en temas informáticos, y entre los años 80 y hasta finales del siglo pasado la posición de Consultor Informático ocupaba un lugar de privilegio entre el staff de estas entidades.
Ahora bien, el crecimiento desmedido en una disciplina nueva que muy trabajosamente lograba ciertas estandarizaciones llevó a un escenario final de conflicto, donde las organizaciones más allá de los grandes mainframes (generalmente del ámbito bancario) contaban con sistemas de información básicamente propietarios, desconectados entre sí, y con un pobre mantenimiento en manos de unos pocos expertos. Lo más parecido a un caos, que no acompañaba la dinámica del cambio de siglo. El inicio del presente siglo encabezó una importante transformación para despejar la situación cada vez más inmanejable, se intentaron estandarizar mejor la mensajería de interconexión de sistemas, con el XML como gran unificador. Pero además se complementó esta política con la oportunidad de nicho que hallaron los principales desarrolladores de software en masificar los productos “enlatados” que gracias una adecuación por configuración inicial se podían adaptar a la realidad de cualquier empresa. Esta alternativa tuvo un éxito comercial increíble, la gran mayoría de las organizaciones migraron sus aplicaciones propietarias a estos productos para librarse del dolor de cabeza que les traía aparejado, cuando no el estancamiento que los inmovilizaba tecnológicamente. Una consecuencia de migrar los sistemas propios a productos trajo tres consecuencias, obligaba prácticamente en delegar la instalación y puesta en marcha en consultoras externas a falta de personal propio experimentado en los nuevos productos, los consultores experimentados se sustituyeron por personal técnico de instalación y soporte desplazando profesionales especializados en proyectos por mano de obra por servicio; y por último el papel esencial que oficiaban las Gerencias de Sistemas se vieron debilitadas y divididas en departamentos de Servicios y Comunicaciones por un lado, y Jefaturas de Proyectos Informáticos dependientes en gran medida como departamentos subordinados a las Gerencias de Finanzas, dedicados solo a la coordinación de los servicios tercerizados.
Sin embargo estos productos world- class no resultaron tampoco el paraíso, si bien aliviaron inicialmente el gran dolor, llevaron a los largo de los últimos veinte años al debilitamiento de las prácticas de Sistemas de Información internas de la empresa, y una profusión de sistemas enlatados de difícil interconexión entre ellos. Este panorama no podría ser más negativo si se le suma el gigantesco volumen de datos que proviene de la web, y el histórico acumulado por las mismas organizaciones, lo que lleva a un escenario en el que nuevamente se vislumbra una nueva crisis. La dependencia con las consultoras externas llega a niveles de costos siderales, donde la cantidad de equipo involucrado desde ambas partes hace nuevamente inmanejable y directamente convierte en pérdidas cualquier iniciativa informática, fracasando no pocas veces en el intento. Los productos enlatados que se adquirieron como una solución adaptable, en la mayoría de los casos lleva a las empresas a adaptar sus procesos internos para poder utilizar el producto. En tren de abaratar los costos, las Consultoras disminuyen la calidad de la mano de obra minimizando remuneración y márgenes de ganancia, llevando a los consultores actuales a rotar rápidamente sin llegar a tomar experiencia. Como contraparte, las áreas de Sistemas disminuidas en importancia dentro de la organización a su vez no llega a conformarse con buenos expertos, constituidas esencialmente con administradores de proyectos con poca y nada visión de completitud del flujo de la información dentro de la organización. Finalmente las decisiones sobre el mismo flujo de la información, se toman por comisiones mixtas entre personal de las Gerencias de Finanzas, que además del departamento de Sistemas también dirige las de Métodos y Procesos las que también se desnaturalizaron asimiladas a solo funciones de auditoría internas.
Si la organización en la que trabajas se asemeja en todos o en parte al último escenario descrito, no es para sorprenderse o que son parte de una excepción. la gran mayoría de las organizaciones están en este momento atravesando problemas similares. Hubiera gustado de hacer alguna conclusión más optimista de la etapa actual, pero la situación no lo permite. Aunque tampoco debemos quedarnos con la idea que todo está perdido. En general las organizaciones intentan sobrevivir, como ya lo mencioné en artículos anteriores, y reaccionan oportunamente para introducir los cambios necesarios. ¿Son estos cambios algo misterioso a lo que no tenemos acceso? Nada más lejos que eso, la solución siempre está en la teoría de los Sistemas de Información, solo se necesita rescatar estos principios y que vuelvan a tener la relevancia inicial que perdieron al asociarse casi exclusivamente a técnicas informáticas. Parte de este resucitar se viene dando inicialmente por la disciplina de Inteligencia de Negocios o BI (no confundir con sus ramas vecinas de Marketing o Comerciales), que de la mano de los Cuadro de Mandos Integral intenta unificar la gestión con el flujo dando de la información en la organización, y que tomando asimismo el rol de la Arquitectura de Datos hoy se convierte en la piedra angular para dominar el escenario inmediato. Sobre este último punto conviene leer un paper de IBM sobre el tema, que da un pantallazo donde materializa un tema que se viene dando de hecho en los sistemas de BI, y que describo con lujo de detalle al menos desde este blog desde hace más de diez años.
Si se preguntan cómo puedo atreverme a indicar la dirección de salida para esta situación, les comento que en la empresa en la que me desempeño actualmente tomamos este último camino, una misión que me encomendaron cuando ingresé hace unos tres años, ayudando no solo a transitar la pandemia con éxito sino que también ordenando y encauzando el flujo de la información interna, con grandes hitos cumplidos y con una perspectiva inmediata de lo más promisoria.
Un ejemplo genérico de esquema basado en una Arquitectura de Datos centralizada
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.
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.
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.
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.
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
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.
Informática y Sistemas (β) 