15 anos do Adobe Experience Manager - Uma história

Hoje completam-se 15 anos desde que a Adobe finalizou a compra da Day Software, adquirindo assim o produto que todos vocês conhecem agora como "AEM".

Para todos vocês que (como eu) trabalham com esta plataforma há anos, espero que este post seja uma viagem nostálgica (ou até dolorosa) ao passado, enquanto relembramos por que a Adobe teria comprado a Day e o que mudou (e o que não mudou!) nesses 15 anos.

Comunicado do dia - antes da aquisição pela Adobe

A Day Software era uma empresa sediada em Basileia, na Suíça, que criou o inovador CMS Communique numa plataforma personalizada baseada em sistema de arquivos, mas que mais tarde se transformou no sistema baseado em repositório de conteúdo Java que conhecemos hoje.

A primeira versão do CQ era uma coleção de scripts CGI para o Netscape Enterprise Server (quem já usou esse servidor?), no início dos anos 2000, e foi reescrita como um aplicativo Java para o CQ2. Posteriormente, o servidor HTTP foi separado para o CQ3 (a gênese do CQSE).

Até o CQ4, o conteúdo ainda era armazenado em arquivos no sistema de arquivos local, mas em 2005, com o lançamento do CQ 4.0, houve a mudança do antigo armazenamento em sistema de arquivos "Content Bus" para o repositório "Content Repository eXtreme" (ou CRX) versão 1.0, uma evolução do qual ainda alimenta o AEM hoje - 20 anos depois.

O CQ5 foi uma ATUALIZAÇÃO ENORME e a base do AEM de hoje.

O CQ5 representou uma reescrita quase completa do produto.

Existem diversas funcionalidades e abordagens que podem parecer comuns hoje em dia, mas que foram partes enormes e revolucionárias da plataforma CQ5. Um artigo encantador da CMSwire de 2008 observou: "Enquanto alguns fornecedores de CMS evitam a Web 2.0, pensando que a implosão da Web 2.0 é iminente, Day se concentra nisso intensamente". Quantas pessoas daquela época seriam capazes de definir o que era a Web 2.0? Mas os novos e importantes recursos lançados com o CQ5 essencialmente o transformaram em uma plataforma completamente nova, e a maioria de nós nem consegue imaginar um CQ/AEM sem ele, como:

• A interface Sidekick e Author: a interface gráfica e o editor WYSIWYG do CQ foram um grande diferencial na época, e o fato de poder trabalhar com componentes em um ambiente rico em gráficos representou um enorme avanço em relação a outras ofertas de CMS disponíveis naquele período.

  

• Fluxos de trabalho: O mecanismo de fluxo de trabalho foi adicionado nesta versão e impressionou a todos, pois permitia visualizar um fluxo de trabalho DIRETAMENTE NO CMS e desenvolver a lógica de negócios diretamente no sistema de gerenciamento de conteúdo. Imagino que só essa funcionalidade tenha convencido muitos clientes corporativos a migrar para o sistema.

  

• Etiquetas CQ: Você consegue imaginar trabalhar no CQ sem etiquetas? A adição do suporte a tags finalmente trouxe a taxonomia completa para o CQ.

• O DAM: CQ5 recebeu um gerenciador de ativos digitais nesta versão, localizado no caminho /content/dam com o qual todos já estamos tão familiarizados. Mesmo nessa época inicial, já permitia recortar e girar imagens usando o navegador (e não Flash!).

  

• Clustering: Isso é algo que durou apenas até o lançamento do CQ5 e não chegou ao AEM6, para o bem ou para o mal. O CQ5 possuía um sistema de agrupamento bastante avançado, que permitia uma configuração de agrupamento ativo-ativo ou ativo-passivo tanto para autores quanto para editores. Vi apenas um cliente usar o agrupamento de Publishers, foi uma péssima ideia e não faço ideia do porquê de terem feito isso. O agrupamento de autores ERA, no entanto, uma boa "ideia", permitindo que, teoricamente, alguém criasse conteúdo em um servidor mestre do cluster e que essas edições fossem propagadas para um servidor escravo (terminologia que já foi descontinuada). No entanto, o agrupamento sempre foi um problema ENORME de confiabilidade.

