Aplicación do low-code en plataformas analíticas

Queridos lectores, bo día!

A tarefa de construír plataformas informáticas para recoller e analizar datos tarde ou cedo xorde para calquera empresa cuxo negocio se basee nun modelo de prestación de servizos cargado intelectualmente ou na creación de produtos tecnicamente complexos. Construír plataformas analíticas é unha tarefa complexa e que leva moito tempo. Non obstante, calquera tarefa pódese simplificar. Neste artigo quero compartir a miña experiencia no uso de ferramentas de código baixo para axudar a crear solucións analíticas. Esta experiencia foi adquirida durante a posta en marcha dunha serie de proxectos na dirección de Big Data Solutions da empresa Neoflex. Dende o ano 2005, a dirección de Big Data Solutions de Neoflex trata os temas de construción de almacéns de datos e lagos, resolvendo problemas de optimización da velocidade de procesamento da información e traballando nunha metodoloxía para a xestión da calidade dos datos.

Ninguén poderá evitar a acumulación consciente de datos débilmente e/ou fortemente estruturados. Quizais aínda que esteamos a falar de pequenas empresas. Despois de todo, ao escalar un negocio, un emprendedor prometedor enfrontarase aos problemas de desenvolver un programa de fidelización, quererá analizar a eficacia dos puntos de venda, pensará na publicidade dirixida e quedará desconcertado pola demanda de produtos de acompañamento. . Nunha primeira aproximación, o problema pódese resolver "de xeonllos". Pero a medida que o negocio crece, chegar a unha plataforma analítica aínda é inevitable.

Non obstante, en que caso as tarefas de análise de datos poden converterse en problemas de clase "Rocket Science"? Quizais no momento no que estamos a falar de datos realmente grandes.
Para facilitar a Rocket Science, podes comer o elefante peza por peza.

Canto máis discretas e autónomas sexan as túas aplicacións/servizos/microservizos, máis fácil será para ti, os teus compañeiros e toda a empresa dixerir o elefante.

Case todos os nosos clientes chegaron a este postulado, despois de reconstruír a paisaxe baseándose nas prácticas de enxeñería dos equipos de DevOps.

Pero mesmo cunha dieta "separada e elefantina", temos unha boa probabilidade de "sobresaturación" do panorama informático. Neste momento paga a pena parar, exhalar e mirar de lado plataforma de enxeñería de código baixo.

Moitos desenvolvedores teñen medo ante a perspectiva dunha vía sen saída na súa carreira cando se afastan de escribir código directamente para "arrastrar" as frechas nas interfaces de IU dos sistemas de código baixo. Pero a chegada das máquinas-ferramenta non levou á desaparición dos enxeñeiros, senón que levou o seu traballo a un novo nivel!

Imos descubrir por que.

A análise de datos no campo da loxística, industria de telecomunicacións, investigación de medios, sector financeiro sempre está asociada ás seguintes preguntas:

• Velocidade da análise automatizada;
• Capacidade para realizar experimentos sen afectar o fluxo principal de produción de datos;
• Fiabilidade dos datos elaborados;
• Seguimento de cambios e versións;
• Procedencia de datos, liñaxe de datos, CDC;
• Entrega rápida de novas funcións ao ambiente de produción;
• E o notorio: o custo de desenvolvemento e apoio.

É dicir, os enxeñeiros teñen un gran número de tarefas de alto nivel, que só se poden completar coa suficiente eficiencia limpando a súa conciencia das tarefas de desenvolvemento de baixo nivel.

Os requisitos previos para que os desenvolvedores pasaran a un novo nivel eran a evolución e dixitalización dos negocios. O valor do programador tamén está a cambiar: hai unha escaseza importante de desenvolvedores que poidan mergullarse nos conceptos do negocio que se está automatizando.

