¿Es MACH el futuro de la arquitectura de TI? Descubre por qué los microservicios, API-first, el SaaS nativo de la nube y headless son principios de arquitectura que conviene adoptar.
Un breve recorrido por el movimiento MACH, sus principales beneficios y su probable impacto en los CTO
Las expectativas en torno al desarrollo de software se transformaron en la última década, gracias al movimiento DevOps y al auge de las tecnologías cloud y de sus proveedores, hoy omnipresentes. El cambio masivo al trabajo remoto hizo aún más urgente reducir las dependencias entre Engineers, que siempre fueron la principal causa de retrasos en los proyectos de software.
Según un nuevo estudio, los líderes tecnológicos consideran a MACH (basado en microservicios, API-first, SaaS nativo de la nube y headless) como el "futuro de la arquitectura", y un 80% planea aumentar su inversión en este enfoque durante el próximo año y los siguientes. Veamos los beneficios de estos principios de arquitectura de TI: microservicios, API-first, SaaS nativo de la nube y headless.
Microservicios
La arquitectura de microservicios parte de la premisa de que varias piezas pequeñas de software pueden generar el mismo valor que una sola pieza monolítica grande. Pero la verdadera ventaja de migrar a microservicios es el desacople del trabajo de Engineering. Ahora, cada Engineer puede concentrarse en su propio fragmento de software, en lugar de invertir cantidades enormes de tiempo coordinándose en un gran proyecto.
DoiT International es una empresa totalmente remota, así que dividir nuestros proyectos de software más grandes en piezas pequeñas que se asignan a equipos con un mínimo de coordinación tiene ventajas evidentes. No es una tarea sencilla, pero ante la exigencia de entregar valor más rápido que nunca, no hay otro camino.
API-first
La arquitectura de software API-first es prácticamente obligatoria al migrar a microservicios. De nuevo, permite que equipos pequeños o incluso minúsculos de Engineers creen piezas de software que encajan entre sí para formar un todo mayor, ya que sus colegas consumen el trabajo bajo un modelo desacoplado, tipo consumo. Para quienes no son Engineers, se explica con la analogía de una manguera: el motor de un auto tiene una entrada por donde debe ingresar el combustible, y no importa qué tipo de tanque tenga el auto, siempre y cuando el diámetro del tubo entre el tanque y el motor coincida con ambos. Así de simple se explican las APIs: el tanque lo fabrica una empresa, el motor otra, y la única coordinación necesaria es documentar el diámetro del tubo.
Software-as-a-Service nativo de la nube
El Software-as-a-Service (SaaS) nativo de la nube es otro pilar excepcionalmente importante en este nuevo mundo del desarrollo de software 100% remoto. La transición al Engineering remoto obligó a las empresas a replantearse los data centers "enjaulados" a los que solo se accedía desde la oficina y, en cambio, dejar que los Engineers trabajaran desde cualquier lugar. Una vez cruzada esa línea, cada vez más empresas que necesitaban crear software se dieron cuenta de que ya no hacía falta mantener sus propios data centers y podían apoyarse en un proveedor cloud para que se encargara de la infraestructura física.
Es lo mismo que ocurre con una fábrica: no necesita generar su propia electricidad y normalmente se la compra a una compañía eléctrica. La migración acelerada a la nube les permitió a los proveedores cloud contratar más personal y lanzar más servicios en muy poco tiempo. Y, como cada vez más tecnologías de TI tienen una versión -as-a-service en la nube, los Engineers experimentan con tecnologías mucho más rápido y a un costo mucho menor que antes.
Antes, un Engineer que quería probar una nueva base de datos tenía que pedirle a alguien que comprara el hardware, a otra persona que lo instalara en el data center y a una tercera que instalara el sistema operativo y la base de datos en ese hardware. Solo después de recibir las instrucciones de acceso podía probar la nueva base de datos. Hoy, todo eso se resuelve con un clic. La nube pasó de entregar infraestructura a entregar cualquier tecnología con un clic, lo que da una flexibilidad cada vez mayor para elegir las mejores herramientas según las necesidades de Engineering.
Headless
Headless encaja a la perfección con los microservicios y API-first. Muchas propuestas de software modernas son multi-head gracias a backends API-first. Mientras la lógica de negocio más compleja corre en la nube, los datos que esta consume o genera están disponibles a través de APIs. Así, otros equipos desacoplados de Engineers crean experiencias para web, móvil o desktop de forma independiente y con una coordinación mínima entre los equipos de frontend y backend.
La abundancia de propuestas SaaS nativas de la nube, o "tecnologías-as-a-service", permite complementar estas experiencias de frontend con tecnologías estándar gestionadas por los proveedores cloud.
El futuro de MACH
DoiT es una empresa cloud-first y 100% remota. Toda nuestra infraestructura está en la nube y nuestra única infraestructura física son las laptops que usan nuestros Engineers para aprovechar las tecnologías cloud y construir pequeñas piezas de software que se integran al gran producto de la compañía.
Hace varios años, cuando nuestro producto era mucho más pequeño, nos apoyábamos fuertemente en las tecnologías SaaS de los proveedores cloud, lo que nos permitió entregar un enorme valor a nuestros clientes con un equipo muy reducido de Engineers y en muy poco tiempo. A medida que la empresa y nuestro Engineering crecieron, tuvo sentido construir servicios adicionales como pequeños microservicios que se integran al producto principal, en lugar de acoplarlo todo en un único e inmenso desorden monolítico.
A medida que avanzamos construyendo experiencias cada vez más valiosas para nuestros clientes, tiene sentido apostar fuerte por MACH y recordarles constantemente a los Engineers por qué es tan importante para nosotros como negocio. Siempre habrá quien proponga retroceder uno o dos pasos: adoptar otra tecnología que tengamos que mantener nosotros mismos, o crear otro servicio con un fuerte acople entre frontend y backend, sin APIs de por medio. Esos movimientos solo nos frenan, así que preferimos mantener nuestras releases pequeñas, frecuentes y valiosas, y evitar atascarnos con ideas y conceptos ajenos a MACH.
Nuestra empresa no forma parte de la alianza MACH en este momento, pero celebramos el esfuerzo. Que estos conceptos ganen popularidad y aceptación en la industria solo puede traducirse en una experiencia de software mucho mejor para todos.