• Ambiente de Desenvolvimento CRX: Na época, Day lançou um ambiente de desenvolvimento baseado no Eclipse para que você pudesse trabalhar e ter uma visão completa do Repositório de Conteúdo Java do lado do cliente. Eles também lançaram uma interface leve baseada em navegador que podia ser usada em vez do Eclipse, chamada "CRX Development Environment Lite" ou crxde, que ainda existe até hoje praticamente da mesma forma.

Embora não seja uma novidade nesta versão, vale a pena mencionar: os níveis separados de autoria e publicação do CQ permitiam que restrições de desempenho ou instabilidade no lado da autoria não derrubassem seu site público, e vice-versa. O fato de o CQ estar baseado nos fundamentos do OSGi e do Sling significava um mecanismo de conteúdo extremamente flexível, capaz tanto de respostas dinâmicas complexas quanto de renderização de páginas, além da possibilidade de integrar funcionalidades complexas em Java para todos os tipos de aplicações que antes precisariam ser executadas em seus próprios servidores de aplicação.

Cronologia dos lançamentos e alterações do CQ

Até a aquisição pela Adobe, o histórico de versões do CQ era o seguinte:

• Dia CQ 3.5 (2002)

• Dia CQ 4.0 (2005)

• Dia CQ 4.1 (2006)

• Dia CQ 4.2 (2008)

• Day CQ 5.0 (2008) - lançado apenas para clientes internos como versão prévia.

• Day CQ 5.1 (2008) - primeira versão de disponibilidade geral do CQ5. Primeira adição de Workflows, DAM, Tags, CRXDE, Clustering e Sidekick.

• Dia CQ 5.2 (2009):

  • Gestão de Ativos Digitais (DAM) aprimorada com melhor tratamento de metadados.
  • Melhorias no mecanismo de fluxo de trabalho para processamento de conteúdo.
  • Melhor integração com o Adobe Analytics.
  • Foi aqui que o Multi-Site Manager (MSM) foi lançado ao mundo pela primeira vez.

• Dia CQ 5.3 (2010)

  • Introdução dos recursos de Comunidades para colaboração social (e vale ressaltar que somente o AEM 6.5 LTS acaba de descontinuar e remover essa funcionalidade!).
  • "Site Optimizer" para testes A/B e multivariados (ouviremos esse nome novamente em breve)
  • Fluxos de trabalho de tradução aprimorados e suporte à internacionalização

A aquisição da Day Software e da CQ pela Adobe

Em julho de 2010, a Adobe anunciou que iria comprar a Day Software e, com ela, o produto CQ. A Adobe já tinha seu próprio site no CQ nessa época e, considerando seu novo foco em desenvolver uma linha de negócios de tecnologia de marketing, fazia sentido. A Adobe havia acabado de adquirir a Omniture em setembro de 2009 por US$ 1,8 bilhão e a Scene7 em 2007 – portanto, era evidente que a Adobe estava começando a levar a sério algo além de seu negócio de software criativo.

A aquisição pela Adobe foi concluída em setembro de 2010 por 240 milhões de dólares em uma transação totalmente em dinheiro, 7 vezes mais barata do que a empresa pagou pela Omniture - o que, em retrospectiva, foi uma verdadeira pechincha.

Não sei quanto a vocês, mas eu me lembro exatamente onde estava quando o acordo foi anunciado. Eu estava no meio da transmissão do CQ 5.2 para a AARP na época (eles estavam no CQ desde o CQ 4.2). Naquela época, para mim, o CQ era uma mistura de "grande dor de cabeça" e "será que é para isso que o CMS está caminhando?". Considerando que ainda estávamos tentando descobrir quais serviços deveriam permanecer no JBoss e quais poderiam ser executados com a mesma facilidade no CQ5, agora que o CQ possuía uma estrutura de servidor de aplicativos Java tão robusta.

Mas AGORA FOI COMPRADO PELA ADOBE?? Isso mudou completamente minha perspectiva sobre se deveria ou não continuar investindo tempo aprendendo CQ5, porque, obviamente, com a Adobe por trás, era provável que tivesse potencial para se consolidar. E funcionou mesmo!

