Nesta fase da Jornada de Migração as a Cloud Service AEM, você se familiarizará com o AEM as a Cloud Service, revisará as alterações notáveis que introduziu e entenderá o que é necessário para planejar uma migração bem-sucedida para a nuvem.
O documento anterior, Introdução à migração para o AEM as a Cloud ServiceO descreve uma lista de fases que você precisa seguir para migrar para o AEM as a Cloud Service, bem como os benefícios de fazer isso.
Este documento ajuda você a entender quais fatores devem ser considerados para garantir que a instalação do AEM esteja pronta para ser movida para a nuvem:
O AEM as a Cloud Service oferece muitos novos recursos e possibilidades para gerenciar seus projetos do AEM.
Juntamente com essas melhorias, foram introduzidas várias diferenças entre as instalações locais do AEM e do Adobe Managed Services, em comparação com o AEM as a Cloud Service.
A lista de itens na tabela abaixo é o subconjunto das alterações mais relevantes para uma migração para o AEM as a Cloud Service. Você pode consultar a lista completa de alterações importantes aqui.
O que mudou? | Referência | Principais pontos |
---|---|---|
Separe filtros mutáveis e imutáveis em pacotes correspondentes | Mudanças notáveis as a Cloud Service do AEM Estrutura de projeto do AEM para o AEM as a Cloud Service |
Um único pacote que pode ser implantado no AEM as a Cloud Service pode ter pacotes secundários, principalmente para conter conteúdo mutável e imutável separado em seus próprios pacotes. |
Inicialização do repositório | Documentação do Apache Sling RepoInit | Os scripts de repoinit são a prática recomendada para criar qualquer estrutura de nó inicial, usuário, grupo ou usuário de serviço. Como esses scripts podem ser direcionados pelo modo de execução e gerenciados por meio da implantação de pacotes de códigos, eles fornecem muita flexibilidade para realizar tarefas de inicialização de repositório. |
Modos de execução personalizados não são permitidos | Somente os modos de execução fornecidos imediatamente com o AEM as a Cloud Service são suportados. Quando ambientes de desenvolvimento adicionais são adicionados, todos eles se vinculam ao modo de execução "dev". |
|
A execução do pipeline do Cloud Manager é a única maneira de implantar | No AEM as a Cloud Service, o acesso a /system/console não é permitido, portanto, todas as configurações de OSGi devem fazer parte do código e devem ser implantadas como código. As configurações do OSGi estão disponíveis no modo somente leitura para visualização no Console do desenvolvedor por meio do Cloud Manager |
|
Os agentes de replicação são substituídos pelo Sling Content Distribution | O conceito do agente de replicação é substituído por Sing Content Distribution. Se houver personalizações aproveitando agentes de replicação, elas deverão ser reprojetadas. A replicação reversa não é suportada |
|
CRX/DE e Gerenciador de pacotes | O CRX/DE é permitido somente no ambiente de desenvolvimento. O Gerenciador de pacotes pode ser acessado em todas as instâncias de autor, mas os pacotes que serão implantados devem conter somente conteúdo mutável ( por exemplo: /content ou /conf) |
|
CDN integrada e Obter seu próprio CDN | O AEM as a Cloud Service inclui a CDN para todos os ambientes, que é otimizada para a maioria dos casos de uso. Se quiser configurar seu próprio CDN, você deve enviar uma solicitação ao Suporte do Adobe para que ele seja aprovado. Se for aprovado, o CDN apontará para o Fastly e não para instâncias do AEM em nenhum ambiente. |
|
Trabalhos de Longa Execução | Evite executar tarefas de longa duração, como Sling Schedulers ou tarefas do Cron, já que as instâncias do AEM em execução nos contêineres podem ir e vir a qualquer momento. Repense essas funcionalidades para transferi-las para o Adobe I/O. |
|
Alternar para operações assíncronas | Configurar operações assíncronas | Para melhorar o desempenho geral de seus ambientes, determinadas operações são executadas no modo assíncrono. Os trabalhos assíncronos serão enfileirados e executados quando os recursos do sistema estiverem disponíveis. |
Estratégias de autenticação e integração baseadas em token | Geração de tokens de acesso para APIs do lado do servidor Tutorial de autenticação baseada em token |
É comum que sistemas externos ao AEM estejam tentando executar operações HTTP dentro do AEM. A abordagem recomendada é implementar as estratégias descritas aqui, em vez de depender da criação de nomes de usuários locais com senhas no AEM. |
Uso de E/S de arquivo/disco | Como não há garantia de quanto espaço em disco é alocado e as instâncias em contêineres vêm e vão, não é aconselhável usar as operações de E/S de arquivo para gravar ou ler o disco anexado à instância do AEM. | |
Fluxo de trabalho do Ativo de atualização DAM | Serviço Asset compute | As etapas de processamento de mídia que fazem parte do fluxo de trabalho Atualizar ativo do DAM agora são substituídas pelo Serviço do Asset compute |
Métodos de upload de ativos e etapas do processo de fluxo de trabalho compatíveis no AEM as a Cloud Service | Fazer upload de comparações de API e etapas do processo WF compatíveis | No AEM as a Cloud Service, durante o upload ou o download de um ativo, o ativo flui diretamente para dentro ou para fora do armazenamento binário.Nem todas as etapas do processo de fluxo de trabalho são compatíveis com o AEMaaCS. |
Inicializadores do fluxo de trabalho | Remova todos os Iniciadores de fluxo de trabalho que estão acionando o fluxo de trabalho do ativo de atualização do DAM personalizado ou OOTB do seu código.Todos os ativos carregados no AEM as a Cloud Service serão processados pelo Serviço de processamento de ativos. Para obter etapas personalizadas, consulte Fluxos de trabalho de pós processamento sobre como configurar fluxos de trabalho de pós-processamento. | |
Etapas de representação personalizadas | Processando perfis | Qualquer geração de representação personalizada, conversões de imagem ou codificações de vídeo devem ser descarregadas no Serviço de processamento de ativos, criando perfis de processamento correspondentes. |
Pesquisa e indexação de conteúdo | Alterações de pesquisa e indexação de conteúdo | Há alterações consideráveis no processamento subjacente de índices e no momento em que ele é iniciado. Compreenda e refatore completamente os índices do Oak antes de gerenciá-los no código que você implantará. |
Nem todas as tarefas de manutenção são configuráveis | Tarefas de manutenção as a Cloud Service do AEM | Você pode configurar apenas determinadas tarefas de manutenção com o AEM as a Cloud Service. |
Alterações no repositório de publicação | Não são permitidas alterações diretas no repositório de publicação, exceto aquelas em /home. É sempre recomendável fazer as alterações no autor e distribuí-las. Todas as alterações de código e configuração devem ser implantadas por meio do pipeline correspondente do Cloud Manager. | |
Configurações e armazenamento em cache do Dispatcher | Dispatcher na nuvem Gerenciamento de cache |
As configurações do Dispatcher devem seguir uma estrutura específica. As configurações devem ser gerenciadas como parte do código e implantadas por meio do pipeline do Cloud Manager. |
Backup e restauração | Backup e restauração as a Cloud Service do AEM | |
Alterações na autenticação | Suporte IMS do AEM as a Cloud Service | Se você estava usando anteriormente a integração SAML 2.0 no Author e no publish antes de migrar para o Cloud Service, a principal alteração é que o AEM as a Cloud Service Author só se integra ao Adobe IMS. No entanto, o nível de publicação as a Cloud Service do AEM ainda pode aproveitar o SAML ou outras integrações de autenticação. O AEM as a Cloud Service oferece suporte à autenticação do IMS somente para os usuários Autor, Administrador e Desenvolvimento. A autenticação IMS não oferece suporte para usuários finais externos de sites do cliente, como visitantes do site. |
A Adobe avalia as funcionalidades do produto constantemente, para reinventar ou substituir recursos mais antigos por alternativas mais modernas, de forma a melhorar o valor do cliente em geral, sempre sob considerações cuidadosas de compatibilidade com versões anteriores.
Recomendamos que você consulte o Recursos obsoletos para se familiarizar com os recursos e funcionalidades que foram marcados como obsoletos no Experience Manager as a Cloud Service e ver qual é o impacto para sua implantação do AEM.
Depois de se familiarizar com as alterações introduzidas com o AEM as a Cloud Service, é hora de começar a planejar uma revisão de sua instalação existente, a fim de medir o nível de alterações necessárias para movê-lo para a nuvem.
A figura a seguir mostra as principais etapas envolvidas durante a fase de revisão:
Em seguida, exploraremos detalhadamente o que cada uma dessas etapas significa.
O primeiro passo é avaliar sua prontidão para migrar da versão existente do AEM para o Cloud Service e determinar as áreas que precisarão de refatoração para serem compatíveis com o AEM as a Cloud Service.
Você precisará realizar uma avaliação abrangente do código-fonte AEM atual em relação às alterações notáveis e aos recursos obsoletos para determinar o nível de esforço esperado na jornada de transição.
O número de descobertas influenciará diretamente as linhas do tempo e o sucesso geral do projeto. Portanto, é recomendável descobrir o máximo possível para planejar o delivery ou iniciar as conversas necessárias para reprojetar quaisquer personalizações necessárias para estar em conformidade com a prática recomendada as a Cloud Service do AEM.
Analisador de práticas recomendadas
Você pode acelerar a avaliação executando o Analisador de práticas recomendadas na versão atual do AEM. Ter uma boa compreensão de como funciona é fundamental para acelerar seu planejamento de avaliação.
Você pode ler como funciona consultando o Analisador de práticas recomendadas documentação.
Criar um relatório de avaliação de disponibilidade da nuvem
O próximo passo é criar um relatório com base em todo o conhecimento adquirido até agora. Você pode fazer isso gerando relatórios do Analisador de práticas recomendadas a partir das instâncias de Preparo e Produção, depois de fazer upload deles para o Cloud Acceleration Manager para obter um relatório digerível de itens acionáveis.
Um relatório típico deve conter estas entradas:
Socializar o relatório
Depois que os relatórios do Analisador de práticas recomendadas forem concluídos, compartilhe-os com as equipes relevantes para confirmar suas conclusões e planejar as próximas etapas. Dependendo da preferência, você também pode distribuir uma versão impressa do relatório usando Visualizar impressão.
Depois de estimar o nível de esforço necessário para migrar para o Cloud Service, você deve identificar recursos, criar uma equipe e mapear funções e responsabilidades para o processo de transição.
Se você não tiver estabelecido Indicadores-chave de desempenho (KPIs) anteriormente, é recomendável estabelecer KPIs para a implementação do AEM para ajudar sua equipe a se concentrar naquilo que é mais importante.
Consulte Desenvolvimento de KPIs para saber como escolher os KPIs certos para seus objetivos de negócios.
Assim que você entender o escopo das mudanças necessárias para migrar para o AEM as a Cloud Service, é hora de Prepare o código e a nuvem de conteúdo antes de realmente executar a migração.