En Moneythor, estamos comprometidos a ofrecer una solución técnica que pueda implementarse con componentes que sean fáciles de mantener, rentables y totalmente alineados con los estándares de la industria para garantizar la longevidad y escalabilidad de nuestro software.
La industria del software siempre ha sido y seguirá siendo susceptible a desarrollos rápidos con la implementación de nuevas arquitecturas y herramientas obsoletas rápidamente, pero también altamente competitiva a medida que se desarrollan nuevas iniciativas para establecer diferenciadores clave para las soluciones. Esto es aún más cierto hoy en día, ya que los proveedores de la nube invierten grandes cantidades en software, hardware e infraestructura.
En este entorno en constante cambio, revisemos qué tenemos en cuenta cuando tomamos cuidadosamente nuestras decisiones de arquitectura técnica y a qué prestamos atención al construir la solución de dinero.
¿Qué es la deuda técnica?
Hay varias interpretaciones de deuda técnica, pero la definición más comúnmente aceptada es cualquier decisión tomada con el propósito de lograr ganancias rápidas a pesar de saberlo implica refactorizar o revisar en una etapa posterior. En nuestro caso, esto podría ser, por ejemplo, implementar un código que funcione perfectamente y que no esté alineado con la estrategia a largo plazo del producto, o casos extremos que se dejen de lado voluntariamente en ausencia de requisitos funcionales que los necesiten en ese momento.
¿Por qué es esto importante para nosotros?
Como la gran mayoría de las soluciones de software empresarial, la plataforma Moneythor se basa en una buena cantidad de bibliotecas de código abierto. Históricamente, el software de código abierto ha sido desarrollado por individuos o financiado por líderes de la industria. Hoy en día, las grandes organizaciones contribuyen cada vez más al desarrollo de muchos proyectos de software de código abierto para ayudar a satisfacer sus propias necesidades. Piensa en lo ahora inevitable Apache Kafka (de LinkedIn), Kubernetes (de Google), Reaccionar (de Facebook/Meta); la lista crece cada día.
Dada la complejidad de la solución Moneythor, sería inimaginable, extremadamente lento y costoso construir nosotros mismos todos los aspectos de la solución, sin mencionar el riesgo de reinventar la rueda sin alcanzar nunca el mismo nivel de calidad de estos proyectos patrocinados por terceros. por organizaciones reconocidas y probado intensivamente en múltiples entornos de producción.
Dicho esto, la seguridad es una gran preocupación. A nadie le gusta escuchar cómo un servicio ha sufrido una violación de datos, pero es casi imposible evitar vulnerabilidades como las que se informan periódicamente. Vulnerabilidades y exposiciones comunes y a menudo requieren una acción inmediata para remediarlos.
Como tal, probamos y seleccionamos cuidadosamente todas las bibliotecas de terceros, considerando siempre las alternativas y lo difícil que sería comprender su código fuente y solucionar nosotros mismos cualquier problema de seguridad. Una vez hecho esto, lo integramos en nuestra solución con las capas necesarias para garantizar que pueda actualizarse o incluso reemplazarse fácilmente.
Sea consciente de su deuda técnica
Reescribir el código fuente o cambiar de una tecnología a otra a menudo implica un alto costo y es difícil de justificar ante las partes interesadas. Por ese motivo, tomamos en cuenta la deuda técnica desde el principio. La forma en que diseñamos nuestra solución juega un papel importante aquí y, a veces, no dudamos en realizar un esfuerzo adicional inicial para preparar la solución para una pieza adicional de funcionalidad no confirmada.
Esta también es una oportunidad para que registremos desde el principio lo que se considerarán implementaciones finales de nuevas funciones y elementos en los que tuvimos que tomar algunos atajos para producir una solución funcional a tiempo, sabiendo aún que algunas partes podrían revisarse más adelante.
Vale la pena señalar que los requisitos funcionales evolucionan y tenemos que revisar el código existente. En ese caso, no estamos abordando una partida de deuda técnica. Es simplemente el ciclo de vida natural de una solución mejorada constantemente.
Mantenga la deuda técnica bajo control
Dicho esto, es imposible adivinar el futuro y arriesgado apostar por una próxima solución o palabra de moda. Por ejemplo, la solución Moneythor aprovecha las bases del conjunto de aplicaciones Java Enterprise, una plataforma muy madura y respetable que ha respaldado el desarrollo de millones de proyectos de software empresarial probados en las últimas décadas. Una de las características de la plataforma Java es la venerable API Servlet de bloqueo, un modelo probado diferente del enfoque de procesamiento de flujo asíncrono sin bloqueo promovido por la nueva iniciativa de programación reactiva.
Si este último se convierte en el enfoque predeterminado en el futuro una vez que la comunidad y muchas dependencias adopten este nuevo paradigma de programación, podría crear una deuda técnica en la que sería necesario invertir tiempo para llevar una solución a un nuevo estándar con el mismo nivel de funcionalidad como antes.
En este caso, el papel del equipo de ingeniería es nuevamente diseñar la solución de tal manera que podamos minimizar el esfuerzo de reescribir y adaptar las características existentes sin tener que dedicar tiempo a adaptar la lógica de negocios existente.
Los sistemas de almacenamiento de datos crean fácilmente deuda técnica
Como es bien sabido, el mundo produce y consume cada año más datos a un ritmo exponencial. Procesar y analizar una gran cantidad de datos siempre ha sido un desafío importante para las organizaciones de todos los sectores, incluida la industria de servicios financieros. No sorprende que la industria del software trabaje y cree constantemente nuevas herramientas con el objetivo de resolver estos desafíos de datos en constante evolución.
Si bien las bases de datos relacionales eran las predeterminadas en el pasado y sus versiones administradas en la nube son muy escalables, ahora existen enfoques completamente diferentes sobre cómo persistir y consultar datos. Cambiar de una base de datos relacional tradicional a algo así como un almacén de documentos no es tan sencillo como cambiar entre dos proveedores de bases de datos relacionales diferentes. En muchos casos, la solución existente se basa en principios y contratos que ya no existen en el nuevo almacén de datos.
La deuda técnica tiene consecuencias
Nuestra experiencia en esta industria durante las últimas décadas y múltiples proyectos heterogéneos muestran que existe un umbral por encima del cual la deuda técnica se convierte en un agujero negro y este umbral disminuye cada vez más con el tiempo, especialmente cuando no se toman medidas.
Lo que significa es esto: cuando se alcanza el límite, puede ser imposible ponerse al día con su deuda técnica y, en última instancia, costará menos reescribir todo desde cero, lo que puede ser un esfuerzo significativo y desmoralizador. Cuando eso sucede, toda la experiencia y el conocimiento que se adquiere con una tecnología deben reconstruirse.
Por ejemplo, cambiar de la popular base de datos relacional PostgreSQL al también popular almacén de documentos Mongo DB no se trata sólo de hacer que su software sea compatible con las dos capas persistentes. También se trata de comprender las implicaciones que tiene en el flujo de datos, el proceso transaccional, los pros y los contras de ambas soluciones, lo que se obtiene y lo que se pierde. Esto puede pasarse por alto fácilmente y provocar retrasos y costes adicionales, e incluso fallos en algunos casos.
Nuestro enfoque para gestionar la deuda técnica
Como se mencionó anteriormente, sería imposible predecir los acontecimientos, ni podemos implementar todo de una vez de manera razonable. Lo que podemos hacer es intentar protegernos contra obstáculos innecesarios. Existen patrones de diseño y arquitectura bien conocidos y probados para este propósito exacto.
En primer lugar, la solución se construye sobre la Marco de primavera. El punto más importante a tener en cuenta aquí es que elegimos Spring no solo porque es extremadamente popular, está bien mantenido y proporciona un rico conjunto de subproyectos para ayudar a abordar muchos aspectos de las soluciones de software de nivel empresarial, sino porque, en esencia, Es un marco de inyección de dependencia que nos permite desacoplar nuestro código y facilita enormemente la implementación del separación de intereses principio.
En la medida de lo posible, desacoplamos todo, desde bibliotecas de terceros, a nuestro propio código para que la implementación sea fácilmente reemplazable. A continuación, una vez que decidimos implementar una nueva característica, comenzamos por desacoplar la implementación concreta de la lógica empresarial con el marco. También nos tomamos más tiempo para diseñar una capa intermediaria genérica que se ubica entre el marco técnico impulsado por Spring o bibliotecas de terceros y la implementación de los requisitos comerciales. El propósito de esta capa intermedia es proporcionar una abstracción de de qué se trata la característica para que luego podamos personalizarla fácilmente y protegerla del impacto de actualizar o reemplazar componentes técnicos subyacentes.
El resultado es que la solución Moneythor se convierte en sí misma en un marco con una implementación concreta de la lógica funcional, y no solo esa implementación. Esto nos proporciona un gran nivel de flexibilidad, lo cual es extremadamente valioso en nuestro caso. También nos da la capacidad de mantener el mismo producto para todos los clientes. Por supuesto, adaptamos nuestra solución a diferentes regiones, entornos de destino y características específicas del cliente, pero esto se logra gracias a una sola versión del código fuente sin bifurcación.
Hoy podemos medir los beneficios de este enfoque. Comenzamos a desarrollar este conjunto de aplicaciones hace casi 10 años y, aún así, no mantenemos ninguna biblioteca vulnerable. En su lugar, utilizamos la última versión de Spring y otros componentes de terceros, lo que nos permite agregar soporte para nuevas tecnologías dentro del presupuesto y sin la necesidad de refactorizar gran parte del software. Por último, pero no menos importante, esto mantiene motivado a nuestro equipo de desarrollo para trabajar en una arquitectura moderna con tecnologías y herramientas recientes.
Básicamente, se trata de encontrar el equilibrio adecuado entre diseño e ingeniería complejos y un costo aceptable de retrabajo, y con la solución Moneythor hemos podido lograr ese equilibrio y continuaremos haciéndolo.
