Es un hecho que las arquitecturas de microservicios han cambiado la manera en la que se concibe el software.
¿Cómo ha sido hasta ahora?
Hace no muchos años, los sistemas distribuidos clásicos copaban el mercado. Es más, todas las grandes organizaciones tenían su propia de granja de servidores websphere’s, jboss, iss… a las que le sumaban una base de datos relacional, sobre la que desplegaban sus aplicaciones corporativas.
Estas aplicaciones presentan una serie de inconvenientes, entre los que destacan:
- Indisponibilidades de servicio, bien por mantenimiento de la plataforma bien por no poder atender la demanda en determinadas situaciones
- Pobre rendimiento en situaciones de alta carga o incluso de manera sistémica
- Bugs, generados por el hecho de ser aplicaciones grandes y no establecer procedimientos automatizados de calidad
- Lentitud de adaptación al negocio, la burocracia interna de las organizaciones unida al modelo de desarrollo de software en cascada hace que desde que surge una necesidad, hasta que el software se pone en producción, puedan haber pasado meses o incluso años.
La solución
Las arquitecturas de microservicios unidas al paradigma devops tratan de mitigar estos problemas.
Cuando en Hocelot definimos nuestra arquitectura corporativa tuvimos claro que ésta debía seguir los siguientes principios:
- Mantenibilidad: La plataforma debía permitir cambios y comportarse bien ante ellos, sin que ello suponga un coste en tiempo poco razonable. Debíamos ser capaces de minimizar los tiempos de desarrollo.
- Flexibilidad: El negocio crece y evoluciona continuamente. La tecnología debía ser un facilitador de ese cambio, nunca un impedimento en el camino.
- Time-to-Market: Debíamos optimizar los procesos de producción de software para llegar al mercado antes que nuestros competidores pero con la calidad exigida.
- Costes: Los costes derivados de esta solución debían estar alineados y ser justificados por los beneficios que se obtuvieran de la misma.
Con estos requisitos empezamos a poner en marcha nuestra arquitectura de microservicios, la cual iremos describiendo más adelante. Mientras tanto, conviene reflexionar unos minutos:
¿Todas las organizaciones tienen los mismos requisitos? es más, ¿todas las organizaciones disponen de los recursos necesarios para poner en marcha este tipo de arquitecturas?
¿Las arquitecturas de microservicios son la solución para todos?
La respuesta es evidente, las necesidades y recursos de una startup difieren radicalmente a las de una gran corporación o las de una pyme “clásica”, y por ello, antes de tomar decisiones es necesario evaluar con calma qué se quiere lograr y los recursos con los que se cuenta. No es raro encontrar startups, en las que primero se valida una idea con una serie de recursos mínimos, por ejemplo, se desarrolla una aplicación web que corre en un servidor aislado, y si esta idea funciona, se realiza el producto con una arquitectura que cubra las necesidades de negocio.
Otro error habitual, es querer utilizar la última versión de la tecnología más novedosa del mercado, y no es raro que el realizar este tipo de decisiones implique otros problemas como falta de features, que otras soluciones ya tienen incorporadas desde hace tiempo, falta de documentación e incluso errores de la solución provocados por su falta de madurez.
Por lo tanto, aunque la idea de poner en marcha un producto haciendo uso de las últimas tecnologías y arquitecturas pueda resultar tentadora, debemos tener en cuenta tanto los recursos disponibles como optar por tecnologías que tenemos claro que funcionan y que lo hacen bien.