Debuxemos unha analoxía con linguaxes de programación de baixo e alto nivel. A transición das linguas de baixo nivel cara ás de alto nivel é unha transición de escribir "directivas directas na linguaxe do hardware" cara a "directivas na linguaxe das persoas". É dicir, engadindo algunha capa de abstracción. Neste caso, a transición a plataformas de código baixo desde linguaxes de programación de alto nivel é unha transición de "directivas na linguaxe das persoas" cara a "directivas na linguaxe dos negocios". Se hai desenvolvedores que están entristecidos por este feito, entón están entristecidos, quizais, desde o momento en que naceu Java Script, que utiliza funcións de ordenación de matrices. E estas funcións, por suposto, teñen implementación de software baixo o capó por outros medios da mesma programación de alto nivel.

Polo tanto, o código baixo é só a aparencia doutro nivel de abstracción.

Experiencia aplicada usando código baixo

O tema do código baixo é bastante amplo, pero agora gustaríame falar da aplicación práctica dos "conceptos de código baixo" usando o exemplo dun dos nosos proxectos.

A división de Big Data Solutions de Neoflex está máis especializada no sector financeiro dos negocios, construíndo almacéns de datos e lagos e automatizando varios informes. Neste nicho, o uso de código baixo converteuse nun estándar. Entre outras ferramentas de código baixo, podemos mencionar ferramentas para organizar procesos ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Ou Oracle Apex, que actúa como un entorno para o desenvolvemento rápido de interfaces para acceder e editar datos. Non obstante, o uso de ferramentas de desenvolvemento de código baixo non sempre implica construír aplicacións moi dirixidas nunha pila de tecnoloxía comercial cunha clara dependencia do provedor.

Usando plataformas de código baixo, tamén pode organizar a orquestración de fluxos de datos, crear plataformas de ciencia de datos ou, por exemplo, módulos para comprobar a calidade dos datos.

Un dos exemplos aplicados de experiencia no uso de ferramentas de desenvolvemento de código baixo é a colaboración entre Neoflex e Mediascope, un dos líderes no mercado ruso de investigación de medios. Un dos obxectivos comerciais desta empresa é a produción de datos a partir dos cales os anunciantes, plataformas de Internet, canles de televisión, emisoras de radio, axencias de publicidade e marcas toman decisións sobre a compra de publicidade e planifican as súas comunicacións de mercadotecnia.

A investigación de medios é unha área de negocio cargada tecnoloxicamente. Recoñecer secuencias de vídeo, recoller datos de dispositivos que analizan a visualización, medir a actividade en recursos web, todo isto implica que a empresa ten un gran persoal informático e unha enorme experiencia na construción de solucións analíticas. Pero o crecemento exponencial da cantidade de información, o número e a variedade das súas fontes obrigan á industria de datos de TI a progresar constantemente. A solución máis sinxela para escalar a plataforma analítica Mediascope xa funcionando podería ser aumentar o persoal de TI. Pero unha solución moito máis eficaz é acelerar o proceso de desenvolvemento. Un dos pasos que leva nesta dirección pode ser o uso de plataformas de código baixo.

No momento en que comezou o proxecto, a empresa xa tiña unha solución de produto en funcionamento. Non obstante, a implementación da solución en MSSQL non puido satisfacer plenamente as expectativas de escalar a funcionalidade mantendo un custo de desenvolvemento aceptable.

A tarefa que tiñamos ante nós era verdadeiramente ambiciosa: Neoflex e Mediascope tiveron que crear unha solución industrial en menos dun ano, suxeita ao lanzamento do MVP no primeiro trimestre da data de inicio.

A pila de tecnoloxía Hadoop foi escollida como a base para construír unha nova plataforma de datos baseada na computación de código baixo. HDFS converteuse no estándar para o almacenamento de datos mediante ficheiros de parquet. Para acceder aos datos localizados na plataforma utilizouse Hive, no que todos os escaparates dispoñibles se presentan en forma de táboas externas. A carga de datos no almacenamento implementouse mediante Kafka e Apache NiFi.

A ferramenta Lowe-code neste concepto utilizouse para optimizar a tarefa máis intensiva na construción dunha plataforma analítica: a tarefa de cálculo de datos.

