Las plataformas de código bajo (plataformas de aplicación de código bajo, LCAP) surgieron como reacción a la complejidad y variedad de las herramientas modernas de desarrollo de software.
Según Gartner, uno de los jugadores más famosos en esta área es Mendix . La venta de Siemens por espacio $ 700 millones confirma esto. Así que usaré esta plataforma como ejemplo, aunque conclusiones similares serán ciertas para Outsystems, Appian, Kony, Betty Blocks y otros.
Entonces, al enfocarse en las ventas a los gerentes superiores, los proveedores de plataformas de bajo código prometen que incluso los usuarios comunes podrán crear aplicaciones comerciales por su cuenta.
Es decir, ¿ya no se necesitan desarrolladores?
Bueno ... después de unos años, Mendix se ve obligado a admitir:
"Ahora los desarrolladores necesitan más que nunca".
Esto es un giro!
Parece que Mendix reconoció que para algo más difícil que el trabajo básico con datos, aún se necesita un desarrollador profesional, al igual que se necesita un mecánico profesional para reparar un automóvil.
Desafortunadamente, las plataformas modernas de bajo código simplemente no están diseñadas para desarrolladores, y confiar en ellas a largo plazo es arriesgado para los negocios. Si su empresa está considerando seriamente el uso de plataformas de bajo código en la operación industrial, vale la pena considerar nuevamente esta solución. A continuación intentaré argumentar esto.
Gran herramienta de prototipos
Mendix es una excelente opción para automatizar procesos simples o creación de prototipos, disponible para analistas o usuarios avanzados.
El editor visual le permite describir el modelo de datos, crear rápidamente pantallas usando un conjunto de widgets y plantillas, e incluso describir la lógica usando los llamados microflujos :
Una vez completado, puede implementar su aplicación en la nube Mendix con un solo clic y comenzar a trabajar con ella. ¡Tan simple que suena a magia! Y parece que se vende bien.
Sin embargo, después de pasar por la etapa de prototipo, la interacción del sistema con el usuario y la lógica de negocios es casi inevitablemente complicada. Para desarrollar el proyecto aún más, se requiere un profesional. Entonces, veamos a Mendix a través de los ojos de un desarrollador.
Desarrollo lento
Cualquier lógica, ya sea informática o interacción del usuario, debe describirse en un diagrama de flujo de microflujo, como se muestra arriba.
Hay varios problemas aquí.
En primer lugar, es mucho tiempo . Obviamente, es más rápido escribir 10 líneas de código en un buen IDE que arrastrar y soltar, personalizar y unir docenas de bloques.
En segundo lugar, legibilidad . Los bloques se ven hermosos, pero ¿qué significa esta Sub_RegistrationValidation ? Es imposible entender esto sin caer en el bloque. Tan pronto como el número de bloques crezca a varias decenas, será extremadamente difícil entender la lógica.
Como alternativa para casos complejos, Mendix admite llamadas de código Java desde microflujos. Puede escribir código en Eclipse, que generalmente es bueno, aunque muchos preferirían un IDE más popular. La desventaja es la falta de transparencia: todos los puntos de entrada están en microflujos, por lo que la lógica está dispersa entre dos entornos poco acoplados. Como resultado, la depuración y el seguimiento de dependencias es difícil.
Lo último que quería mencionar era el control de versiones.
La buena noticia es que él es. Lo malo es que es una versión simplificada de Subversion. Olvídate del flujo de git.
Falta de control
Cualquier persona familiarizada con el ecosistema de Java no puede subestimar el poder del código abierto. Cuando aparece un error en algún lugar de la pila, puede ver en qué parte del código sucedió esto. El código se puede depurar para comprender exactamente lo que está sucediendo. Puedes buscar en Google la solución. Puede enviar una solicitud de extracción. En casos extremos, puede bifurcar la biblioteca. Usted tiene el control total del proyecto.
Con Mendix, puedes olvidarte de eso. Este es un marco comercial cerrado, y lo que sucede dentro de él es una caja negra real. Todo lo que le queda es comprar soporte pagado o esperar a que alguien lo ayude en un foro con ~ 200 preguntas por mes (¡compárelo con la etiqueta #spring en stackoverflow !).
Dependencia del vendedor
Mendix probablemente reproche esto con bastante frecuencia. Incluso publicaron un artículo que decía que realmente no hay adicción. Si lees entre el término, se lee:
Puede obtener sus datos, DDL, recursos de UI y código (microflow convertido mágicamente a código Java).
¿Se ejecutará o compilará sin tiempo de ejecución y API Mendix? ¿Se puede mantener y desarrollar esto? Las preguntas son retóricas. De hecho, necesitarás reescribir completamente todo. Depende de una plataforma propietaria. No es dueño del sistema que creó.
Escalabilidad limitada
El marketing de Mendix se centra en las empresas más grandes, por lo que el término "escalabilidad" parpadea constantemente en materiales de marketing.
En 2017, Mendix introdujo el tiempo de ejecución sin estado, es decir, toda la información de la sesión se almacena en el lado del cliente o en un almacenamiento persistente.
Teóricamente, esto significa escalabilidad horizontal ilimitada. Suena genial, pero como siempre hay un matiz: la base de datos.
Una base de datos casi siempre resulta ser un cuello de botella en una aplicación corporativa. Entonces, ¿qué almacena la información detrás de muchos servidores sin estado Mendix? Sin sorpresas: esta es una buena base de datos relacional. En la nube Mendix - PostgreSQL. Además, el DDL Mendix generado, por decirlo suavemente, no es del todo óptimo. Por ejemplo, vi una tabla intermedia que se usa comúnmente para modelar relaciones N: M, creada para una relación 1: N.
El problema de la escalabilidad podría resolverse mediante métodos estándar: optimización de la estructura de la base de datos, almacenamiento en caché o incluso el uso de soluciones como Citus. Pero, por supuesto, no existe tal posibilidad.
La única forma de escalar la base de datos es escalar usando réplicas de lectura (por ejemplo, Amazon RDS). Pero para el registro, esto no funcionará.
Resumiendo lo anterior, Mendix tiene una limitación fundamental en la escalabilidad y no tiene medios para optimizar el rendimiento.
Pregunta de recursos humanos
La búsqueda de personal calificado siempre es una tarea difícil. Parece que en este Mendix es el sueño de cualquier gerente, porque los requisitos de calificación se reducen drásticamente.
De hecho, ya hemos descubierto que la mayoría de los proyectos requieren un equipo profesional, independientemente de la herramienta. Pero es poco probable que un desarrollador respetuoso acepte trabajar con Mendix, ya que este es un punto muerto obvio en su carrera.
Precios
Por último pero no menos importante. El costo de una licencia para una aplicación comienza en $ 1875 por mes, sujeto a una suscripción por tres años, la licencia está limitada a 50 usuarios internos.
El precio de una licencia corporativa con la posibilidad de implementación local comienza en $ 7825, que es de casi $ 100,000 por año.
Una empresa mediana con varios cientos de usuarios pagará anualmente facturas de decenas de millones de rublos.
No olvide que estamos hablando de aplicaciones relativamente simples, como puede entender de lo anterior. Para mí, esto es una locura. Este modelo de precios también hace prácticamente imposible replicar las aplicaciones que creó.
Entonces, ¿por qué los LCAP siguen siendo populares?
En mi opinión, la razón radica en la decepción en los procesos existentes. Administrar un equipo de desarrollo en una organización grande, ya sea un equipo interno o una subcontratación, es demasiado complicado.
Planificación presupuestaria, aprobaciones interminables, falta de personas dispuestas a asumir la responsabilidad. Creo que esto es familiar para muchos.
Lo curioso es que lo primero que viene a la mente cuando los proyectos de TI avanzan demasiado lentamente es contratar aún más desarrolladores y, por supuesto, gerentes. No hace falta decir que esto solo empeora la situación. Conozco un par de bancos con más de 10,000 (!!!) desarrolladores, y al menos la mitad de ellos están haciendo un trabajo inútil.
En su desesperación, los líderes empresariales están buscando una solución en "varitas mágicas" como LCAP, supuestamente capaces de resolver todos los problemas.
Cómo salir de este círculo vicioso es un tema para un artículo separado. Pero esto es una cuestión de gestión, no de tecnología.
Sin entrar en detalles, si logra crear un pequeño equipo calificado de 3 a 10 personas totalmente involucradas en el proyecto, con contacto directo con el tomador de decisiones, obtendrá excelentes resultados más rápido y más barato de lo que espera.
Cuales son las alternativas?
Ahora hay una gran selección de herramientas y marcos para desarrolladores.
Por ejemplo, Spring Framework es la tecnología de código abierto más popular para crear software empresarial que funciona bien con marcos web como React o Angular. Y herramientas como Spring Initializr y JHipster han simplificado enormemente la creación de proyectos en los últimos años.
Si desea obtener el resultado más rápido, debe considerar las herramientas RAD, como la Plataforma CUBA .
Se basa en el mismo Spring Framework, lo complementa con herramientas de desarrollo visual y una gran cantidad de componentes listos para usar. Quizás esta sea la alternativa más cercana al LCAP, ya que proporciona flexibilidad y un proceso de desarrollo cómodo.
La elección final debe depender de la tarea, así como de las habilidades del equipo y sus preferencias.
Conclusión
Las plataformas de código bajo son excelentes para la creación de prototipos. Reducen la brecha entre los usuarios comerciales y la TI, lo que le permite obtener rápidamente un prototipo funcional y formar una visión del sistema futuro.
Dado que hay muy pocos usuarios prototipo, los costos en esta etapa también son pequeños. ¡Y vale la pena detenerse en este momento!
Al utilizar LCAP para desarrollar un sistema completo, la velocidad del trabajo caerá inevitablemente y dependerá de la costosa plataforma patentada que lo limita.