Estimados lectores, ¡buen día!
La tarea de construir plataformas informáticas para recopilar y analizar datos, tarde o temprano, surge para cualquier empresa cuyo negocio se base en un modelo de prestación de servicios intelectualmente cargado o en la creación de productos técnicamente complejos. Crear plataformas analíticas es una tarea compleja y que requiere mucho tiempo. Sin embargo, cualquier tarea se puede simplificar. En este artículo quiero compartir mi experiencia en el uso de herramientas de código bajo para ayudar a crear soluciones analíticas. Esta experiencia la adquirió durante la implementación de varios proyectos en la dirección de Soluciones Big Data de la empresa Neoflex. Desde 2005, la dirección de Soluciones Big Data de Neoflex se ocupa de los problemas de construcción de almacenes y lagos de datos, resolviendo problemas de optimización de la velocidad de procesamiento de la información y trabajando en una metodología para la gestión de la calidad de los datos.
Nadie podrá evitar la acumulación consciente de datos débil y/o fuertemente estructurados. Quizás incluso si hablamos de pequeñas empresas. Después de todo, al escalar un negocio, un emprendedor prometedor se enfrentará a los problemas de desarrollar un programa de fidelización, querrá analizar la efectividad de los puntos de venta, pensará en la publicidad dirigida y quedará desconcertado por la demanda de los productos que lo acompañan. . En una primera aproximación, el problema se puede resolver “sobre la rodilla”. Pero a medida que el negocio crece, llegar a una plataforma analítica sigue siendo inevitable.
Sin embargo, ¿en qué caso las tareas de análisis de datos pueden convertirse en problemas de clase de “ciencia espacial”? Quizás en el momento en que hablamos de big data realmente.
Para facilitar la ciencia espacial, puedes comerte el elefante pieza por pieza.
Cuanto más discretas y autónomas sean sus aplicaciones/servicios/microservicios, más fácil será para usted, sus colegas y toda la empresa digerir el elefante.
Casi todos nuestros clientes llegaron a este postulado, reconstruyendo el panorama basándose en las prácticas de ingeniería de los equipos DevOps.
Pero incluso con una dieta “separada y elefantina”, tenemos muchas posibilidades de que se produzca una “sobresaturación” del panorama de TI. En este momento vale la pena detenerse, exhalar y mirar hacia un lado. plataforma de ingeniería de código bajo.
Muchos desarrolladores temen la perspectiva de un callejón sin salida en sus carreras cuando pasan de escribir código directamente a "arrastrar" flechas en las interfaces UI de los sistemas de código bajo. Pero la llegada de las máquinas herramienta no provocó la desaparición de los ingenieros, ¡sino que llevó su trabajo a un nuevo nivel!
Averigüemos por qué.
El análisis de datos en el campo de la logística, la industria de las telecomunicaciones, la investigación de medios y el sector financiero siempre está asociado con las siguientes preguntas:
- Velocidad de análisis automatizado;
- Capacidad para realizar experimentos sin afectar el flujo principal de producción de datos;
- Fiabilidad de los datos preparados;
- Seguimiento de cambios y control de versiones;
- Procedencia de los datos, linaje de los datos, CDC;
- Entrega rápida de nuevas funciones al entorno de producción;
- Y lo notorio: el coste de desarrollo y soporte.
Es decir, los ingenieros tienen una gran cantidad de tareas de alto nivel, que pueden completarse con suficiente eficiencia sólo despejando su conciencia de las tareas de desarrollo de bajo nivel.
Los requisitos previos para que los desarrolladores pasaran a un nuevo nivel eran la evolución y la digitalización de los negocios. El valor del desarrollador también está cambiando: hay una escasez significativa de desarrolladores que puedan sumergirse en los conceptos del negocio que se está automatizando.
Hagamos una analogía con los lenguajes de programación de bajo y alto nivel. La transición de lenguajes de bajo nivel a lenguajes de alto nivel es una transición de escribir "directivas directas en el lenguaje del hardware" a "directivas en el lenguaje de las personas". Es decir, añadiendo alguna capa de abstracción. En este caso, la transición a plataformas low-code desde lenguajes de programación de alto nivel es una transición de “directivas en el lenguaje de las personas” a “directivas en el lenguaje de los negocios”. Si hay desarrolladores que están tristes por este hecho, entonces probablemente lo estén desde el momento en que nació Java Script, que utiliza funciones de clasificación de matrices. Y estas funciones, por supuesto, tienen una implementación de software interna mediante otros medios de la misma programación de alto nivel.
Por lo tanto, el código bajo es sólo la apariencia de otro nivel de abstracción.
Experiencia aplicada usando low-code
El tema del código bajo es bastante amplio, pero ahora me gustaría hablar sobre la aplicación práctica de los "conceptos de código bajo" usando el ejemplo de uno de nuestros proyectos.
La división Big Data Solutions de Neoflex se especializa más en el sector financiero de las empresas, construyendo almacenes y lagos de datos y automatizando diversos informes. En este nicho, el uso de código bajo se ha convertido desde hace mucho tiempo en un estándar. Entre otras herramientas low-code, podemos mencionar herramientas para organizar procesos ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. O Oracle Apex, que actúa como un entorno para el rápido desarrollo de interfaces para acceder y editar datos. Sin embargo, el uso de herramientas de desarrollo de código bajo no siempre implica la creación de aplicaciones altamente específicas sobre una pila de tecnología comercial con una clara dependencia del proveedor.
Utilizando plataformas low-code, también puede organizar la orquestación de flujos de datos, crear plataformas de ciencia de datos o, por ejemplo, módulos para comprobar la calidad de los datos.
Uno de los ejemplos aplicados de experiencia en el uso de herramientas de desarrollo de código bajo es la colaboración entre Neoflex y Mediascope, uno de los líderes en el mercado ruso de investigación de medios. Uno de los objetivos comerciales de esta empresa es la producción de datos a partir de los cuales anunciantes, plataformas de Internet, canales de televisión, estaciones de radio, agencias de publicidad y marcas toman decisiones sobre la compra de publicidad y planifican sus comunicaciones de marketing.
La investigación de medios es un área de negocio cargada de tecnología. Reconocer secuencias de vídeo, recopilar datos de dispositivos que analizan la visualización, medir la actividad en los recursos web: todo esto implica que la empresa cuenta con un gran personal de TI y una enorme experiencia en la creación de soluciones analíticas. Pero el crecimiento exponencial de la cantidad de información, la cantidad y variedad de sus fuentes obliga a la industria de datos de TI a progresar constantemente. La solución más sencilla para ampliar la plataforma analítica Mediascope que ya funciona podría ser aumentar el personal de TI. Pero una solución mucho más eficaz es acelerar el proceso de desarrollo. Uno de los pasos que conduzcan en esta dirección puede ser el uso de plataformas low-code.
Cuando comenzó el proyecto, la empresa ya contaba con una solución de producto en funcionamiento. Sin embargo, la implementación de la solución en MSSQL no pudo cumplir completamente con las expectativas de escalar la funcionalidad manteniendo un costo de desarrollo aceptable.
La tarea que teníamos ante nosotros era realmente ambiciosa: Neoflex y Mediascope tenían que crear una solución industrial en menos de un año, siempre que el MVP se lanzara dentro del primer trimestre de la fecha de inicio.
Se eligió la pila de tecnología Hadoop como base para construir una nueva plataforma de datos basada en computación de código bajo. HDFS se ha convertido en el estándar para el almacenamiento de datos mediante archivos parquet. Para acceder a los datos ubicados en la plataforma se utilizó Hive, en el que todos los escaparates disponibles se presentan en forma de tablas externas. La carga de datos en el almacenamiento se implementó utilizando Kafka y Apache NiFi.
La herramienta Lowe-code en este concepto se utilizó para optimizar la tarea más laboriosa en la construcción de una plataforma analítica: la tarea de cálculo de datos.
Se eligió la herramienta Datagram de código bajo como mecanismo principal para el mapeo de datos. Datagrama Neoflex es una herramienta para desarrollar transformaciones y flujos de datos.
Con esta herramienta, puede prescindir de escribir código Scala manualmente. El código Scala se genera automáticamente utilizando el enfoque de arquitectura basada en modelos.
Una ventaja obvia de este enfoque es la aceleración del proceso de desarrollo. Sin embargo, además de la velocidad, también existen las siguientes ventajas:
- Ver el contenido y la estructura de fuentes/receptores;
- Rastrear el origen de los objetos del flujo de datos hasta campos individuales (linaje);
- Ejecución parcial de transformaciones con visualización de resultados intermedios;
- Revisar el código fuente y ajustarlo antes de su ejecución;
- Validación automática de transformaciones;
- Descarga automática de datos 1 en 1.
La barrera de entrada a soluciones low-code para generar transformaciones es bastante baja: el desarrollador necesita conocer SQL y tener experiencia trabajando con herramientas ETL. Vale la pena mencionar que los generadores de transformación basados en código no son herramientas ETL en el sentido amplio de la palabra. Es posible que las herramientas de código bajo no tengan su propio entorno de ejecución de código. Es decir, el código generado se ejecutará en el entorno que existía en el clúster incluso antes de instalar la solución de código bajo. Y esta es quizás otra ventaja del karma de código bajo. Ya que, en paralelo con un equipo low-code, puede trabajar un equipo “clásico” que implemente funcionalidad, por ejemplo, en código Scala puro. Llevar las mejoras de ambos equipos a producción será simple y fluido.
Quizás valga la pena señalar que, además del código bajo, también existen soluciones sin código. Y en esencia, son cosas diferentes. El código bajo permite al desarrollador interferir más con el código generado. En el caso de Datagram, es posible ver y editar el código Scala generado; es posible que la falta de código no brinde esa oportunidad. Esta diferencia es muy significativa no sólo en términos de flexibilidad de la solución, sino también en términos de comodidad y motivación en el trabajo de los ingenieros de datos.
Arquitectura de soluciones
Intentemos descubrir exactamente cómo una herramienta de código bajo ayuda a resolver el problema de optimizar la velocidad de desarrollo de la funcionalidad de cálculo de datos. Primero, veamos la arquitectura funcional del sistema. Un ejemplo en este caso es el modelo de producción de datos para la investigación de medios.
Las fuentes de datos en nuestro caso son muy heterogéneas y diversas:
- Los medidores de personas (medidores de TV) son dispositivos de software y hardware que leen el comportamiento de los usuarios de los encuestados del panel de televisión: quién, cuándo y qué canal de televisión fue visto en el hogar que participa en el estudio. La información suministrada es un flujo de intervalos de visualización de transmisiones vinculados al paquete de medios y al producto de medios. Los datos en la etapa de carga en el lago de datos se pueden enriquecer con atributos demográficos, geoestratificación, zona horaria y otra información necesaria para analizar la visualización televisiva de un producto de medios en particular. Las mediciones realizadas pueden utilizarse para analizar o planificar campañas publicitarias, evaluar la actividad y preferencias de la audiencia y elaborar la red de difusión;
- Los datos pueden provenir de sistemas de seguimiento de transmisiones de televisión en streaming y de medición de la visualización de contenidos de recursos de vídeo en Internet;
- Herramientas de medición en el entorno web, incluidos medidores tanto centrados en el sitio como centrados en el usuario. El proveedor de datos para Data Lake puede ser un complemento del navegador de la barra de investigación y una aplicación móvil con una VPN integrada.
- Los datos también pueden provenir de sitios que consolidan los resultados de la cumplimentación de cuestionarios en línea y los resultados de entrevistas telefónicas en encuestas de empresas;
- Se puede lograr un enriquecimiento adicional del lago de datos descargando información de los registros de las empresas asociadas.
La implementación de la carga tal como está desde los sistemas de origen en la puesta en escena primaria de datos sin procesar se puede organizar de varias maneras. Si se utiliza código bajo para estos fines, es posible la generación automática de scripts de carga basados en metadatos. En este caso, no es necesario bajar al nivel de desarrollo de asignaciones de origen a destino. Para implementar la carga automática, necesitamos establecer una conexión con la fuente y luego definir en la interfaz de carga la lista de entidades que se cargarán. La estructura de directorios en HDFS se creará automáticamente y corresponderá a la estructura de almacenamiento de datos en el sistema de origen.
Sin embargo, en el contexto de este proyecto, decidimos no utilizar esta característica de la plataforma low-code debido a que la empresa Mediascope ya ha comenzado a trabajar de forma independiente para producir un servicio similar utilizando la combinación Nifi + Kafka.
Cabe señalar inmediatamente que estas herramientas no son intercambiables, sino complementarias. Nifi y Kafka pueden funcionar tanto en conexión directa (Nifi -> Kafka) como inversa (Kafka -> Nifi). Para la plataforma de investigación de medios, se utilizó la primera versión del paquete.
En nuestro caso, NayFi necesitaba procesar varios tipos de datos de los sistemas fuente y enviarlos al corredor Kafka. En este caso, los mensajes se enviaron a un tema Kafka específico utilizando procesadores PublishKafka Nifi. La orquestación y mantenimiento de estos ductos se realiza en una interfaz visual. La herramienta Nifi y el uso de la combinación Nifi + Kafka también pueden denominarse un enfoque de desarrollo de código bajo, que tiene una barrera baja para ingresar a las tecnologías de Big Data y acelera el proceso de desarrollo de aplicaciones.
La siguiente etapa en la implementación del proyecto fue llevar datos detallados a un formato de capa semántica única. Si una entidad tiene atributos históricos, el cálculo se realiza en el contexto de la partición en cuestión. Si la entidad no es histórica, entonces, opcionalmente, es posible recalcular todo el contenido del objeto o negarse por completo a recalcular este objeto (debido a la falta de cambios). En esta etapa, se generan claves para todas las entidades. Las claves se almacenan en los directorios de Hbase correspondientes a los objetos maestros, que contienen una correspondencia entre las claves de la plataforma analítica y las claves de los sistemas fuente. La consolidación de entidades atómicas va acompañada del enriquecimiento con los resultados del cálculo preliminar de los datos analíticos. El marco para el cálculo de datos fue Spark. La funcionalidad descrita para llevar datos a una semántica única también se implementó en base a asignaciones de la herramienta Datagram de código bajo.
La arquitectura de destino requería acceso SQL a los datos para los usuarios empresariales. Se utilizó Hive para esta opción. Los objetos se registran en Hive automáticamente cuando habilita la opción "Registrar tabla de Hive" en la herramienta de código bajo.
Control de flujo de cálculo
Datagram tiene una interfaz para crear diseños de flujo de trabajo. Las asignaciones se pueden iniciar utilizando el programador de Oozie. En la interfaz del desarrollador de flujo, es posible crear esquemas para transformaciones de datos paralelas, secuenciales o dependientes de la ejecución. Hay soporte para scripts de shell y programas java. También es posible utilizar el servidor Apache Livy. Apache Livy se utiliza para ejecutar aplicaciones directamente desde el entorno de desarrollo.
Si la empresa ya tiene su propio orquestador de procesos, es posible utilizar la API REST para integrar asignaciones en un flujo existente. Por ejemplo, tuvimos una experiencia bastante exitosa al incorporar asignaciones en Scala en orquestadores escritos en PLSQL y Kotlin. La API REST de una herramienta de bajo código incluye operaciones como generar un año ejecutable basado en el diseño del mapeo, llamar a un mapeo, llamar a una secuencia de mapeos y, por supuesto, pasar parámetros a la URL para ejecutar mapeos.
Junto con Oozie, es posible organizar un flujo de cálculo utilizando Airflow. Quizás no me detendré mucho en la comparación entre Oozie y Airflow, sino que simplemente diré que en el contexto del trabajo en un proyecto de investigación de medios, la elección recayó a favor de Airflow. Los principales argumentos esta vez fueron una comunidad más activa que desarrolla el producto y una interfaz + API más desarrollada.
Airflow también es bueno porque utiliza el querido Python para describir los procesos de cálculo. Y, en general, no existen tantas plataformas de gestión de flujo de trabajo de código abierto. Lanzar y monitorear la ejecución de procesos (incluido un diagrama de Gantt) solo agrega puntos al karma de Airflow.
El formato del archivo de configuración para lanzar asignaciones de soluciones de código bajo se ha convertido en envío de chispa. Esto sucedió por dos razones. Primero, Spark-Submit le permite ejecutar directamente un archivo jar desde la consola. En segundo lugar, puede contener toda la información necesaria para configurar el flujo de trabajo (lo que facilita la escritura de scripts que generan Dag).
El elemento más común del flujo de trabajo de Airflow en nuestro caso fue SparkSubmitOperator.
SparkSubmitOperator le permite ejecutar jars: asignaciones de datagramas empaquetados con parámetros de entrada generados previamente para ellos.
Vale la pena mencionar que cada tarea de Airflow se ejecuta en un hilo separado y no sabe nada sobre otras tareas. Por tanto, la interacción entre tareas se realiza mediante operadores de control, como DummyOperator o BranchPythonOperator.
En conjunto, el uso de la solución de código bajo Datagram junto con la universalización de los archivos de configuración (formando Dag) condujo a una aceleración y simplificación significativas del proceso de desarrollo de flujos de carga de datos.
Cálculos de escaparate
Quizás la etapa con mayor carga intelectual en la producción de datos analíticos sea la etapa de construcción de vitrinas. En el marco de uno de los flujos de cálculo de datos de la empresa de investigación, en esta fase los datos se reducen a una emisión de referencia, teniendo en cuenta correcciones por husos horarios y vinculados a la parrilla de emisión. También es posible realizar ajustes para la red de transmisión local (noticias y publicidad locales). Entre otras cosas, este paso desglosa los intervalos de visualización continua de productos multimedia basándose en el análisis de los intervalos de visualización. Inmediatamente, los valores de visualización se “ponderan” basándose en información sobre su importancia (cálculo de un factor de corrección).
Un paso aparte en la preparación de presentaciones es la validación de datos. El algoritmo de validación implica el uso de varios modelos científicos matemáticos. Sin embargo, el uso de una plataforma de código bajo le permite dividir un algoritmo complejo en una serie de asignaciones separadas visualmente legibles. Cada una de las asignaciones realiza una tarea limitada. Como resultado, es posible la depuración intermedia, el registro y la visualización de las etapas de preparación de datos.
Se decidió discretizar el algoritmo de validación en las siguientes subetapas:
- Construir regresiones de las dependencias de visualización de redes de televisión en una región con visualización de todas las redes de la región durante 60 días.
- Cálculo de residuos estudentizados (desviaciones de los valores reales de los predichos por el modelo de regresión) para todos los puntos de regresión y para el día calculado.
- Una selección de pares anómalos de región-red, donde el saldo estudentizado del día de liquidación excede la norma (especificada por la configuración de operación).
- Nuevo cálculo del residual estudentizado corregido para pares anómalos de región-red de televisión para cada encuestado que vio la cadena en la región, determinando la contribución de este encuestado (la cantidad de cambio en el residual estudentizado) al excluir la visualización de este encuestado de la muestra .
- Busque candidatos cuya exclusión vuelva a la normalidad el saldo estudentizado del día de pago.
El ejemplo anterior confirma la hipótesis de que un ingeniero de datos ya tiene demasiadas cosas en la cabeza... Y, si realmente se trata de un “ingeniero” y no de un “codificador”, entonces el miedo a la degradación profesional al utilizar herramientas de código bajo lo finalmente debe retirarse.
¿Qué más puede hacer el código bajo?
El ámbito de aplicación de una herramienta de bajo código para el procesamiento de datos por lotes y flujos sin la necesidad de escribir código manualmente en Scala no termina ahí.
El uso de low-code en el desarrollo de datalake ya se ha convertido en un estándar para nosotros. Probablemente podamos decir que las soluciones basadas en la pila de Hadoop siguen el camino de desarrollo de los DWH clásicos basados en RDBMS. Las herramientas de código bajo en la pila de Hadoop pueden resolver tanto las tareas de procesamiento de datos como la tarea de crear interfaces de BI finales. Además, cabe señalar que BI puede significar no sólo la representación de datos, sino también su edición por parte de los usuarios empresariales. A menudo utilizamos esta funcionalidad cuando creamos plataformas analíticas para el sector financiero.
Entre otras cosas, utilizando low-code y, en particular, Datagram, es posible resolver el problema de rastrear el origen de los objetos del flujo de datos con atomicidad hasta campos individuales (linaje). Para ello, la herramienta low-code implementa una interfaz con Apache Atlas y Cloudera Navigator. Básicamente, el desarrollador necesita registrar un conjunto de objetos en los diccionarios Atlas y hacer referencia a los objetos registrados al crear asignaciones. El mecanismo para rastrear el origen de los datos o analizar las dependencias de los objetos ahorra mucho tiempo cuando es necesario realizar mejoras en los algoritmos de cálculo. Por ejemplo, al preparar estados financieros, esta función le permite sobrevivir más cómodamente al período de cambios legislativos. Después de todo, cuanto mejor comprendamos la dependencia entre formas en el contexto de los objetos de una capa detallada, menos encontraremos defectos "repentinos" y reduciremos el número de reelaboraciones.
Calidad de datos y código bajo
Otra tarea implementada por la herramienta de código bajo en el proyecto Mediascope fue la tarea de clase de Calidad de datos. Una característica especial de la implementación del proceso de verificación de datos para el proyecto de la empresa de investigación fue la falta de impacto en el rendimiento y la velocidad del flujo principal de cálculo de datos. Para poder organizar flujos de verificación de datos independientes, se utilizó el ya conocido Apache Airflow. A medida que cada paso de la producción de datos estuvo listo, se lanzó en paralelo una parte separada del proceso de DQ.
Se considera una buena práctica monitorear la calidad de los datos desde el momento de su inicio en la plataforma analítica. Al tener información sobre los metadatos, podemos verificar el cumplimiento de las condiciones básicas desde el momento en que la información ingresa a la capa primaria: no nulos, restricciones, claves externas. Esta funcionalidad se implementa en base a asignaciones generadas automáticamente de la familia de calidad de datos en Datagram. La generación de código en este caso también se basa en los metadatos del modelo. En el proyecto Mediascope la interfaz se realizó con los metadatos del producto Enterprise Architect.
Al combinar la herramienta de código bajo con Enterprise Architect, se generaron automáticamente las siguientes comprobaciones:
- Comprobando la presencia de valores "nulos" en campos con el modificador "no nulo";
- Comprobar la presencia de duplicados de la clave primaria;
- Verificar la clave externa de una entidad;
- Comprobar la unicidad de una cadena en función de un conjunto de campos.
Para comprobaciones más complejas de disponibilidad y confiabilidad de los datos, se creó un mapeo con Scala Expression, que toma como entrada un código de verificación Spark SQL externo preparado por analistas de Zeppelin.
Por supuesto, la generación automática de cheques debe lograrse gradualmente. En el marco del proyecto descrito, este fue precedido por los siguientes pasos:
- DQ implementado en portátiles Zeppelin;
- DQ integrado en el mapeo;
- DQ en forma de asignaciones masivas separadas que contienen un conjunto completo de controles para una entidad separada;
- Asignaciones DQ parametrizadas universales que aceptan información sobre metadatos y comprobaciones comerciales como entrada.
Quizás la principal ventaja de crear un servicio de verificación parametrizado es la reducción del tiempo que lleva entregar la funcionalidad al entorno de producción. Los nuevos controles de calidad pueden evitar el patrón clásico de entregar código indirectamente a través de entornos de desarrollo y prueba:
- Todas las comprobaciones de metadatos se generan automáticamente cuando se modifica el modelo en EA;
- Las comprobaciones de disponibilidad de datos (que determinan la presencia de cualquier dato en un momento determinado) se pueden generar basándose en un directorio que almacena el momento esperado de aparición del siguiente dato en el contexto de los objetos;
- Los analistas crean comprobaciones de validación de datos comerciales en cuadernos Zeppelin. Desde allí se envían directamente a las tablas de configuración del módulo DQ en el entorno de producción.
No existen riesgos al enviar guiones directamente a producción. Incluso con un error de sintaxis, lo máximo que nos amenaza es no realizar una verificación, porque el flujo de cálculo de datos y el flujo de inicio de verificación de calidad están separados entre sí.
En esencia, el servicio DQ se ejecuta permanentemente en el entorno de producción y está listo para comenzar su trabajo en el momento en que aparece el siguiente dato.
En lugar de una conclusión
La ventaja de utilizar código bajo es obvia. Los desarrolladores no necesitan desarrollar la aplicación desde cero. Y un programador liberado de tareas adicionales produce resultados más rápido. La velocidad, a su vez, libera tiempo adicional para resolver problemas de optimización. Por tanto, en este caso, puedes contar con una solución mejor y más rápida.
Por supuesto, el código bajo no es una panacea y la magia no sucederá por sí sola:
- La industria del código bajo está atravesando una etapa de “fortalecimiento” y todavía no existen estándares industriales uniformes;
- Muchas soluciones low-code no son gratuitas y adquirirlas debe ser un paso consciente, que debe realizarse con plena confianza en los beneficios económicos de utilizarlas;
- Muchas soluciones de código bajo no siempre funcionan bien con GIT/SVN. O resultan incómodos de usar si el código generado está oculto;
- Al ampliar la arquitectura, puede ser necesario perfeccionar la solución de código bajo, lo que, a su vez, provoca el efecto de "apego y dependencia" en el proveedor de la solución de código bajo.
- Es posible alcanzar un nivel de seguridad adecuado, pero requiere mucha mano de obra y es difícil de implementar en motores de sistemas de código bajo. Las plataformas de código bajo deben elegirse no sólo por el principio de buscar beneficios a partir de su uso. Al elegir, vale la pena preguntarse sobre la disponibilidad de la funcionalidad para el control de acceso y la delegación/escalado de datos de identificación al nivel de todo el panorama de TI de la organización.
Sin embargo, si conoce todas las deficiencias del sistema elegido y, sin embargo, los beneficios de su uso son mayoría dominante, pase sin miedo al código pequeño. Además, la transición hacia él es inevitable, como también lo es cualquier evolución.
Si un desarrollador en una plataforma low-code hace su trabajo más rápido que dos desarrolladores sin low-code, esto le da a la empresa una ventaja en todos los aspectos. El umbral para entrar en soluciones low-code es más bajo que en tecnologías “tradicionales”, y esto tiene un efecto positivo en la cuestión de la escasez de personal. Cuando se utilizan herramientas de código bajo, es posible acelerar la interacción entre equipos funcionales y tomar decisiones más rápidas sobre la corrección del camino elegido de investigación en ciencia de datos. Las plataformas de bajo nivel pueden impulsar la transformación digital de una organización porque las soluciones producidas pueden ser entendidas por especialistas no técnicos (en particular, usuarios empresariales).
Si tiene plazos ajustados, una lógica empresarial cargada, falta de experiencia tecnológica y necesita acelerar su tiempo de comercialización, entonces el código bajo es una forma de satisfacer sus necesidades.
No se puede negar la importancia de las herramientas de desarrollo tradicionales, pero en muchos casos, utilizar soluciones low-code es la mejor manera de aumentar la eficiencia de las tareas que se resuelven.
Fuente: habr.com