Elixiuse a ferramenta Datagram de código baixo como o principal mecanismo para mapear datos. Datagrama Neoflex é unha ferramenta para desenvolver transformacións e fluxos de datos.
Usando esta ferramenta, pode prescindir de escribir o código Scala manualmente. O código Scala xérase automaticamente mediante o enfoque de Arquitectura impulsada por modelos.

Unha vantaxe obvia deste enfoque é a aceleración do proceso de desenvolvemento. Non obstante, ademais da velocidade, tamén hai as seguintes vantaxes:

• Visualización do contido e estrutura das fontes/receptores;
• Rastrexar a orixe dos obxectos de fluxo de datos a campos individuais (liñaxe);
• Execución parcial de transformacións con visualización de resultados intermedios;
• Revisar o código fonte e axustalo antes da execución;
• Validación automática de transformacións;
• Descarga automática de datos 1 en 1.

A barreira para entrar en solucións de código baixo para xerar transformacións é bastante baixa: o programador necesita coñecer SQL e ter experiencia traballando con ferramentas ETL. Paga a pena mencionar que os xeradores de transformación impulsados ​​por código non son ferramentas ETL no sentido amplo da palabra. É posible que as ferramentas de código baixo non teñan o seu propio contorno de execución de código. É dicir, o código xerado executarase no entorno que existía no clúster mesmo antes de instalar a solución de código baixo. E esta quizais sexa outra vantaxe para o karma de código baixo. Xa que, en paralelo cun equipo de código baixo, pode traballar un equipo "clásico" que implemente funcionalidades, por exemplo, en código Scala puro. Traer melloras de ambos os equipos á produción será sinxelo e fluido.

Quizais paga a pena notar que ademais de código baixo, tamén hai solucións sen código. E no seu núcleo, estas son cousas diferentes. O código baixo permite ao programador interferir máis co código xerado. No caso de Datagram, é posible ver e editar o código Scala xerado; sen código pode non proporcionar esa oportunidade. Esta diferenza é moi significativa non só en canto á flexibilidade da solución, senón tamén en canto á comodidade e á motivación no traballo dos enxeñeiros de datos.

Arquitectura de solución

Imos tentar descubrir exactamente como unha ferramenta de código baixo axuda a resolver o problema de optimizar a velocidade de desenvolvemento da funcionalidade de cálculo de datos. En primeiro lugar, vexamos a arquitectura funcional do sistema. Un exemplo neste caso é o modelo de produción de datos para a investigación dos medios.

As fontes de datos no noso caso son moi heteroxéneas e diversas:

• Os contadores de persoas (contadores de TV) son dispositivos de software e hardware que len o comportamento dos usuarios dos entrevistados do panel de televisión: quen, cando e que canle de televisión se viu no fogar que participa no estudo. A información proporcionada é un fluxo de intervalos de visualización de emisión vinculados ao paquete multimedia e ao produto multimedia. Os datos na fase de carga no Data Lake pódense enriquecer con atributos demográficos, xeoestratificación, zona horaria e outra información necesaria para analizar a visualización de televisión dun determinado produto multimedia. As medicións realizadas pódense utilizar para analizar ou planificar campañas publicitarias, avaliar a actividade e as preferencias da audiencia e elaborar a rede de emisión;
• Os datos poden proceder de sistemas de vixilancia para transmitir emisións de televisión e medir a visualización de contidos de recursos de vídeo en Internet;
• Ferramentas de medición no contorno web, incluíndo medidores centrados no sitio e no usuario. O fornecedor de datos para Data Lake pode ser un complemento do navegador da barra de investigación e unha aplicación móbil cunha VPN integrada.
• Os datos tamén poden proceder de sitios que consolidan os resultados de cubrir cuestionarios en liña e os resultados de entrevistas telefónicas nas enquisas das empresas;
• Pode producirse un enriquecemento adicional do lago de datos descargando información dos rexistros das empresas colaboradoras.

