15 años de Adobe Experience Manager: una historia

A día de hoy, han pasado 15 años desde que Adobe finalizó la compra de Day Software, adquiriendo así el producto que todos conocen ahora como "AEM".

Para cualquiera de ustedes que (como yo) haya estado trabajando con esta plataforma durante años, esperamos que esta publicación sea un viaje entretenido (o doloroso) por el carril de la memoria para ustedes mientras revisamos por qué Adobe habría comprado Day y qué ha cambiado (¡y qué no!) en los 15 años posteriores.

Comunicado del día: antes de la adquisición de Adobe

Day Software era una empresa con sede en Basilea, Suiza, que creó su innovador Communique CMS en una plataforma basada en un sistema de archivos personalizado, pero luego se transformó en el sistema respaldado por Java Content Repository que conocemos hoy.

La primera versión de CQ fue una colección de scripts CGI para Netscape Enterprise Server (¡manos arriba si alguna vez usaste ese!) a principios de 2000, y se reescribió como una aplicación Java para CQ2 y luego el servidor HTTP se separó de él para CQ3 (la génesis de CQSE).

Hasta CQ4, el contenido todavía se almacenaba en archivos en el sistema de archivos local, pero en 2005, con el lanzamiento de CQ 4.0, se cambió del almacenamiento del sistema de archivos "Content Bus" anterior al repositorio "Content Repository eXtreme" (o CRX) versión 1.0, una evolución de la cual todavía impulsa AEM en la actualidad, 20 años completos después.

CQ5 fue una ACTUALIZACIÓN MASIVA y la base del AEM de hoy

CQ5 representó una reescritura casi completa del producto.

Hay una serie de características y enfoques que pueden parecer comunes hoy en día que fueron partes enormes y revolucionarias de la plataforma CQ5. Un encantador artículo de CMSwire de 2008 señaló: "Si bien algunos proveedores de CMS se alejan de la Web 2.0, pensando que la implosión de la Web 2.0 es inminente; Day se centra en ello a lo grande". ¿Cuántas personas de esa época podrían siquiera definir la web 2.0? Pero las enormes características nuevas lanzadas con CQ5 esencialmente la convirtieron en una plataforma completamente nueva, y la mayoría de nosotros ni siquiera podríamos imaginar un CQ / AEM sin ella, como:

• La interfaz de usuario de Sidekick & Author: la creación de GUI y WYSIWG de CQ fue un gran punto de venta en ese momento, y el hecho de que pudiera trabajar con componentes en un entorno rico en gráficos fue un gran paso adelante con respecto a otras ofertas de CMS en ese momento.

  

• Flujos de trabajo: El motor de flujo de trabajo se agregó con esta versión, que también estaba sorprendiendo a las personas, ya que podía visualizar un flujo de trabajo DIRECTAMENTE EN EL CMS y desarrollar lógica comercial directamente en su sistema de administración de contenido. Puedo imaginar que esta característica por sí sola vendió a muchos clientes empresariales al pasar al sistema

  

• CQ Tags: ¿Te imaginas trabajar en CQ sin etiquetas? La adición de compatibilidad con etiquetas finalmente trajo la taxonomía con todas las funciones a CQ.

• El DAM: CQ5 obtuvo un administrador de activos digitales con este lanzamiento, ubicado en el camino /content/dam con el que todos estamos tan familiarizados ahora. Incluso en esta era temprana, trajo el recorte y la rotación de imágenes basadas en navegador (¡no Flash!).

  

• Agrupación en clústeres: Esto es algo que solo duró hasta la versión CQ5 y no llegó a AEM6, para bien o para mal. CQ5 tenía una agrupación en clústeres bastante avanzada que permitía una configuración de agrupación activa-activa o activa-pasiva tanto para el autor como para los editores. Vi precisamente a un cliente usar la agrupación de editores, fue una idea terrible y no tengo idea de por qué lo hicieron. Sin embargo, la agrupación de autores FUE una buena "idea", lo que permitió crear teóricamente en un maestro de clúster y hacer que esas ediciones se propaguen a un esclavo de clúster (terminología que se ha retirado). La agrupación, sin embargo, siempre fue un dolor de cabeza de confiabilidad MASIVO.

