Tecnología MACH explicada a profesionales de negocio

Hace un par de años que en publicaciones y conferencias escuchamos sobre cómo soluciones basadas en arquitectura MACH son el nuevo paradigma y cambio disruptivo en el sector de soluciones tecnológicas. Las tecnologías MACH (pronunciado mac, como la velocidad del sonido, mach1, mach2…) están haciendo ruido. 

Durante el año pasado, vendors MACH han conseguido 2,5 mil millones de dólares en financiación, un volumen que por sí solo supera al que han recibido enteras ciudades como Madrid o Barcelona en el sector de startups durante el mismo año y acumulan en global una valoración de 20 mil millones de dólares (fuente MACH Alliance). Algo grande está pasando en este sector, y no se trata de una moda pasajera. 

Entre las soluciones MACH encontramos principalmente a eCommerce y gestores de contenido (CMS), pero también hay soluciones PIM, sistemas de búsqueda, herramientas de integración y cada día son más las soluciones que se suman a esta nueva filosofía cuyas virtudes no son siempre tan simples de comprender.

¿Qué significa MACH?

El acrónimo MACH hace referencia a conceptos tecnológicos, lo que puede dificultar la comprensión para alguien de negocio que necesita entender qué diferencia hay entre una solución MACH y una no MACH. Vamos a explicar aquí debajo MACH de la M a la H poniendo foco en cómo se diferencia del resto de soluciones y, sobre todo, qué nos aporta a nuestro negocio. 

M de Microservicios

Los Microservicios hacen referencia a una manera de desarrollar soluciones compuesta por una larga colección de pequeñas soluciones independientes con un cometido único y que se comunican entre ellas. Por ejemplo, un software de eCommerce MACH tiene un microservicio para añadir líneas de producto a un pedido, otro para controlar la disponibilidad del producto, otro para calcular los gastos de envío.  

¿Cuándo no es microservicio? En un sistema que no esté construido con microservicios, las funcionalidades están enredadas y son altamente dependientes unas de otras. Modificar una pieza del software significa alterar todo el conjunto de software. 

Qué me aporta. Directamente no mucho, la verdad. La principal ventaja (hay más) de los microservicios es lo eficiente y mantenible que es el software. Si contratas un software que utiliza microservicios puedes asumir que evolucionará de manera rápida y ágil. Pero lo realmente interesante de los Microservicios viene con el siguiente punto. 

A de API First

Las APIs (por cierto, otro acrónimo, ¡inception!) son funciones que cumplen un estándar de comunicación, es decir, que cualquiera al que se le dé permiso puede utilizarlas. Si a cada uno de los microservicios que comentamos arriba, se les provee por defecto de un estándar de comunicación (de ahí el First), esto permite que piezas de software diferentes puedan interactuar entre ellas a cualquier nivel de detalle. 

¿Cuándo no es API first? Cuando tengo que descargar un Excel de un software para volver a importarlo en otro, cuando tengo que dejar un CSV en una carpeta para que otro software lo procese, o cuando tengo que manualmente replicar información entre aplicaciones, es probable que esté usando aplicaciones que no son API first. 

Qué me aporta. Si alguna vez has usado herramientas como Zapier ya intuyes de qué va esto. También puede que integraras el formulario de tu web con MailChimp o con tu CRM. Esa conexión ha sido posible porque ambas herramientas disponen de APIs. Ahora imagina esta funcionalidad, pero a cualquier nivel de detalle entre todas tus aplicaciones empresariales… las opciones son infinitas. Podemos tener nuestro eCommerce B2B que se alimente de los productos del PIM que a su vez los saca del ERP, que personalice el contenido usando un software específico que se nutra de tu CRM y que y muestre la configuración de productos sacándola de tu CPQ. Esta característica la verás a menudo descrita como composable, acompañada de la metáfora de construir soluciones como si de piezas de Lego se tratara.  