A implementación de como está a carga dos sistemas fonte na posta en escena primaria de datos en bruto pódese organizar de varias maneiras. Se se usa código baixo para estes fins, é posible a xeración automática de scripts de carga baseados en metadatos. Neste caso, non hai que baixar ao nivel de desenvolvemento de mapas de orixe para destino. Para implementar a carga automática, necesitamos establecer unha conexión coa fonte, e despois definir na interface de carga a lista de entidades a cargar. A estrutura de directorios en HDFS crearase automaticamente e corresponderá á estrutura de almacenamento de datos do sistema fonte.

Non obstante, no contexto deste proxecto, decidimos non usar esta función da plataforma de código baixo debido ao feito de que a empresa Mediascope xa comezou a traballar de forma independente na produción dun servizo similar usando a combinación Nifi + Kafka.

Convén indicar inmediatamente que estas ferramentas non son intercambiables, senón complementarias. Nifi e Kafka poden traballar tanto en conexión directa (Nifi -> Kafka) como inversa (Kafka -> Nifi). Para a plataforma de investigación de medios, utilizouse a primeira versión do paquete.

No noso caso, NayFi necesitaba procesar varios tipos de datos dos sistemas fonte e envialos ao corredor de Kafka. Neste caso, as mensaxes enviáronse a un tema específico de Kafka mediante procesadores PublishKafka Nifi. A orquestración e mantemento destas canalizacións realízase nunha interface visual. A ferramenta Nifi e o uso da combinación Nifi + Kafka tamén se poden chamar un enfoque de código baixo para o desenvolvemento, que ten unha barreira baixa para entrar nas tecnoloxías de Big Data e acelera o proceso de desenvolvemento de aplicacións.

A seguinte etapa na implementación do proxecto foi traer datos detallados a un único formato de capa semántica. Se unha entidade ten atributos históricos, o cálculo realízase no contexto da partición en cuestión. Se a entidade non é histórica, entón é opcionalmente posible recalcular o contido completo do obxecto ou rexeitar por completo a recalcular este obxecto (debido á falta de cambios). Nesta fase, xéranse claves para todas as entidades. As claves gárdanse nos directorios de Hbase correspondentes aos obxectos mestres, que conteñen unha correspondencia entre as claves da plataforma analítica e as claves dos sistemas fonte. A consolidación de entidades atómicas vai acompañada do enriquecemento cos resultados do cálculo preliminar dos datos analíticos. O marco para o cálculo de datos foi Spark. A funcionalidade descrita para levar datos a unha única semántica tamén se implementou en función de mapeamentos da ferramenta Datagram de código baixo.

A arquitectura de destino requiría acceso SQL aos datos para os usuarios empresariais. Utilizouse Hive para esta opción. Os obxectos rexístrase en Hive automaticamente cando activas a opción "Registr Hive Table" na ferramenta de código baixo.

Control de fluxo de cálculo

Datagram ten unha interface para crear deseños de fluxo de traballo. As asignacións pódense iniciar usando o programador Oozie. Na interface do programador de fluxos, é posible crear esquemas para transformacións de datos paralelas, secuenciais ou dependentes da execución. Hai soporte para scripts de shell e programas java. Tamén é posible utilizar o servidor Apache Livy. Apache Livy úsase para executar aplicacións directamente desde o ambiente de desenvolvemento.

Se a empresa xa ten o seu propio orquestrator de procesos, é posible utilizar a API REST para incorporar as asignacións nun fluxo existente. Por exemplo, tivemos unha experiencia bastante exitosa de incorporar mapeamentos en Scala en orquestadores escritos en PLSQL e Kotlin. A API REST da ferramenta de código baixo inclúe operacións como xerar un ano executable baseado no deseño de mapeo, chamar a un mapeo, chamar a unha secuencia de mapeamentos e, por suposto, pasar parámetros á URL para executar mapeamentos.

Xunto con Oozie, é posible organizar un fluxo de cálculo usando Airflow. Quizais non me demore moito na comparación entre Oozie e Airflow, pero simplemente digo que no contexto do traballo nun proxecto de investigación de medios, a elección foi a favor de Airflow. Os principais argumentos desta vez foron unha comunidade máis activa desenvolvendo o produto e unha interface + API máis desenvolvida.