• Entorno de desarrollo CRX: En ese momento, Day lanzó un entorno de desarrollo basado en Eclipse para que trabajara con el fin de tener una vista densa del lado del cliente en el repositorio de contenido de Java. También lanzaron una interfaz liviana basada en navegador que podría usarse en lugar de Eclipse llamada "CRX Development Environment Lite" o crxde, que aún sobrevive hasta el día de hoy casi exactamente en la misma forma.

No es nuevo en esta versión, pero vale la pena mencionarlo: los niveles separados de creación y publicación de CQ hicieron que las limitaciones de rendimiento o la inestabilidad en el extremo de la creación no eliminaran su sitio público, y viceversa. Tener a CQ sobre la base de OSGI y Sling significó un motor de contenido enormemente flexible, capaz tanto de respuestas dinámicas ricas como de representación de páginas, así como la capacidad de conectar el trabajo pesado en Java para todo tipo de aplicaciones que anteriormente podrían haber tenido que ejecutarse en su propia pila de servidores de aplicaciones.

Una cronología de los lanzamientos y cambios de CQ

Hasta la adquisición de Adobe, el historial de versiones de CQ era así:

• Día CQ 3.5 (2002)

• Día CQ 4.0 (2005)

• Día CQ 4.1 (2006)

• Día CQ 4.2 (2008)

• Día CQ 5.0 (2008): solo se ha publicado para clientes internos como versión preliminar

• Día CQ 5.1 (2008): primera versión de disponibilidad general de CQ5. Primera adición de flujos de trabajo, DAM, etiquetas, CRXDE, agrupación en clústeres y la barra de tareas

• Día CQ 5.2 (2009):

  • Gestión mejorada de activos digitales (DAM) con manejo de metadatos mejorado
  • Mejoras en el motor de flujo de trabajo para el procesamiento de contenido
  • Mejor integración con Adobe Analytics
  • Aquí es donde se lanzó por primera vez al mundo Multi-Site Manager (MSM).

• Día CQ 5.3 (2010)

  • Introducción de las funciones de Comunidades para la colaboración social (y, como nota, AEM 6.5 LTS solo ACABA de dejar de usar y eliminar esta funcionalidad).
  • "Site Optimizer" para pruebas A / B y multivariadas (pronto volveremos a escuchar ESE nombre)
  • Flujos de trabajo de traducción mejorados y soporte de internacionalización

La adquisición de Day Software & CQ por parte de Adobe

Adobe anunció en julio de 2010 que iban a comprar Day Software, y con él el producto CQ. Adobe ya estaba ejecutando su propio sitio web en CQ en este momento, y dado su nuevo enfoque en la construcción de una línea de negocio de tecnología de marketing, tenía sentido. Adobe acababa de adquirir Omniture en septiembre de 2009 por $ 1.8 mil millones, y Scene7 en 2007, por lo que estaba claro que Adobe estaba comenzando a tomarse en serio algo más que su negocio de software creativo.

La adquisición por parte de Adobe se completó en septiembre de 2010 por $ 240 millones de dólares en un acuerdo en efectivo, 7 veces más barato de lo que pagaron por Omniture, lo cual fue una gran ganga cuando se mira en retrospectiva.

No estoy seguro de ti, pero recuerdo exactamente dónde estaba cuando se anunció el acuerdo. Estaba en medio de la ejecución de CQ 5.2 para AARP en ese momento (habían estado en CQ desde CQ 4.2). CQ en ese momento para mí, era a partes iguales "dolor de cabeza masivo" y "¿es aquí hacia donde va CMS?" dado que todavía estábamos tratando de averiguar qué servicios deberían permanecer en JBoss y cuáles podrían ejecutarse fácilmente dentro de CQ5 ahora que CQ tenía un marco de servidor de aplicaciones Java tan robusto.

¿ PERO COMPRADO POR ADOBE AHORA? Esto cambió todas las matemáticas para mí sobre si seguir invirtiendo tiempo en aprender CQ5, porque obviamente con Adobe detrás, era probable que TUVIERA PIERNAS. ¡Y eso hizo!

