Nesta fase da Jornada de Migração AEM as a Cloud Service, você se familiarizará com AEM as a Cloud Service, analisará as alterações notáveis que introduziu e compreenderá o que é necessário para planejar uma migração bem-sucedida para a nuvem.
O documento anterior, Introdução à migração para AEM as a Cloud Service, descreve uma lista de fases que precisam ser seguidas para migrar para AEM as a Cloud Service, bem como os benefícios de fazê-lo.
Este documento ajuda você a entender quais fatores devem ser considerados para garantir que sua 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.
Junto com essas melhorias, várias diferenças foram introduzidas entre as instalações locais do AEM e o Adobe Managed Services, em comparação a AEM as a Cloud Service.
A lista de itens na tabela abaixo é o subconjunto das alterações mais relevantes para uma migração para AEM as a Cloud Service. Você pode consultar a lista completa de alterações importantes here.
O que mudou? | Referência | Takeaways de chave |
---|---|---|
Separe os filtros mutáveis e imutáveis em pacotes correspondentes | AEM alterações importantes as a Cloud Service AEM Estrutura de Projeto para AEM as a Cloud Service |
Um único pacote que pode ser implantado em AEM as a Cloud Service pode ter subpacotes, principalmente para conter conteúdo mutável e imutável separado em seus próprios pacotes. |
Repo Init | Documentação do Apache Sling RepoInit | Os scripts de realocação são a prática recomendada para criar estruturas de nó iniciais, usuários, grupos ou usuários de serviços. Como esses scripts podem ser direcionados pelo modo de execução e gerenciáveis por meio da implantação do pacote de código, eles fornecem muita flexibilidade para realizar tarefas de inicialização do repositório. |
Não são permitidos modos de Execução Personalizados | Somente os modos de execução fornecidos prontos para uso com AEM as a Cloud Service são compatíveis. Quando ambientes de desenvolvimento adicionais são adicionados, todos se vinculam ao modo de execução "dev". |
|
A execução de pipeline do Cloud Manager é a única maneira de implantar | Em AEM as a Cloud Service, o acesso ao /system/console não é permitido, portanto, todas as configurações do OSGi devem fazer parte do código e devem ser implantadas como código. As configurações 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 pela Distribuição de conteúdo de sling | 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. Não há suporte para replicação inversa |
|
CRX/DE e Gerenciador de pacotes | O CRX/DE é permitido somente no ambiente de desenvolvimento. O Gerenciador de Pacotes está acessível em todas as instâncias do autor, mas os pacotes que serão implantados devem conter apenas conteúdo mutável ( por exemplo: /content ou /conf) |
|
Incorporado no CDN e Obtenha seu próprio CDN | AEM as a Cloud Service inclui a CDN para todos os ambientes, o que é otimizado para a maioria dos casos de uso. Se quiser configurar seu próprio CDN, envie uma solicitação para o Adobe Support para que ele seja aprovado. Se for aprovado, o CDN apontará para Fastly e não para AEM instâncias em nenhum ambiente. |
|
Trabalhos de longa execução | Evite executar trabalhos de longa execução, como agendadores do Sling ou trabalhos do Cron, pois as instâncias de AEM executadas nos contêineres podem vir e ir a qualquer momento. Repense essas funcionalidades para descarregá-las no Adobe I/O. |
|
Alternar para operações assíncronas | Configuração de 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 integração e autenticação baseadas em token | Gerar tokens de acesso para APIs do lado do servidor Tutorial de autenticação baseado 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ário locais com senhas no AEM. |
E/S de arquivo/Uso de 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 operações de E/S de arquivo para gravar ou ler do disco anexado à instância de 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 do Ativo de atualização 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 em AEM as a Cloud Service | Fazer upload de comparações de API e etapas do processo WF suportadas | Em AEM as a Cloud Service, durante o upload ou o download de um ativo, o ativo é transmitido 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 OOTB ou DAM personalizado de seu código.Todos os ativos carregados 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 e configurar workflows de pós-processamento. | |
Etapas da representação personalizada | 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 na pesquisa e indexação de conteúdo | Há mudanças consideráveis no processamento subjacente de índices e no momento em que ele começa. Entenda e refatere completamente os índices do Oak antes de gerenciá-los no código que você implantará. |
Nem todas as tarefas de manutenção podem ser configuradas | AEM tarefas de manutenção as a Cloud Service | Você pode configurar apenas determinadas tarefas de manutenção com AEM as a Cloud Service. |
Alterações no repositório de publicação | Alterações diretas no repositório de Publicação não são permitidas, 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 do Cloud Manager correspondente. | |
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 | AEM backup e restauração as a Cloud Service | |
Alterações na autenticação | Suporte IMS do AEM as a Cloud Service | Se você estava usando anteriormente a integração do SAML 2.0 no autor e na publicação antes de migrar para o Cloud Service, a principal mudança é que AEM autor as a Cloud Service só se integra ao Adobe IMS. No entanto, AEM camada de publicação as a Cloud Service 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 marcados como obsoletos no Experience Manager as a Cloud Service e ver qual é o impacto da sua implantação de AEM.
Depois de se acostumar com as alterações introduzidas com AEM as a Cloud Service, é hora de começar a planejar uma revisão da instalação existente, para medir o nível de alterações necessárias para movê-la para a nuvem.
A figura a seguir mostra as principais etapas envolvidas durante a fase de revisão:
Em seguida, exploraremos detalhadamente o significado de cada uma dessas etapas.
O primeiro passo é avaliar sua disponibilidade para migrar da versão AEM existente para o Cloud Service e determinar as áreas que exigirão refatoração para serem compatíveis com AEM as a Cloud Service.
Você precisará fazer 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 os prazos 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 qualquer personalização necessária para estar em conformidade com AEM prática recomendada as a Cloud Service.
Analisador de práticas recomendadas
Você pode acelerar a avaliação executando o Analisador de práticas recomendadas em relação à versão atual do AEM. Ter um bom entendimento de como funciona é fundamental para acelerar seu planejamento de avaliação.
Leia como funciona consultando o Analisador de práticas recomendadas documentação.
Criar um relatório de avaliação de disponibilidade da nuvem
O passo seguinte é criar um relatório baseado em todos os conhecimentos adquiridos até agora. Você pode fazer isso gerando relatórios do Analisador de práticas recomendadas das instâncias de Preparo e Produção, em seguida, faça o upload delas no Cloud Acceleration Manager para um relatório digestível de itens acionáveis.
Um relatório típico deve conter essas 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 suas próximas etapas. Dependendo da preferência, você também pode distribuir uma versão impressa do relatório usando Visualização de 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 sua implementação de 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 alterações necessárias para mudar para AEM as a Cloud Service, é hora de Prepare seu código e a nuvem de conteúdo antes de realmente executar a migração.