O fluxo de aire tamén é bo porque usa o querido Python para describir os procesos de cálculo. E, en xeral, non hai tantas plataformas de xestión de fluxo de traballo de código aberto. O lanzamento e o seguimento da execución dos procesos (incluído un diagrama de Gantt) só engade puntos ao karma de Airflow.

O formato de ficheiro de configuración para lanzar asignacións de solucións de código baixo converteuse en spark-submit. Isto ocorreu por dúas razóns. En primeiro lugar, spark-submit permítelle executar directamente un ficheiro jar desde a consola. En segundo lugar, pode conter toda a información necesaria para configurar o fluxo de traballo (o que facilita a escritura de scripts que xeran Dag).
O elemento máis común do fluxo de traballo Airflow no noso caso foi o SparkSubmitOperator.

SparkSubmitOperator permítelle executar frascos: mapas de datagramas empaquetados con parámetros de entrada xerados previamente para eles.

Paga a pena mencionar que cada tarefa Airflow execútase nun fío separado e non sabe nada sobre outras tarefas. Polo tanto, a interacción entre tarefas realízase mediante operadores de control, como DummyOperator ou BranchPythonOperator.

En conxunto, o uso da solución de código baixo Datagram xunto coa universalización dos ficheiros de configuración (que forman Dag) levou a unha aceleración e simplificación significativas do proceso de desenvolvemento de fluxos de carga de datos.

Cálculo de escaparate

Quizais a etapa máis cargada intelectualmente na produción de datos analíticos sexa o paso de construír escaparates. No contexto dun dos fluxos de cálculo de datos da empresa de investigación, nesta fase, os datos redúcense a unha emisión de referencia, tendo en conta as correccións dos fusos horarios e ligados á grella de difusión. Tamén é posible axustarse á rede de transmisión local (noticias e publicidade locais). Entre outras cousas, este paso desglosa os intervalos de visualización continua dos produtos multimedia en función da análise dos intervalos de visualización. Inmediatamente, os valores de visualización son "ponderados" en función da información sobre a súa importancia (cálculo dun factor de corrección).

Un paso separado na preparación de vitrinas é a validación de datos. O algoritmo de validación implica o uso dunha serie de modelos de ciencia matemática. Non obstante, o uso dunha plataforma de código baixo permítelle dividir un algoritmo complexo nunha serie de mapas separados lexibles visualmente. Cada un dos mapeos realiza unha tarefa estreita. Como resultado, é posible a depuración intermedia, o rexistro e a visualización das etapas de preparación de datos.

Decidiuse discretizar o algoritmo de validación nas seguintes subetapas:

• Creación de regresións das dependencias de visualización da rede de televisión nunha rexión coa visualización de todas as redes da rexión durante 60 días.
• Cálculo de residuos estudiados (desviacións dos valores reais dos previstos polo modelo de regresión) para todos os puntos de regresión e para o día calculado.
• Unha selección de pares anómalos rexión-rede, onde o saldo estudiantil do día de liquidación supera a norma (especificada pola configuración da operación).
• Recálculo do residuo estudantil corrixido para parellas anómalas rexión-rede de televisión para cada entrevistado que viu a cadea na rexión, determinando a contribución deste entrevistado (a cantidade de cambio no residuo estudantilizado) ao excluír a visualización deste entrevistado da mostra. .
• Busca candidatos cuxa exclusión faga que o saldo estudiantil do día de pagamento volva á normalidade.

O exemplo anterior confirma a hipótese de que un enxeñeiro de datos xa ten moito na súa mente... E, se realmente se trata dun "enxeñeiro" e non dun "codificador", entón o medo á degradación profesional ao usar ferramentas de baixo código el debe finalmente retirarse.

Que máis pode facer o código baixo?

O ámbito de aplicación dunha ferramenta de código baixo para o procesamento de datos por lotes e fluxo sen necesidade de escribir código manualmente en Scala non remata aí.