La marca "Day Software" dentro de la aplicación se cambió brevemente a "Adobe CQ", aunque todo lo demás siguió igual, en su mayor parte.

• Adobe CQ 5.4 (2011)

  • Repositorio CRX2 para mejorar el rendimiento y la escalabilidad (este fue mi primer proyecto importante de CQ, una migración de repositorios que se actualizó de CQ 5.3 a 5.4)
  • Funciones sociales mejoradas y gestión de la comunidad
  • Mejores capacidades de creación móvil

• Adobe CQ 5.5 (2012)

  • Conectores a Adobe Creative Suite, Scene7 y Search&Promote
  • Creación directa de aplicaciones móviles
  • Asociación con Hybris para la integración del comercio electrónico
  • Funcionalidad Deshacer/Rehacer en el editor
  • Los fragmentos de contenido aparecieron por primera vez aquí, así como un desarrollo personalizado para un cliente con el que estaba trabajando en realidad, y luego se lanzaron como un paquete de funciones.

Cambio de marca a "Adobe Experience Manager"

Adobe sabía que esto no se llamaría "CQ" para siempre, por lo que intentaron algunos intentos abortados de cambio de marca, primero llamándolo "Adobe WCM" y luego "Web Experience Manager" por un tiempo antes de decidirse por llamarlo "Adobe Experience Manager". Fue durante la versión 5.6 cuando la pantalla de inicio de sesión cambió y ahora vio "Adobe Experience Manager" cuando inició sesión en CQ.

• AEM 5.6 (2013)

  • Se introduce TouchUI para el entorno de creación (¿cuántas aplicaciones conoce que TODAVÍA usan ClassicUI?)
  • Soporte para sitios móviles y aplicaciones
  • Personalización y orientación mejoradas
  • DAM mejorado con perfiles de vídeo

• AEM 6.0 (2014)
  AEM 6 fue una reescritura SIGNIFICATIVA de muchos de los fundamentos de AEM. Para cualquiera de nosotros en el negocio, las migraciones de CQ5 -> AEM6 ocuparon la gran mayoría de nuestro tiempo, ya que requerían MUCHA mano de obra.

  • AEM 6 cambió el repositorio subyacente de Apache Jackrabbit a Apache Oak, lo que requirió una migración a gran escala.
  • La agrupación activa-activa de CQ ya no estaba disponible, aunque Adobe introdujo el backend de almacenamiento MongoMK para AEM, que teóricamente (en este momento MUY TEÓRICAMENTE) podría proporcionar AEM Authors escalados horizontalmente. Sin embargo, tenía muchos errores y nuestra única implementación que hicimos en esto terminó en un desastre y un giro hacia un solo autor TarMK
  • Mayor huella de TouchUI para la mayoría de las páginas
  • Etiquetas inteligentes para recursos