A marca "Day Software" dentro do aplicativo foi alterada pouco depois para "Adobe CQ", embora todo o resto tenha permanecido praticamente igual.

• Adobe CQ 5.4 (2011)

  • Repositório CRX2 para melhor desempenho e escalabilidade (este foi meu primeiro grande projeto em CQ, uma migração de repositório atualizando do CQ 5.3 para o 5.4)
  • Funcionalidades sociais aprimoradas e gestão de comunidades
  • Recursos aprimorados de autoria móvel

• Adobe CQ 5.5 (2012)

  • Conectores para Adobe Creative Suite, Scene7 e Search&Promote
  • Criação direta de aplicativos móveis
  • Parceria com a Hybris para integração de comércio eletrônico
  • Funcionalidade de desfazer/refazer no editor
  • Os Fragmentos de Conteúdo surgiram pela primeira vez aqui, como um desenvolvimento personalizado para um cliente com quem eu estava trabalhando, e posteriormente foram lançados como um pacote de recursos.

Renomeação para "Adobe Experience Manager"

A Adobe sabia que o nome "CQ" não duraria para sempre, então tentou algumas mudanças de marca que acabaram não dando certo, primeiro chamando-o de "Adobe WCM" e depois de "Web Experience Manager" por um tempo, antes de finalmente optar por "Adobe Experience Manager". Foi durante o lançamento da versão 5.6 que a tela de login mudou, e agora você via "Adobe Experience Manager" ao entrar no CQ.

• AEM 5.6 (2013)

  • A TouchUI foi introduzida para o ambiente de desenvolvimento (quantos aplicativos VOCÊ conhece que AINDA usam a ClassicUI?)
  • Suporte para sites e aplicativos móveis
  • Personalização e segmentação aprimoradas
  • DAM aprimorado com perfis de vídeo

• AEM 6.0 (2014)
  O AEM 6 representou uma reescrita SIGNIFICATIVA de muitos dos fundamentos do AEM. Para qualquer um de nós na área, as migrações de CQ5 para AEM6 consumiam a maior parte do nosso tempo, pois eram MUITO trabalhosas.

  • O AEM 6 substituiu o repositório subjacente do Apache Jackrabbit pelo Apache Oak, exigindo uma migração em larga escala.
  • O cluster ativo-ativo do CQ não estava mais disponível, embora a Adobe tenha introduzido o backend de armazenamento MongoMK para AEM, que teoricamente (naquele momento, MUITO TEORICAMENTE) poderia fornecer AEM Authors com escalabilidade horizontal. No entanto, era extremamente instável e a única implementação que fizemos terminou em desastre, resultando em uma mudança para o TarMK de autor único.
  • Maior presença do TouchUI na maioria das páginas.
  • Etiquetas inteligentes para ativos