O uso de código baixo no desenvolvemento de datalake xa se converteu nun estándar para nós. Probablemente podemos dicir que as solucións baseadas na pila Hadoop seguen o camiño de desenvolvemento dos DWH clásicos baseados en RDBMS. As ferramentas de código baixo na pila de Hadoop poden resolver tanto as tarefas de procesamento de datos como a tarefa de construír interfaces de BI finais. Ademais, hai que ter en conta que BI pode significar non só a representación de datos, senón tamén a súa edición por parte dos usuarios empresariais. Adoitamos usar esta funcionalidade cando creamos plataformas analíticas para o sector financeiro.

Entre outras cousas, usando código baixo e, en particular, Datagram, é posible resolver o problema de rastrexar a orixe dos obxectos de fluxo de datos con atomicidade ata campos individuais (liñaxe). Para iso, a ferramenta de código baixo implementa unha interface con Apache Atlas e Cloudera Navigator. Esencialmente, o desenvolvedor debe rexistrar un conxunto de obxectos nos dicionarios de Atlas e facer referencia aos obxectos rexistrados ao construír mapeos. O mecanismo para rastrexar a orixe dos datos ou analizar as dependencias dos obxectos aforra moito tempo cando é necesario facer melloras nos algoritmos de cálculo. Por exemplo, ao preparar os estados financeiros, esta función permítelle sobrevivir con máis comodidade ao período de cambios lexislativos. Despois de todo, canto mellor entendamos a dependencia entre as formas no contexto dos obxectos dunha capa detallada, menos atoparemos defectos "súbitos" e reduciremos o número de reelaboración.

Calidade de datos e código baixo

Outra tarefa implementada pola ferramenta de código baixo no proxecto Mediascope foi a tarefa da clase Data Quality. Unha característica especial da implementación do pipeline de verificación de datos para o proxecto da empresa de investigación foi a falta de impacto no rendemento e na velocidade do fluxo principal de cálculo de datos. Para poder orquestrar fluxos de verificación de datos independentes, utilizouse o xa familiar Apache Airflow. Como cada paso da produción de datos estaba listo, lanzouse en paralelo unha parte separada da canalización de DQ.

Considérase unha boa práctica controlar a calidade dos datos desde o momento da súa creación na plataforma analítica. Ao ter información sobre metadatos, podemos comprobar o cumprimento das condicións básicas desde o momento en que a información entra na capa primaria: non nulas, restricións, chaves externas. Esta funcionalidade implícase en base a mapeamentos xerados automaticamente da familia de calidade de datos en Datagram. Neste caso, a xeración de código tamén se basea nos metadatos do modelo. No proxecto Mediascope realizouse a interface cos metadatos do produto Enterprise Architect.

Ao vincular a ferramenta de código baixo con Enterprise Architect, xeráronse automaticamente as seguintes comprobacións:

• Comprobando a presenza de valores "nulos" nos campos co modificador "non nulo";
• Comprobar a presenza de duplicados da chave primaria;
• Comprobar a clave estranxeira dunha entidade;
• Comprobación da unicidade dunha cadea baseada nun conxunto de campos.

Para verificacións máis complexas da dispoñibilidade e fiabilidade dos datos, creouse unha asignación con Scala Expression, que toma como entrada un código de verificación Spark SQL externo preparado por analistas de Zeppelin.

Por suposto, a xeración automática de cheques debe conseguirse gradualmente. No marco do proxecto descrito, este foi precedido dos seguintes pasos:

• DQ implementado en cadernos Zeppelin;
• DQ integrado na cartografía;
• DQ en forma de mapeos masivos separados que conteñen todo un conxunto de comprobacións para unha entidade separada;
• Mapeamentos DQ parametrizados universais que aceptan información sobre metadatos e comprobacións comerciais como entrada.