Las ventajas del composable no solo está en los datos que viajan entre aplicaciones de manera precisa en tiempo real, sino que en cualquier momento podemos descomponer nuestra aplicación reemplazando una parte por otra sin afectar el todo. Algo que nos garantiza una evolución orgánica que de nuestras soluciones digitales que pueden crecer de manera aislada. Nunca más oiremos “es que, si cambiamos la web, hay que cambiar el eCommerce, y si cambiamos el eCommerce hay que cambiar el sistema de emailing, y si… ” 

C de Cloud based SaaS

Cloud ya sabemos todos que es y SaaS (de Software as a Service, ¡otro acrónimo más!) también, aunque no necesariamente con este nombre. Un software SaaS es uno al que nos conectamos normalmente por navegador y del que nos despreocupamos totalmente por sus servidores, mantenimiento y actualizaciones. Salesforce fue quien introdujo el concepto (que intentaron acuñar sin suerte como no-software). Muchas otras herramientas que usamos a diario como Gmail, HubSpot o MailChimp también son SaaS 

¿Cuándo no es Cloud based SaaS? Si lo tienes que instalar, como Outlook en su versión de escritorio, si tienes que descargarte actualizaciones, como en Spotify, o si tienes que instalar y mantener servidores, como Jira en su versión on premise, entonces no tienes un sistema SaaS.  

Qué me aporta. Desaparecen todos los incordios de arriba. Se acabaron las instalaciones, se acabaron las versiones, se acabaron los mantenimientos. Se acabaron también, y esta es uno de los aspectos más importantes, las complejidades de gestión de servidores, equipos de guardia, gestión de alta disponibilidad o réplica geográfica de infraestructura. Las cosas funcionan, sin más. 

H de Headless

La cabeza (head) en desarrollo de aplicaciones hace referencia a la parte visual, a la interfaz de usuario con la que operamos. Una aplicación Headless no se refiere a que no tenga interfaz de usuario, sino que la interfaz y la parte de datos están completamente desacopladas. Una descripción un poco más técnica que escucharás es que back-end y front-end están completamente desacoplados. 

Así como arriba contábamos sobre aplicaciones que se conectaban entre ellas mediante APIs, aquí sucede algo muy parecido, y se trata de que la parte visual de nuestra aplicación se conecta por API a la parte de lógica de negocio y de datos.  

¿Cuándo no es Headless? Si tienes WordPress, por ejemplo, no tienes una aplicación Headless (puede haber excepciones), esto significa que para realizar cambios en la parte visual (o de front-end) pueden que tengamos que realizar cambios también en la parte de back-end. 

Qué me aporta. Si tu web estuviese desarrollada de manera completamente Headless, podrías cambiar por completo el CMS manteniendo toda la parte visual, por lo que ganas en flexibilidad. 

Rendimiento es otra gran ventaja, ya que se descarga mucho trabajo de parte del servidor y es más simple también distribuir geográficamente tu aplicación, es decir, que tus usuarios se conecten al servidor que tienen más cercano. Por último, la seguridad aumenta también ya que las partes más críticas de la web (las partes de back-end) están más aisladas y solo dejamos acceder a aquello que ya es público, como imágenes y recursos estáticos. 

¿Qué es entonces un ecosistema MACH?

Resumiendo, muy brevemente, un ecosistema MACH, como hemos visto arriba, te ayuda a mejorar aspectos como velocidad y seguridad, te facilita cosas que antes no podías, como tener datos en tiempo real y evolucionar tus aplicaciones de manera separada y te quita dolores de cabeza de gestión de servidores y actualizaciones. 

En Novicell, como miembros de la MACH Alliance, estamos encantados de ser parte de este cambio de paradigma y nos comprometemos a difundir los beneficios de este tipo de tecnología. Si quieres saber más sobre cómo tu empresa puede beneficiarse de estas tecnologías ponte en contacto con nosotros. 

¿Cómo podemos ayudarte?

Si necesitas más información no dudes en ponerte en contacto con nosotros.