Las 4 creencias erradas sobre Headless
La transformación digital se consolidó en el mundo de los negocios, y esta evolución es cada vez más visible en la gestión de contenidos, razón por la que muchas empresas se ven en la necesidad migrar a arquitecturas Headless CMS en pos de mayor escalabilidad y flexibilidad en sus operaciones.
Sin ir más lejos uno de nuestros partner - Contentful - ha sido uno de los headless CMS más reconocidos en el entorno empresarial, y aún así, persisten algunas falsas creencias en torno a lo que es y no es esta manera de crear arquitectura digital.
1. Cambiar a un headless CMS requiere migrar toda la plataforma
En la web es común encontrar plataformas que basan su gestión en un CMS monolítico, donde Wordpress es el más utilizado. Estos sistemas usualmente operan con una base de datos para lectura y escritura de contenido, una interfaz para permitir la interacción con el editor y un integrador.
Por ejemplo, en la arquitectura tradicional los contenidos generados en distintos formatos (texto, imágenes, y videos) son indexados por la base de datos y convertidos en HTML y CSS.
La creencia errada nace entonces a consecuencia de la idea de que una plataforma no puede funcionar si todas las piezas del monolito no están juntas. Pero la realidad se encarga de exponer la verdad, en un Headless CMS el hub de contenidos y la capa de presentación funcionan de manera independiente, permitiendo al desarrollador acceder al contenido a través de APIs, comúnmente REST o GraphQL), sin necesitar operar una base de datos tradicional ni un servidor web clásico para gestionar cada consulta.
De hecho, una marca puede incorporar únicamente el headless CMS y mantener las demás funciones operando. Y aunque nosotros únicamente lo recomendamos para iniciar una progresión e ir modificando paulatinamente, sí es posible mantener una plataforma con esta condición, por lo que no es necesario migrar toda la plataforma.
Punto de compatibilidad para headless.
2. Desacoplar una plataforma significará perder mis datos
La segunda preocupación está relacionada a la migración de datos. Se cree que solo por migrar hacia una plataforma sin cabeza es probable perder nuestros datos, debido a la forma en que han sido indexados y procesados en el CMS monolítico.
La verdad es que esta preocupación está más basada en malas experiencias de implementación que el comportamiento del CMS. Te lo explicamos así, imagínate tienes una casa de 4 habitaciones pero solo vives tú y tomaste la decisión de transformarla, la parte delantera quieres que sea un local comercial y lo demás seguirá siendo tu casa, pero más ajustada a tus necesidades.
¿Solo compras materiales y construyes?, claro, si eres un constructor experto quizás podrías enfrentar el desafío, pero para quienes no lo son hay muchos aspectos a resolver antes de poner el primer tornillo: distribución, materiales, conexiones y, por supuesto, mover todo lo que está adentro de ella (datos).
Buscas los mejores materiales, proteges y mueves tus muebles, proyectas lo que construirás, el orden de integraciones y, por supuesto, consigues a los expertos que te ayudarán. Lo mismo ocurre en headless, todo se basa en la planificación: cuando se emplean las estrategias correctas de la mano de expertos, la construcción se transforma en una obra maestra.
Punto de estrategia para headless.
3. El gasto en servicios en la nube será abrumador
Dentro de los equipos de desarrollo habituados al monolito esta creencia es muy común; pensar que al trabajar desde una plataforma headless implicará pagar a múltiples proveedores de servicios aumentando el gasto asociado a la plataforma de manera desproporcionada.
Esto podría ser cierto, si es que en headless las empresas trabajaran como lo hacían los proveedores de soluciones monolíticas. Es decir, tener que contratar altas capacidades por adelantado y múltiples funcionalidades que no necesariamente vamos a utilizar pero que vienen integradas en el sistema.
Pero los costos de los servicios en la nube operan bajo la modalidad on-demand, lo que significa que solo se paga por los recursos utilizados. Esta condición de facturación por demanda reduce considerablemente el gasto asociado a servidores y recursos informáticos que tradicionalmente se contrataban por adelantado (capacidad rígida).
Además, en los servicios cloud la responsabilidad de que los servidores respondan a la demanda recae en el proveedor de servicios, lo que implica un menor gasto en mantención de infraestructura por una parte, y por otra una mayor libertad en la capacidad de los desarrolladores.
Los servicios en la nube funcionan con una estructura de datos independiente y mucho más específica, permitiendo realizar acciones y tareas puntuales y por ende, menos costosas que adquirir una solución completa, tal como sucede en los monolitos.
4. Con headless perdemos el control de nuestra plataforma
En más de una oportunidad clientes manifestaron una profunda preocupación por el control sobre la plataforma. A su forma de entenderlo, delegar funciones implicaría no poder tomar decisiones sobre cómo deberían operar. Y esto es categóricamente falso.
Uno de los mayores beneficios de headless es que nos permite diferenciar los elementos que conforman la experiencia de la parte operativa. Y por el contrario a lo que piensan algunos, cada módulo representa mayor autonomía y eficiencia operacional. Ya que cada servicio se integra en la medida de las necesidades de cada marca, no son los proveedores quienes deciden cómo operar ¿en qué mundo eso sería un modelo de negocios rentable?
Headless nos otorga un mayor control de cómo construir y operar nuestras plataformas, sobre todo porque podemos utilizar únicamente las integraciones que realmente necesitemos, dejando fuera del sistema todo lo innecesario, lo que libera recursos, libera tiempo y capacidades.
Al ser integraciones autocontenidas, en el fondo diferenciamos cada componente de la experiencia. En este contexto, es posible integrar sitios web estáticos con el uso de arquitecturas Serverless como JAMstack y permitir a una operatividad ágil y segura. Al delegar la gestión de la infraestructura al proveedor de servicios, también accedemos a mayor seguridad frente a posibles caídas del servidor o ataques cibernéticos.
Punto de autonomía para headless.
Headless prepara a las plataformas para los desafíos digitales
En Estados Unidos, para el año 2022 se estima un crecimiento de las ventas a través de canales digitales de un 16.1%, ascendiendo a un total de 1.06 billones de dólares. Es por esto que debemos ofrecer servicios guiados por una experiencia de usuario en donde nuestros clientes se sientan entendidos.
Al implementar arquitecturas Headless contamos con la posibilidad de desarrollar estrategias omnicanal y ofrecer mayor portabilidad a nuestros clientes. Actualmente, no solo se trata de aparecer en canales digitales, sino también de cómo presentamos nuestro servicio al cliente y la forma en que estos nos perciben.
En un Headless CMS debemos tomar en cuenta algunas acciones claves al momento de realizar la migración. En muchos casos, el proceso de conversión de datos, la falta de una estrategia de contenidos y la estructura de almacenamiento de contenidos pueden obstaculizar la migración. Sin embargo, disponer de un equipo de expertos como Reign permite realizar una transición exitosa a esta arquitectura.
Para nosotros en Reign, implementar Headless es impulsar a las marcas mediante plataformas y metodologías flexibles, constituye la apertura hacia una mayor libertad en la construcción de la arquitectura web para las empresas, proporcionando una mejor experiencia digital al cliente.