Quizais a principal vantaxe de crear un servizo de verificación parametrizado sexa a redución do tempo que leva entregar funcionalidade ao contorno de produción. As novas comprobacións de calidade poden evitar o patrón clásico de entrega de código indirectamente a través de ambientes de desenvolvemento e probas:

• Todas as comprobacións de metadatos xéranse automaticamente cando se modifica o modelo en EA;
• As comprobacións de dispoñibilidade de datos (que determinan a presenza de calquera dato nun momento) pódense xerar en función dun directorio que almacena o momento esperado da aparición do seguinte dato no contexto dos obxectos;
• As comprobacións de validación de datos empresariais son creadas polos analistas nos cadernos de Zeppelin. Desde alí envíanse directamente ás táboas de configuración do módulo DQ no contorno de produción.

Non hai riscos de enviar guións directamente á produción. Mesmo cun erro de sintaxe, o máximo que nos ameaza é non realizar unha comprobación, porque o fluxo de cálculo de datos e o fluxo de lanzamento da comprobación de calidade están separados entre si.

En esencia, o servizo DQ funciona permanentemente no contorno de produción e está preparado para comezar o seu traballo no momento en que apareza o seguinte dato.

En vez de unha conclusión

A vantaxe de usar código baixo é obvia. Os desenvolvedores non precisan desenvolver a aplicación desde cero. E un programador libre de tarefas adicionais produce resultados máis rápido. A velocidade, á súa vez, libera tempo adicional para resolver problemas de optimización. Polo tanto, neste caso, pode contar cunha solución mellor e máis rápida.

Por suposto, o código baixo non é unha panacea e a maxia non ocorrerá por si mesma:

• A industria do código baixo está atravesando unha etapa de "facendo máis forte" e aínda non hai estándares industriais uniformes;
• Moitas solucións de código baixo non son gratuítas, e compralas debería ser un paso consciente, que debería facerse con total confianza nos beneficios económicos de usalas;
• Moitas solucións de código baixo non sempre funcionan ben con GIT/SVN. Ou son inconvenientes de usar se o código xerado está oculto;
• Ao expandir a arquitectura, pode ser necesario refinar a solución de código baixo, o que, á súa vez, provoca o efecto de "apego e dependencia" no provedor da solución de código baixo.
• É posible un nivel de seguridade adecuado, pero é moi laborioso e difícil de implementar en motores de sistemas de código baixo. As plataformas de código baixo deben escollerse non só polo principio de buscar beneficios do seu uso. Ao elixir, paga a pena facer preguntas sobre a dispoñibilidade de funcionalidades para o control de acceso e a delegación/escalada de datos de identificación a nivel de todo o panorama informático da organización.

Non obstante, se coñeces todas as deficiencias do sistema escollido e, con todo, os beneficios do seu uso son a maioría dominante, pasa ao código pequeno sen medo. Ademais, a transición cara a ela é inevitable, do mesmo xeito que calquera evolución é inevitable.

Se un programador nunha plataforma de código baixo fai o seu traballo máis rápido que dous desenvolvedores sen código baixo, isto dálle á empresa unha vantaxe en todos os aspectos. O limiar para a entrada en solucións de código baixo é inferior ao das tecnoloxías "tradicionais", e isto ten un efecto positivo no problema da escaseza de persoal. Cando se usan ferramentas de código baixo, é posible acelerar a interacción entre os equipos funcionais e tomar decisións máis rápidas sobre a corrección do camiño elixido para a investigación da ciencia de datos. As plataformas de baixo nivel poden impulsar a transformación dixital dunha organización porque as solucións producidas poden ser entendidas por especialistas non técnicos (especialmente usuarios empresariais).

Se tes prazos axustados, lóxica de negocio cargada, falta de coñecementos tecnolóxicos e necesitas acelerar o teu tempo de comercialización, entón o código baixo é unha forma de satisfacer as túas necesidades.

Non se pode negar a importancia das ferramentas de desenvolvemento tradicionais, pero en moitos casos, utilizar solucións de código baixo é a mellor forma de aumentar a eficiencia das tarefas que se están a resolver.

Fonte: www.habr.com