O objetivo deste documento é descrever o processo, as práticas recomendadas e as ferramentas de uso do Anthos para modernizar aplicativos Java monolíticos legados.
Este documento é destinado a CTOs, CIOs, arquitetos corporativos, desenvolvedores de aplicativos, administradores de segurança de TI, desenvolvedores de aplicativos, equipes de DevOps e equipes de engenharia de confiabilidade do site (SRE, na sigla em inglês). Ele pressupõe um conhecimento básico de conteinerização e seus benefícios operacionais e de desenvolvimento.
Este documento sugere uma abordagem em duas etapas da modernização:
- Conteinerizar. Nesta fase, você conteineriza e implanta aplicativos candidatos adequados à plataforma Anthos (seja no local ou no Google Cloud). Nesta fase, são usados vários serviços e tecnologias, como o Migrate to Containers, as práticas modernas de integração contínua/implantação contínua (CI/CD, na sigla em inglês) e as ferramentas de integração de sistemas.
- Refatorar e reformular. Com o tempo, você refatora e remodela os aplicativos monolíticos legados para frameworks Java modernos (como Spring Boot) e microsserviços.
Neste documento, você encontra orientações e recursos para cada uma dessas fases. Você encontra também um caminho alternativo caso pretenda manter sua empresa em máquinas virtuais (VMs).
Um caso de modernização
Muitas organizações têm dificuldade para manter os aplicativos empresariais em execução e tentar inovar. As equipes de desenvolvimento e operações precisam atender a novas demandas de serviços de aplicativos e também manter, operar e melhorar os portfólios de aplicativos atuais.
Essa nova demanda vem de iniciativas de negócios digitais e do objetivo da transformação digital de melhorar as funções existentes. No entanto, de acordo com o relatório da Gartner (Como criar um caso de negócios da modernização de aplicativos multiplataforma, novembro de 2019), 90% dos aplicativos atuais ainda estarão em uso até 2025, e a dívida técnica decorrente do suporte e gerenciamento desses aplicativos continuará aumentando, consumindo mais de 40% dos orçamentos de TI atuais.
Embora as empresas desenvolvam e adotem novos aplicativos, a maioria deles ainda são aplicativos monolíticos, convencionais. Muitos desses aplicativos legados são executados em servidores de aplicativos proprietários e comerciais, como IBM WebSphere ou Oracle® WebLogic. Como esses aplicativos geralmente são bem otimizados, mantidos e gerenciados, as empresas são desafiadas a inovar a partir deles. Além disso, os servidores de aplicativos proprietários podem aumentar a sobrecarga operacional e exigir (em muitos casos) contratos de licença muito caros.
Vários estudos sugerem que as organizações podem economizar tempo e dinheiro modernizando os aplicativos tradicionais em vez de reescrever o código de aplicativo existente. Qualquer estratégia para modernizar aplicativos legados precisa se concentrar em reduzir o tempo e o custo da modernização.
Aplicativos modernos
Os aplicativos modernos podem ajudar você a proporcionar experiências melhores para seus clientes, o que pode resultar na retenção e na satisfação dos clientes e, assim, aumentar a lucratividade. Os princípios do desenvolvimento de aplicativos e plataformas modernos destacam os benefícios da transformação digital. As seções a seguir explicam esses princípios.
Como aumentar a produtividade do desenvolvedor e do operador
Aplicativos legados geralmente são aplicativos monolíticos. Esses aplicativos têm um grande codebase que executa várias funções. À medida que os aplicativos crescem, assim como as equipes que os desenvolvem e gerenciam, torna-se mais difícil manter e lançar novos recursos rapidamente. Existem muitas dependências entre as equipes que precisam ser reconciliadas e aprovadas antes que uma alteração seja liberada para produção e para o cliente. Essa dinâmica pode reduzir a produtividade do desenvolvedor e do operador e gerar insatisfação do cliente.
Os aplicativos modernos são criados com microsserviços. Diferentes domínios de um aplicativo monolítico são divididos em serviços separados, cada um responsável por uma função específica (por isso, o termo microsserviços). Essa arquitetura oferece vários benefícios:
- Para desenvolvedores. A separação dos serviços permite que os desenvolvedores trabalhem nos seus recursos específicos, independentemente de outros serviços. Essa abordagem aumenta a produtividade do desenvolvedor porque os desenvolvedores podem adicionar recursos ao serviço sem dependências rigorosas de outros serviços e equipes.
- Para operadores. Cada versão de microsserviço implementa pequenas alterações, o que é muito mais fácil para a equipe de operações gerenciar que uma grande mudança complexa. A implantação de alterações menores dessa maneira controlada traz menos riscos se uma versão falhar, levando a um aumento da produtividade das operações.
- Para clientes. As eficiências de desenvolvimento e operacionais de uma arquitetura moderna podem ajudar suas equipes a fornecer novos recursos aos clientes mais rapidamente do que com uma arquitetura monolítica.
Foco em serviços e APIs
Aplicativos legados geralmente são considerados em termos de infraestrutura. Servidores, máquinas virtuais (VMs), rede e armazenamento são elementos de design importantes para um aplicativo monolítico. Os aplicativos modernos são considerados em termos de serviços e APIs. Esse foco em serviços e APIs oferece várias vantagens:
- Redundância e resiliência de serviço. É possível executar serviços em qualquer lugar, geralmente em muitos lugares, como VMs, contêineres ou clusters.
- Disponibilidade do serviço. Operar com foco nos serviços pode aumentar a disponibilidade geral do aplicativo. Desde que o serviço esteja disponível, as falhas da infraestrutura serão indefinidas e irrelevantes. Projetar e pensar em termos de serviços e APIs em vez de infraestrutura enfatiza o tempo de atividade e ajuda você a atingir seu objetivo de nível de serviço (SLO, na sigla em inglês).
Como executar como microsserviços em contêineres
Aplicativos legados normalmente são executados como VMs ou em bare metal. Essas plataformas são caras, usadas de forma ineficiente (com CPUs e RAM subutilizadas) e mais difíceis de gerenciar do que as plataformas modernas baseadas na nuvem (especialmente para servidores bare metal). Os aplicativos modernos são executados como microsserviços em contêineres, o que oferece vários benefícios, incluindo os seguintes:
- Aplicativos menores e mais eficientes. Os contêineres podem incluir um microsserviço com uma ocupação duas a três vezes menor do que um aplicativo monolítico.
- Isolamento do espaço do usuário do Linux. É possível executar vários contêineres em um único host e usá-lo com eficiência.
- Portabilidade entre diferentes ambientes e infraestruturas. Como os contêineres encapsulam o aplicativo com todas as dependências e bibliotecas necessárias, você pode executar os contêineres em qualquer ambiente, seja em um data center local ou em um ambiente de nuvem pública.
Como criar com padrões abertos
Aplicativos legados geralmente usam produtos comerciais ou licenciados para funcionalidade. Essa abordagem não é apenas cara devido aos custos de licenciamento, mas também torna o aplicativo altamente dependente de plataformas comerciais.
Em alguns casos, o software comercial é limitado pela infraestrutura ou hardware em que ele pode ser executado. Por exemplo, se o software só puder ser executado no local, sua empresa precisará gerenciar data centers e infraestruturas dispendiosos (como rede, armazenamento, servidores, energia e HVAC).
Aplicativos e serviços modernos geralmente são criados com o uso de um software de código aberto, oferecendo várias vantagens:
- Extensibilidade e portabilidade. Você pode executar serviços em qualquer lugar.
- Suporte. Tecnologias de código aberto amplamente adotadas como Kubernetes e Docker geralmente têm comunidades fortes (compostas por muitas empresas) que criam recursos para o benefício de várias empresas. Essa abordagem de código aberto resulta em um conjunto de atributos melhor para o produto. Quanto mais você adotar uma tecnologia de código aberto (como o Kubernetes), mais forte será seu conjunto de atributos em comparação com quase todos os equivalentes comerciais.
- Flexibilidade: Nesse modelo, sua empresa não fica presa a um único fornecedor de plataforma ou infraestrutura de aplicativos. A adoção de padrões abertos permite que você tome decisões sobre aplicativos e infraestrutura com base nos requisitos do cliente e da empresa.
A plataforma moderna
Os aplicativos modernos precisam de uma plataforma moderna. A plataforma moderna precisa atender a várias necessidades.
Lançamento de recursos rápido, confiável e seguro
As plataformas modernas precisam ser compatíveis com lançamentos rápidos, confiáveis e seguros de novos recursos.
- Rapidez. Esse requisito depende da automação suficiente para implantar serviços e novos recursos. A automação elimina o trabalho humano e os erros e aumenta a velocidade de entrega.
- confiável A plataforma precisa permitir que as equipes liberem recursos gradualmente ou revertam recursos para o estado original se não funcionarem.
- Proteger. A plataforma precisa ser compatível com controles de acesso granulares. Somente operadores autorizados podem acessar serviços ou implantar recursos e serviços na plataforma.
Uma prioridade nos serviços
Os aplicativos modernos são projetados, desenvolvidos e executados priorizando os serviços, e não a infraestrutura. Essa prioridade nos serviços depende de plataformas resilientes a falhas de infraestrutura. As plataformas modernas têm funcionalidade integrada que recupera serviços (e a própria plataforma) de falhas de hardware e software.
Abordagem híbrida e de várias nuvens com um plano de controle consistente
Como parte da transformação digital, muitas empresas estão migrando para uma estratégia de várias nuvens ou de nuvem híbrida para o portfólio de serviços. Talvez não seja possível migrar determinados aplicativos de data centers locais para a nuvem pública (por motivos regulatórios, de compliance ou de segurança), mas ainda assim você queira usar a nuvem para outros serviços. Plataformas modernas podem ser (e geralmente são) executadas em vários ambientes, como data centers locais, nuvens privadas ou uma ou mais nuvens públicas. Durante a execução em várias infraestruturas, as plataformas modernas precisam fornecer uma experiência unificada de plano de controle consistente aos desenvolvedores e operadores, o que aumenta a eficiência operacional.
Tudo como código declarativo
Plataformas legadas (como VMs) são imperativas por natureza. Os operadores geralmente criam recursos e fornecem scripts e configurações executados no ambiente de execução do aplicativo. Quando os operadores alteram um aplicativo, eles fazem a alteração diretamente na VM em que o aplicativo é executado. Esse processo pode causar desvio de configuração. Isso significa que, a qualquer momento, não há garantia de que o aplicativo e a plataforma estão no estado pretendido. Nesse ambiente, a solução de problemas e a recuperação de falhas podem ser difíceis.
As plataformas modernas são sistemas declarativos em que todos os recursos são definidos como código, também conhecidos como Infraestrutura como código (IAC). Infraestrutura, serviços, implantações, segurança e política são codificados em documentos de recursos que definem o estado pretendido da plataforma. Essa abordagem declarativa permite que os operadores definam os serviços, a segurança e a política por meio de uma linguagem unificada. Como esses recursos são códigos, eles podem ser armazenados em um repositório de código e passar pelas mesmas verificações de código que os aplicativos. Quando o estado da plataforma reside em um repositório Git (junto com o histórico de todas as confirmações de cada alteração de estado), é mais fácil recuperar para um estado anterior quando ocorre uma falha ou um desastre no sistema.
A plataforma Anthos
Anthos é a moderna plataforma de aplicativos do Google Cloud. Anthos é uma plataforma aberta, híbrida e de várias nuvens, use-a para modernizar seus aplicativos atuais, criar novos e executá-los em qualquer lugar de maneira mais segura. Desenvolvido com base em tecnologias de código aberto criadas pelo Google, incluindo Kubernetes, Istio e Knative, o Anthos ajuda você a atingir a consistência entre ambientes locais e em nuvem e a acelerar o desenvolvimento de aplicativos.
O diagrama a seguir mostra os componentes do Anthos e suas interações em um ambiente corporativo típico:
As seções a seguir contém uma breve descrição dos principais componentes do Anthos.
Clusters do Anthos: orquestração do contêiner
O ambiente de computação principal do Anthos depende dos clusters do Anthos para gerenciar as instalações do Kubernetes nos ambientes em que você pretende implantar os aplicativos. Essas ofertas incluem versões upstream do Kubernetes e permitem criar, dimensionar e fazer upgrade de clusters em conformidade com o Kubernetes.
O Kubernetes tem duas partes principais: o plano de controle e os componentes do nó. Quando você usa o GKE, o Google Cloud hospeda o plano de controle, e o servidor da API Kubernetes é o único componente do plano de controle que os clientes podem acessar. O GKE gerencia os componentes do nó no projeto do cliente usando instâncias no Compute Engine. Quando você usa clusters do Anthos, todos os componentes são hospedados no ambiente de virtualização local do cliente.
Com o Kubernetes instalado e funcionando, você tem acesso a uma camada de orquestração comum que gerencia a implantação, a configuração, o upgrade e o dimensionamento do aplicativo.
Anthos Config Management: gerenciamento de políticas
O Anthos Config Management permite gerenciar clusters únicos, clusters multilocatários e implantações de vários clusters do Kubernetes usando arquivos chamados configs. Você armazena os configs em um repositório do Git.
Alguns configs são manifestos de objetos do Kubernetes. Outros configs não são manifestos de objeto, mas fornecem as informações necessárias para o Anthos Config Management. É possível gravar configs em YAML ou JSON. O Anthos Config Management procura atualizações desses arquivos e aplica alterações em todos os clusters relevantes automaticamente.
Uma abordagem de configuração como código permite gerenciar a configuração de clusters do Anthos usando os mesmos princípios que você pode já usar para gerenciar os aplicativos implantados. no Kubernetes.
Anthos Service Mesh: gerenciamento de serviços
O Anthos Service Mesh é um framework compatível com Istio que permite conectar, monitorar e ajudar a proteger serviços em execução em clusters do Anthos. Use o Anthos Service Mesh para criar uma rede de serviços implantados, como balanceamento de carga, autenticação de serviço a serviço e monitoramento, sem precisar alterar o código do serviço.
O Anthos Service Mesh injeta automaticamente um proxy sidecar para cada pod do aplicativo. Um pod é a unidade de execução básica de um aplicativo do Kubernetes. Um pod encapsula o contêiner de um aplicativo ou, em alguns casos, vários contêineres. No Anthos Service Mesh, cada pod contém dois contêineres: o contêiner do aplicativo e um contêiner de proxy Envoy (também conhecido como proxy sidecar). O proxy sidecar intercepta todo o tráfego de rede dos pods e para eles. O Anthos Service Mesh também configura um gateway de entrada para gerenciar o tráfego de entrada para a malha. É possível usar APIs de código aberto do Istio para configurar políticas aplicadas a arquivos secundários e gateways.
Jornada para a modernização
O Google Cloud fornece um processo prescritivo para mover os aplicativos Java de um estado monolítico para microsserviços. Adote as seguintes etapas e siga o ritmo que melhor atende aos requisitos e às necessidades da sua empresa:
- Aumente e modernize aplicativos adequados da execução em VMs para a execução em contêineres sem reescrever qualquer código.
- Implante aplicativos em contêiner na plataforma Anthos usando práticas modernas de CI/CD. Alguns aplicativos podem não ser bons candidatos para a conteinerização e devem permanecer como VMs.
- Refatore aplicativos para pilhas de aplicativos OSS, frameworks modernos e microsserviços ao longo do tempo.
O fluxograma a seguir ilustra essa jornada.
Cada uma destas etapas importantes será explicada na próxima seção.
Etapas da modernização
As seções a seguir contêm explicações sobre cada etapa do processo de modernização e sobre como o Anthos e o Migrate to Containers ajudam em cada etapa.
Etapa 1: como conteinerizar aplicativos Java
Nesta etapa da modernização, você conteineriza aplicativos Java adequados que estão sendo executados como VMs.
A conteinerização é um processo que empacota o código do aplicativo com todas as dependências e bibliotecas do ambiente operacional. É possível executar vários contêineres em um único host, cada um com seus próprios ambientes de aplicativos autônomos. Os contêineres são alternativas mais leves, portáteis e eficientes que as VMs.
Normalmente, você cria e empacota aplicativos Java como arquivos JAR usando ferramentas como maven ou gradle. Em seguida, você executa os binários em VMs ou em servidores bare metal.
Você pode conteinerizar um aplicativo Java de duas maneiras:
- Use o Migrate to Containers para elevar e modernizar o aplicativo.
- Use ferramentas integradoras de sistema para criar contêineres.
Elevar e modernizar usando o Migrate to Containers
Used o Migrate to Containers para migrar aplicativos de VMs diretamente para artefatos em contêineres (como um Dockerfile ou manifestos de recursos do Kubernetes). Em seguida, implante os contêineres no Anthos (no GKE e nos clusters do Anthos no VMware).
Como migrar com o Migrate to Containers
O processo de uso do Migrate to Containers é o seguinte:
- Identifique os candidatos à migração. Nesta etapa, avalie quais aplicativos são adequados para a migração. Dois tipos de aplicativos são bons candidatos à migração:
- Aplicativos com código-fonte que não pode ser acessado. Caso os desenvolvedores não estejam mais com uma empresa e o codebase não seja mais compatível. Em vez de gerenciar esses aplicativos como VMs, é possível usar o processo de conteinerização simplificado no Migrate to Containers para mover esses aplicativos para o Anthos.
- Aplicativos que são mantidos, mas não desenvolvidos. Alguns aplicativos podem não ser desenvolvidos ativamente, mas as empresas ainda precisam deles por causa de dependências em outros serviços. O Migrate to Containers simplifica o processo de modernização da plataforma compatível com esses aplicativos.
- Migrar para o Anthos. Depois de identificar os candidatos adequados para migração, use o Migrate to Containers para converter VMs em artefatos conteinerizados que podem ser implantados no Anthos usando as práticas modernas de CI/CD (consulte a próxima seção). O Migrate to Containers também ajuda a mover dados e o estado dos aplicativos.
O Migrate to Containers e migrações desafiadoras
Em alguns casos, as empresas gerenciam milhares de aplicativos. O número de aplicativos a serem migrados ou as complexidades da conteinerização podem dificultar o avanço das empresas em iniciativas importantes na nuvem. Como resultado, as empresas podem perder oportunidades de negócios e os benefícios dos melhores serviços de nuvem pública da categoria. Esses serviços podem ser serviços de análise e dados, como o BigQuery, aplicativos de inteligência artificial, como o AutoML, ou aplicativos de machine learning (ML), como as APIs pré-treinadas do Google Cloud.
O Migrate to Containers pode ajudar você com os desafios e as complexidades do seu portfólio de aplicativos das seguintes maneiras:
- Como lidar com migrações de aplicativos em grande escala. Use o Migrate to Containers para modernizar e mover vários aplicativos para o Anthos sem acumular dívida técnica para os desenvolvedores e operadores.
- Como simplificar a conteinerização. Além do grande número de aplicativos, a conteinerização pode ser complexa e as empresas podem não ter as habilidades ou a quantidade de recursos para apoiar grandes esforços de modernização em tempo hábil. Para esses casos, o Migrate to Containers fornece um caminho simplificado e eficiente para o Anthos e a modernização.
Para mais informações, consulte documentação sobre Migrate to Containers.
Outras ferramentas para conteinerização
O Docker é uma plataforma amplamente usada para criar imagens de contêiner. Um Dockerfile é um documento de texto que contém todos os comandos que você pode chamar na linha de comando para montar uma imagem. Para criar um contêiner do Docker, crie seus binários (arquivos JAR) e empacote-os em um Dockerfile. Depois de criar o Dockerfile, use-o em um pipeline de CI/CD. O diagrama a seguir ilustra o fluxo de trabalho que usa um Dockerfile.
Etapa 2: como implantar aplicativos no Anthos usando CI/CD moderna
Nesta etapa da modernização, você implanta aplicativos Java conteinerizados no Anthos usando práticas modernas de entrega de software.
Os aplicativos têm que ser criados, testados e entregues aos clientes de forma organizada, automatizada, repetível e confiável. Como várias equipes de desenvolvimento adicionam recursos continuamente, elas geralmente criam, testam e implantam aplicativos em contêineres usando CI/CD.
Benefícios das práticas modernas de entrega de software
A moderna plataforma de entrega de software ou CI/CD do Anthos permite que você faça o seguinte:
- Crie e atualize as práticas recomendadas para provisionar aplicativos.
- Integre novos aplicativos por meio de projetos iniciais (ou padrão).
- Desenvolva e itere aplicativos sem interferir no desenvolvimento de outros aplicativos.
- Implemente e propague políticas facilmente em toda a plataforma.
- Use o GitOps para implantação e para melhoria do gerenciamento de versões e do rastreamento de alterações.
Plataforma de entrega de software com Anthos
Os componentes no diagrama a seguir formam uma plataforma de entrega de software completa, disponível com a plataforma Anthos.
Cada componente fornece funcionalidade para o sistema e os aplicativos em execução na plataforma. Várias equipes (como desenvolvimento, operações e segurança) normalmente são responsáveis por manter o tempo de atividade, a configuração, a estabilidade e a escala da plataforma.
Um componente importante da plataforma de entrega de software é o sistema de CI/CD. Quando você começa a definir o processo de CI/CD, precisa verificar se cada componente produz ou consome artefatos que obedecem a uma interface padronizada. Quando você usa uma interface padrão, é mais fácil trocar cada componente quando uma implementação melhor é lançada no mercado. Quando você cria uma plataforma para aplicativos conteinerizados, é possível escolher entre três interfaces padronizadas:
- Repositórios do Git
- imagens do Docker
- Manifestos do Kubernetes
Use essas interfaces para criar um pipeline de CI/CD reutilizável e flexível com os fluxos mostrados no diagrama a seguir.
O processo é o seguinte:
- Os desenvolvedores confirmam o código do aplicativo no repositório do Git do aplicativo.
- O sistema de CI testa o código, cria um artefato de imagem do Docker e armazena a imagem em um registro.
- Depois que o artefato estiver pronto para implantação, uma referência ao artefato será adicionada ao arquivo de configuração do aplicativo.
- Essa configuração do aplicativo é renderizada em um formato legível pelo Kubernetes e armazenada em um repositório de código, que a implanta em um ambiente de pré-produção.
- Após a confirmação das alterações no repositório do código, os operadores analisam as alterações e as mesclam na ramificação principal.
- O aplicativo é implantado para produção.
- Quando os operadores querem fazer alterações em toda a organização, eles confirmam essas alterações nos repositórios, o que aciona uma configuração de aplicativo. Quando os desenvolvedores implantarem a próxima alteração, eles selecionarão as atualizações dos operadores.
- Paralelamente, os engenheiros de segurança podem implementar e ajustar as políticas que definem o que pode ser implantado por meio da confirmação no próprio repositório de políticas.
Etapa 3: como otimizar VMs locais para aplicativos Java legados
Nesta etapa da modernização, os aplicativos Java são executados como VMs em data centers locais ou no Google Cloud, como mostra o diagrama a seguir.
Alguns aplicativos Java podem não ser bons candidatos para a conteinerização pelos seguintes motivos:
- Alguns dos aplicativos são essenciais para os negócios. Se a migração dos aplicativos críticos para os negócios for muito arriscada, você ainda poderá ter os benefícios do custo flexível da infraestrutura movendo as VMs para o Google Cloud. No Google Cloud, é possível personalizar o tamanho da VM para maximizar os custos de uso.
- As equipes operacionais não estão familiarizadas com o gerenciamento de uma plataforma moderna. Algumas equipes de operações podem não estar familiarizadas com o gerenciamento de ambientes de VM ou não ter as habilidades para operar em plataformas conteinerizadas modernas. Por exemplo, sua equipe pode já estar familiarizada com o conjunto de ferramentas atual para gerenciar a conectividade e as dependências entre aplicativos legados, mas precisa de tempo para acelerar a operação de uma plataforma conteinerizada em produção.
- Adote a nuvem em etapas. Por exemplo, comece a adotar a nuvem, mas sem fazer muitas alterações de uma vez. Ou, devido aos riscos, não altere o ambiente (de um data center para a nuvem) e as plataformas (de VM para contêineres) ao mesmo tempo.
- Você tem restrições operacionais e de orçamento. Isso pode incluir requisitos de hardware/infraestrutura, licenciamento ou arquitetura do aplicativo.
Opções para executar cargas de trabalho de VM
Você pode escolher uma ou mais das seguintes opções para executar cargas de trabalho de VM com mais eficiência:
- No Google Cloud. Você pode executar VMs no Google Cloud de duas maneiras:
- Como instâncias do Compute Engine . O Compute Engine oferece VMs configuráveis em execução nos data centers do Google que têm acesso à infraestrutura de rede de alto desempenho e ao armazenamento em blocos. Essa opção libera as empresas do gerenciamento de servidores e data centers locais e do pagamento de licenças comerciais de virtualização (se aplicável).
- Como VMware como serviço. A parceria entre a VMware e o Google Cloud oferece uma plataforma aberta para garantir a implantação, as operações e a segurança consistentes para aplicativos em nuvem em ambientes de várias nuvens e nuvem híbrida. Essa opção é aplicável a empresas que atualmente executam o VMware e dependem da funcionalidade específica do VMware. As empresas estão em um ambiente de nuvem híbrida em que querem um plano de controle consistente para gerenciar as VMs (em vários ambientes) ou não querem mais gerenciar os próprios data centers e a infraestrutura do servidor.
- Data centers locais. Existem vários motivos para você executar determinados aplicativos como VMs no local:
- Considerações regulatórias ou de compliance
- Necessidades de desempenho que exigem que elas fiquem mais próximas dos usuários ou de outros aplicativos
- Investimentos atuais em hardware local
Ferramentas e soluções para migrar VMs
O Google Cloud oferece várias ferramentas e soluções para migrar as VMs para o Google Cloud. Com a opção "Migrate to Virtual Machines", é possível validar, executar e migrar aplicativos para o Google Cloud em minutos, enquanto seus dados migram de maneira transparente em segundo plano. Para recursos sobre como migrar para o Compute Engine, consulte Migração para o Google Cloud: primeiros passos.
Para migrações para o VMWare como serviço, o Google trabalha com parceiros confiáveis para fornecer serviços profissionais que podem auxiliar nas migrações de VMware para o Google Cloud.
Etapa 4: como refatorar aplicativos em microsserviços
Depois de modernizar a plataforma, concentre-se em modernizar os aplicativos executados nela. Nesta etapa, use os aplicativos em execução na plataforma Anthos e refatore-os em microsserviços.
Talvez você ainda tenha alguns aplicativos que são executados como monolíticos em contêineres, mas isso não é um problema. Um pré-requisito da modernização de aplicativos é migrar os aplicativos para uma plataforma moderna (como o Anthos). Após a migração, o processo de modernização dos aplicativos em microsserviços pode ocorrer ao longo do tempo.
A migração para o Anthos permite que desenvolvedores e operadores se familiarizem com novas formas de gerenciamento de aplicativos e plataformas. Os desenvolvedores se acostumam a mesclar códigos com mais rapidez e realizar testes com mais frequência, enquanto os operadores se familiarizam com a forma moderna de criar, testar e fornecer software aos clientes.
Para os aplicativos executados na plataforma Anthos, suas linhas de negócios podem priorizar os que serão modernizados em microsserviços. O Google e nossos parceiros de IS oferecem várias ferramentas de desenvolvedor e operador para ajudar as empresas nesta etapa de modernização. Esses recursos são explicados nas seções a seguir.
Spring Google Cloud
Como parte da refatoração, é possível transferir aplicativos Java para frameworks Java modernos, como o Spring Boot. O Spring Boot e Spring Framework fornece um modelo abrangente de programação e configuração para aplicativos corporativos modernos baseados em Java. O Spring Cloud fornece ferramentas para desenvolvedores criarem rapidamente alguns dos padrões comuns em sistemas distribuídos, por exemplo, gerenciamento de configuração, descoberta de serviços, disjuntores, roteamento inteligente, micro-proxy, barramento de controle, tokens de uso único, bloqueios globais, eleição de liderança, sessões distribuídas e estado do cluster.
Para simplificar o uso do Google Cloud a partir de aplicativos Spring Boot, o projeto Spring Google Cloud fornece várias bibliotecas e recursos compatíveis com os seguintes produtos do Google Cloud:
- Pub/Sub: Spring Integration e Spring Stream
- Cloud Spanner, Datastore e Cloud SQL: Spring Data
- Cloud Logging e Cloud Trace
- Firestore: Spring Data Reactive Repositories
- Cloud Storage: Spring Resource e Spring Integration
- API Cloud Vision: o modelo
CloudVisionTemplate - Identity-Aware Proxy (IAP): extração de identidade do Spring Security a partir de cabeçalhos do IAP
- BigQuery: Spring Integration
Ferramentas do desenvolvedor
O Google Cloud fornece ferramentas que ajudam você a criar aplicativos Java conteinerizados modernos. Algumas dessas ferramentas incluem:
- Cloud Code. O Cloud Code fornece suporte de ambiente de desenvolvimento integrado para o ciclo de desenvolvimento completo dos aplicativos Kubernetes, da criação de um cluster para desenvolvimento e teste até a execução de um aplicativo finalizado na produção. O Cloud Code fornece amostras de execução, snippets de configuração prontos e uma experiência de depuração personalizada para simplificar o desenvolvimento com o Kubernetes. O Cloud Code fornece uma experiência otimizada do Google Kubernetes Engine (GKE) que simplifica a criação de clusters hospedados no Google Cloud e a melhor integração com as ferramentas do Google Cloud, como o Cloud Source Repositories, o Cloud Storage e várias bibliotecas do Cloud. É possível usar o Cloud Code com o VS Code ou com o IntelliJ.
- Artifact Registry. O Artifact Registry fornece um local central para armazenar artefatos e criar dependências como parte de uma experiência integrada do Google Cloud. O Artifact Registry fornece um único local para gerenciar pacotes, bibliotecas e imagens de contêiner do Docker. É possível usar esses artefatos (pacotes e imagens de contêiner) em um pipeline moderno de CI/CD, descrito anteriormente neste documento.
Criar ferramentas como Jib e Buildpacks. O Jib e o Buildpacks permitem criar contêineres usando as ferramentas do Java que você já conhece (como maven ou gradle). Sem essas ferramentas de desenvolvimento, é preciso criar e testar manualmente o Dockerfile. Essa abordagem manual requer um host com o daemon do Docker em execução para criar e executar os contêineres. Esse processo inclui mais algumas etapas e pode ser repetitivo para os desenvolvedores que querem enviar o código para produção da maneira mais rápida e fácil possível. Em uma única etapa de desenvolvimento, o Jib organiza a compilação do binário, cria a imagem do contêiner e a envia para um Container Registry. O Jib usa ferramentas de desenvolvimento conhecidas dos desenvolvedores, permitindo que eles tenham maior produtividade. Depois de enviar o contêiner Java para o registro, ele poderá ser implantado por meio de um pipeline de CI/CD. O diagrama a seguir mostra esse fluxo geral para Buildpack ou Jib.
Como atualizar para servidores de aplicativos de código aberto
Para alguns aplicativos, a refatoração de aplicativos Java também requer a atualização dos servidores de aplicativos Java. Para reduzir os custos de licenciamento, os aplicativos Java em execução nas plataformas comerciais do servidor de aplicativos (por exemplo, WebSphere ou WebLogic) são atualizados para componentes de código aberto (por exemplo, JBoss ou Tomcat).
Arquitetura de aplicativo Java legado
Aplicativos Java legados geralmente usam uma arquitetura JEE de três ou quatro camadas. A arquitetura JEE é compatível com o desenvolvimento baseado em componentes de aplicativos empresariais de várias camadas. O diagrama a seguir mostra as camadas normalmente encontradas em um sistema de aplicativos JEE.
Estas são as camadas:
- Camada de apresentação. Na camada de apresentação, os componentes da Web, como servlets e páginas JavaServer (JSP ou JSF) ou aplicativos Java autônomos, fornecem uma interface dinâmica para a camada intermediária.
- Camada intermediária ou de aplicativo. Na camada intermediária, ou de aplicativo, o Enterprise Java Beans e os serviços da Web encapsulam uma lógica de negócios que pode ser reutilizada e distribuída para o aplicativo. Esses componentes da camada de servidor estão contidos em um servidor de aplicativos JEE, que fornece a plataforma para esses componentes executarem ações e armazenarem dados.
- Camada de dados corporativos. Na camada de dados, os dados corporativos são armazenados e mantidos, normalmente em um banco de dados relacional.
Normalmente, essas camadas diferentes são implantadas em ambientes virtualizados e dependem de servidores de aplicativos, o que pode gerar custos elevados de licenciamento.
Benefícios da mudança para padrões abertos
A mudança para os padrões abertos reduz os custos de licenciamento e oferece os benefícios das metodologias de implantação baseadas na nuvem e de uma plataforma baseada na nuvem.
Ferramentas e soluções
O Google Cloud tem parceria com vários integradores de sistemas (SIs, na sigla em inglês) que têm abordagens comprovadas e ferramentas para reformular aplicativos JEE e adotar tecnologias OSS.
O processo de atualização de plataforma começa com a avaliação dos aplicativos Java legados. A avaliação considera vários fatores, incluindo a complexidade de um aplicativo, a funcionalidade, métricas de uso e importância comercial. Essa avaliação gera uma lista priorizada de aplicativos candidatos a serem substituídos. Os ISs fornecem ferramentas de desenvolvedor e DevOps que ajudam as empresas a remover todas as dependências do código-fonte de servidores de aplicativos comerciais. Os critérios de teste e saída são considerados para cada aplicativo antes de prosseguir para a próxima etapa (implantação). Essa etapa é aplicável a aplicativos em que o código-fonte está acessível e a variante de código aberto da plataforma existe.
Práticas recomendadas de refatoração
Os dois artigos do Google Cloud a seguir explicam os benefícios e o processo de migração de aplicativos monolíticos para microsserviços:
- Como migrar um aplicativo monolítico para microsserviços
- Como acomodar a migração com a expansão de malha do Istio
Como conectar microsserviços a VMs com o Anthos Service Mesh
As empresas têm vários aplicativos. Quase todas as empresas têm aplicativos em execução em uma das seguintes plataformas:
- A plataforma Anthos para executar microsserviços em contêineres
- Uma plataforma de virtualização para executar VMs
Muitas vezes, os serviços em execução nessas duas plataformas dependem uns dos outros e precisam ser capazes de se comunicar com segurança. Para microsserviços em execução na plataforma Anthos, o Anthos Service Mesh fornece uma conexão aprimorada de segurança às VMs em execução fora do Anthos em um ambiente virtualizado.
Benefícios do Anthos Service Mesh com VMs
- As VMs podem aproveitar a mesma política declarativa no estilo do Kubernetes e o framework de gerenciamento de segurança dos contêineres e microsserviços em execução no Anthos. Essa abordagem permite que os operadores garantam que haja uma conexão autenticada aprimorada de segurança (mTLS) entre os contêineres em execução no Anthos e as VMs em execução em outro ambiente.
- Não é necessário recodificar as VMs existentes para que elas apareçam como serviços na plataforma Anthos. Depois que a VM aparece como um serviço, o Anthos a trata como um serviço em execução no GKE.
- Os operadores recebem observabilidade aprimorada (métricas) para VMs sem instrumentação. As métricas aparecem como se fossem um serviço em execução no Anthos.
VMs para conteinerização
Ao longo do tempo, você pode mover as VMs refatoradas existentes para contêineres. Essa abordagem permite avançar na modernização de acordo com o seu ritmo, priorizando quais aplicativos serão modernizados.
A seguir
- Leia a lista de verificação de integração do Google Cloud Enterprise.
- Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.