• AEM 6.1 (2015)

  • Muchas correcciones de errores, pero la 6.1 todavía no era una versión particularmente estable.
  • La compatibilidad con URL personalizadas apareció en 6.1
  • ContextHub para la personalización
  • SDK de aplicaciones móviles
  • Se presenta AEM Communities y, junto con él, una gran cantidad de opciones de infraestructura y almacenamiento para el contenido generado por el usuario. Se harían mejoras a esto con el tiempo, pero desafortunadamente no sobrevive al cambio a Cloud Service.
  • La aplicación de escritorio AEM se lanzó para 6.1, logré 100% DDOS en un entorno de creación con esta aplicación :(

• AEM 6.2 (2016)

  • Muchas más correcciones de errores y mejoras de estabilidad, todavía no es una versión particularmente estable, pero MUCHO mejor que 6.1 o 6.0.
  • Introducción generalizada de fragmentos de contenido (antes se podía hacer a través del paquete de funciones, pero ahora es parte del producto)
  • Compatibilidad con SSL dentro de AEM
  • La interfaz de usuario cambia a cómo estamos acostumbrados ahora, con la navegación movida a la parte superior desde el carril lateral

• AEM 6.3 (2017)

  • Core Components se presenta como "listo para producción".
  • Las grandes mejoras de almacenamiento subyacentes en 6.3 finalmente hacen que esta sea la primera versión de AEM 6 muy estable. Esta fue la introducción de la datastore y segmentstore separada y un mecanismo confiable para la administración de versiones en línea (compactación de tar).
  • Se introducen fragmentos de experiencia
  • El Editor de una sola página (SPA) se introduce para aplicaciones de una sola página.
  • "Adobe Sensei" comienza a impregnar AEM Assets como la marca de IA de Adobe, con lo que eran (en ese momento) piezas bastante innovadoras de funcionalidad de IA. El recorte inteligente, el etiquetado inteligente, etc. se abrieron paso en Assets.

• AEM 6.4 (2018)

  • 6.4 fue la primera ronda de "reestructuración de repositorios" diseñada para facilitar las actualizaciones y, finalmente, allanar el camino para un cambio a Cloud Service.
  • Flujos de trabajo movidos a TouchUI
  • Varias mejoras en los servicios de traducción
  • Recorte inteligente de video en activos

• AEM 6.5 (2019)

  • Mucha reestructuración de repositorios
  • Connected Assets ofrecía una opción potencial para conectar entornos de recursos remotos a un entorno de AEM Sites independiente. Sin embargo, solo funciona para imágenes.
  • Grandes mejoras en el editor de SPA
  • GraphQL para el comercio
  • Y, dado que la versión 6.5 lleva 6 años (¡la más larga de todas las versiones de AEM/CQ hasta la fecha!), hay un montón de nuevas funciones que se han lanzado a través del Service Pack. Estamos en Service Pack 23 en este momento, y un resumen de todas las nuevas características que han salido desde 2019 merece su propia publicación de blog.

• AEM como servicio en la nube (2020)
  Se burló por primera vez en adaptTo() 2019 (¡la mayoría de nosotros no sabíamos lo que realmente estábamos viendo, en este momento!) AEM as a Cloud Service se lanzó al mundo en enero de 2020 y habría ocupado un lugar central en Adobe Summit 2020... si hubiera habido un Adobe Summit en persona en 2020. Más es la lástima. AEM as a Cloud Service se creó para resolver una serie de deficiencias de AEM y CQ desde hace mucho tiempo y ha tenido un éxito variable al hacerlo, lo que realmente ha dado como resultado el panorama de las ofertas de AEM que tenemos hoy. Lo que ofrece es:

  • Un entorno AEM completo basado en servicios en la nube
  • Escalado automático en el nivel de autor y editor
  • CDN incorporado
  • Capacidades de flujo de trabajo e ingesta de datos actualizadas masivamente con motor de ingesta de activos basado en microservicios
  • Nuevas capacidades de búsqueda, con búsqueda mejorada por IA (basada en RAG) que acaba de ser lanzada y comentada en adaptTo()

• AEM 6.5 LTS
  Con un nombre variable como "AEM 6.6" o "AEM 6.5 LTS" dependiendo de si está hablando con personal de ingeniería o marketing, 6.5 LTS es la opción a largo plazo para las personas que planean continuar autohospedando o alojando AMS sus cargas de trabajo de AEM 6.5 después de 2025. Java 11 pronto llegará al final de su vida útil, por lo que ejecutar AEM en Java 17 o Java 21 es la única opción.
  
  Este es, sin duda, el último VERDADERO SUCESOR restante del producto completo que salió en 2009, ya que muchas partes de él (es decir, /crx/packmgr y /crx/de y /etc/replication.html y así sucesivamente) son casi EXACTAMENTE iguales que en el lanzamiento original de CQ5.

• Servicios de entrega de borde y DA
  ¿Cuál es el futuro de AEM? Podría decirse que el sucesor funcional y "espiritual" de AEM para el futuro será Edge Delivery Services en el nivel de entrega y Document Authoringen el nivel de administración de contenido y habilitación de autor. Esto está absolutamente en debate, pero DA presenta un caso muy sólido para la dirección que AEM aún tomará en los próximos años.

Sobre el autor

¿Te gusta lo que escuchaste? ¿Tiene preguntas sobre lo que es adecuado para usted? ¡Nos encantaría hablar! Contáctenos

Más artículos de AEM que te pueden gustar