Nesta fase da Jornada de Migração as a Cloud Service AEM, você se familiariza com o AEM as a Cloud Service. Você pode analisar as alterações notáveis introduzidas 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 Service, descreve uma lista de fases que devem ser seguidas para que você possa migrar para o AEM as a Cloud Service. Ele também descreve os benefícios de fazer a migração.
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 traz 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 de AEM e 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 que usam 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, envie uma solicitação ao Suporte do Adobe para que ele seja aprovado. Se for aprovado, o CDN aponta para o Fastly e não para instâncias do AEM em nenhum ambiente. |
|
Trabalhos de Longa Execução | Evite tarefas de longa execução, como Sling Schedulers ou trabalhos Cron, já que as instâncias do AEM em execução nos contêineres podem vir e ir a qualquer momento. Repense essas funcionalidades para poder transferi-las para o Adobe Developer. |
|
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 são enfileirados e executados quando os recursos do sistema estão 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 | Não há garantia de quanto espaço em disco é alocado, e as instâncias em contêineres vêm e vão. Portanto, não é aconselhável usar 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 de ativos de atualização do DAM pronto para uso ou personalizado 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. Entenda e refatore completamente os índices Oak antes de gerenciá-los no código implantado. |
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 alterações em /home. É sempre recomendável que qualquer alteração feita no autor seja distribuída. 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ê já estava usando a integração SAML 2.0 na criação e na publicação 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 usar SAML ou outras integrações de autenticação. O AEM as a Cloud Service oferece suporte à autenticação IMS somente para os usuários Autor, Administrador e Desenvolvedor. 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.
Adobe recomenda que você consulte Recursos obsoletos para se familiarizar com os recursos e funcionalidades marcados como obsoletos no Experience Manager as a Cloud Service. Veja qual é o impacto da sua implementação do AEM.
Depois de se familiarizar com as alterações introduzidas no AEM as a Cloud Service, é hora de começar a planejar uma revisão de sua instalação existente. Isso ajuda a 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, explore 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 exigem que a refatoração seja compatível com o AEM as a Cloud Service.
Faça 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 pode influenciar diretamente as linhas do tempo e o sucesso geral do projeto. Portanto, a Adobe recomenda que você descubra o máximo possível para que possa planejar o delivery. Ou inicie as conversas para reprojetar as 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
A próxima etapa é criar um relatório com base em todo o conhecimento adquirido até o momento. Você cria o relatório gerando relatórios do Analisador de práticas recomendadas a partir das instâncias de Preparo e Produção, em seguida, carregue-os no 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 que você possa 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 que você possa aprender a 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.