• AEM 6.1 (2015)

  • Muitas correções de bugs, mas a versão 6.1 ainda não era particularmente estável.
  • O suporte para URLs personalizadas surgiu na versão 6.1.
  • ContextHub para personalização
  • SDK para Aplicativos Móveis
  • O AEM Communities foi lançado e, juntamente com ele, uma série de opções de infraestrutura e armazenamento para conteúdo gerado pelo usuário. Melhorias seriam feitas com o tempo, mas infelizmente isso não sobrevive à migração para o serviço em nuvem.
  • O aplicativo AEM Desktop foi lançado para a versão 6.1 e eu consegui realizar um ataque DDoS de 100% em um ambiente de produção com esse aplicativo :(

• AEM 6.2 (2016)

  • Muitas outras correções de bugs e melhorias de estabilidade - ainda não é uma versão particularmente estável, mas MUITO melhor que a 6.1 ou a 6.0.
  • Introdução de fragmentos de conteúdo generalizados (antes isso podia ser feito por meio de um pacote de recursos, mas agora faz parte do produto).
  • Suporte SSL dentro do AEM
  • Alterações na interface do usuário para o formato que já conhecemos — com a barra de navegação movida da lateral para o topo, em vez de ficar na parte superior.

• AEM 6.3 (2017)

  • O Core Components é apresentado como "pronto para produção".
  • As grandes melhorias no armazenamento subjacente da versão 6.3 finalmente fazem desta a primeira versão do AEM 6 muito estável. Esta foi a introdução dos caracteres separados datastore e segmentstore e de um mecanismo confiável para gerenciamento de versões online (compactação tar).
  • São introduzidos fragmentos de experiência.
  • O Single Page Editor (SPA) foi introduzido para aplicativos de página única.
  • O conceito "Adobe Sensei" começa a permear o AEM Assets como a marca de IA da Adobe, com funcionalidades de IA que eram (na época) bastante inovadoras. Recursos como recorte inteligente, marcação inteligente, etc., foram incorporados ao Assets.

• AEM 6.4 (2018)

  • A versão 6.4 foi a primeira rodada de "reestruturação do repositório", projetada para facilitar as atualizações e, eventualmente, abrir caminho para a migração para o Serviço em Nuvem.
  • Os fluxos de trabalho foram migrados para a TouchUI.
  • Diversas melhorias nos serviços de tradução
  • Recorte inteligente de vídeo em ativos

• AEM 6.5 (2019)

  • Muita reestruturação de repositórios
  • Os Ativos Conectados ofereciam uma opção potencial para conectar ambientes de ativos remotos a um ambiente AEM Sites separado. Só funciona com imagens.
  • Grandes melhorias no editor de SPA
  • GraphQL para comércio
  • E, como a versão 6.5 já está ativa há 6 anos (a mais longa de qualquer versão do AEM/CQ até hoje!), há uma infinidade de novos recursos lançados por meio de pacotes de serviço. Neste momento, estamos no Service Pack 23, e um resumo de todos os novos recursos lançados desde 2019 merece um post próprio no blog.

• AEM como um serviço em nuvem (2020)
  Apresentado pela primeira vez no adaptTo() 2019 (naquela época, a maioria de nós não sabia exatamente o que estava vendo!). O AEM como um serviço em nuvem foi lançado mundialmente em janeiro de 2020 e teria sido o destaque do Adobe Summit 2020... se o evento presencial do Adobe Summit tivesse acontecido em 2020. É uma pena. O AEM como um serviço em nuvem foi criado para resolver uma série de deficiências antigas do AEM e do CQ e teve sucesso variável nesse sentido, resultando, na realidade, no cenário de ofertas do AEM que temos hoje. O que oferece é:

  • Um ambiente AEM completo baseado em serviços na nuvem.
  • Dimensionamento automático nos níveis de autor e editor
  • CDN integrada
  • Fluxos de trabalho e recursos de ingestão de dados amplamente atualizados com um mecanismo de ingestão de ativos baseado em microsserviços.
  • Novas funcionalidades de busca, com busca aprimorada por IA (baseada em RAG), acabaram de ser lançadas e foram discutidas no adaptTo().

• AEM 6.5 LTS
  Com nomes variados, como "AEM 6.6" ou "AEM 6.5 LTS", dependendo se você está falando com o pessoal de engenharia ou de marketing, o 6.5 LTS é a opção de longo prazo para quem planeja continuar hospedando suas cargas de trabalho do AEM 6.5 por conta própria ou na AMS após 2025. O Java 11 está prestes a chegar ao fim de sua vida útil, portanto, executar o AEM no Java 17 ou no Java 21 é a única opção.
  
  Este é, sem dúvida, o último VERDADEIRO SUCESSOR do produto completo lançado em 2009, já que muitas partes dele (ou seja, /crx/packmgr e /crx/de e /etc/replication.html e assim por diante) são quase EXATAMENTE iguais a como eram no lançamento original do CQ5.

• Serviços de entrega Edge e DA
  Qual é o futuro do AEM? Pode-se argumentar que o sucessor funcional e "espiritual" do AEM para o futuro será o Edge Delivery Services na camada de entrega e a Criação de Documentosna camada de gerenciamento de conteúdo e habilitação de autoria. Isso é absolutamente discutível, mas DA apresenta argumentos muito convincentes sobre a direção que a AEM tomará nos próximos anos.

Sobre o autor

Gostou do que ouviu? Tem dúvidas sobre o que é certo para você? Adoraríamos conversar! Entre em contato conosco

Mais artigos sobre AEM que você pode gostar