Padrões e práticas de implementações híbridas e em várias nuvens

Este artigo é o primeiro de uma série que trata de implementações híbridas e em várias nuvens, padrões de arquitetura e topologias de rede. Nesta parte, exploramos as oportunidades e os desafios das implantações híbridas e em várias nuvens, além de fornecer orientações sobre como lidar com e implementar uma configuração híbrida que usa o Google Cloud Platform (GCP).

A série é composta das seguintes partes:

A digitalização e a necessidade de se adaptar rapidamente às novas demandas do mercado em constante evolução provocaram um aumento nos requisitos e expectativas que pressionam a TI corporativa. Muitas empresas encontram dificuldades em atender e adaptar-se a tais tendências mantendo a infraestrutura e os processos atuais.

Ao mesmo tempo, os departamentos de TI geralmente trabalham sob forte pressão para aumentar a economia, tornando ainda mais difícil justificar mais investimentos em despesas de capital (CAPEX, na sigla em inglês) para ampliar e modernizar data centers e equipamentos.

Desenvolver uma estratégia de nuvem híbrida é uma solução pragmática. Com a nuvem pública, é possível ampliar a capacidade e os recursos da TI sem a necessidade de realizar investimentos iniciais em CAPEX. Ao adicionar uma ou mais implantações de nuvem à infraestrutura que sua empresa já tem, além de preservar os investimentos realizados, você também evitará se comprometer com um único fornecedor de TI. Por fim, a adoção de uma estratégia híbrida possibilita modernizar aplicativos e processos de forma incremental, conforme permitido pelos recursos.

Nuvem híbrida e várias nuvens

Como cada empresa têm cargas de trabalho, infraestrutura e processos únicos, é necessário adaptar a estratégia de implementação híbrida às necessidades específicas. O resultado é o uso inconsistente dos termos nuvem híbrida e várias nuvens.

No contexto do GCP, o termo nuvem híbrida descreve uma configuração em que cargas de trabalho comuns ou interconectadas são implantadas em mais de um ambiente de computação: um baseado na nuvem pública e, no mínimo, um ambiente particular.

O exemplo mais comum é combinar um ambiente de computação particular (normalmente o data center local atual) e um ambiente de computação em nuvem pública, como mostrado no diagrama a seguir:

Como combinar um ambiente computacional particular com um em nuvem pública

O termo várias nuvens descreve configurações que combinam pelo menos dois provedores de nuvem pública, como no diagrama a seguir:

Topologia de várias nuvens que combina pelo menos dois provedores de nuvem pública

Uma configuração de várias nuvens também pode incluir ambientes de computação particulares.

Topologia de várias nuvens que combina pelo menos dois provedores de nuvem pública e ambientes particulares

Drivers para configurações de nuvem híbrida e de várias nuvens

As configurações de nuvem híbrida e várias nuvens podem ser temporárias, ou seja, mantidas apenas por um tempo limitado para facilitar a migração. No entanto, essas configurações também podem representar o estado futuro da maioria das organizações, à medida que elas criam novos sistemas e evoluem os sistemas atuais para aproveitá-los da melhor maneira possível, independentemente de onde a instalação é executada. As configurações híbridas e de várias nuvens podem, portanto, ser permanentes no cenário de TI.

Uma configuração híbrida ou de várias nuvens raramente é o objetivo final. Geralmente, elas são um meio de atender aos requisitos de negócios. Portanto, escolher a configuração híbrida ou de várias nuvens correta requer que tais requisitos sejam claros.

Impulsionadores e restrições de negócios

Os impulsionadores e as restrições comuns do ponto de vista dos negócios incluem:

  • redução do CAPEX ou gastos gerais com TI;
  • maior flexibilidade e agilidade para responder melhor às demandas do mercado em evolução;
  • desenvolvimento das capacidades, como serviços analíticos avançados, que podem ser de difícil implantação nos ambientes atuais;
  • melhor qualidade e disponibilidade do serviço;
  • maior transparência em relação aos custos e o consumo de recursos;
  • observação das leis e regulamentos sobre soberania de dados;
  • eliminação ou redução da dependência de fornecedor.

Impulsionadores do projeto e do desenvolvimento

Os impulsionadores comuns do projeto e do desenvolvimento incluem:

  • automatização e aceleração da distribuição de aplicativos para reduzir o tempo de lançamento e do ciclo;
  • utilização de APIs e serviços de alto nível para acelerar o desenvolvimento;
  • aceleração do provisionamento de recursos computacionais e de armazenamento.

Requisitos e restrições operacionais

Os requisitos e as restrições que precisam ser pensados em relação às operações incluem:

  • garantia de que a autenticação, a autorização, a auditoria e as políticas sejam consistentes nos diferentes ambientes computacionais;
  • uso de ferramentas e processos de maneira consistente para limitar a complexidade;
  • visibilidade em todos os ambientes.

Restrições de arquitetura

Do ponto de vista da arquitetura, os sistemas atuais geralmente causam as maiores restrições, que podem incluir:

  • dependências entre aplicativos;
  • requisitos de desempenho e latência para comunicação entre sistemas;
  • dependência de hardware ou sistemas operacionais não disponíveis na nuvem pública;
  • restrições de licenciamento.

Objetivos gerais

O objetivo de uma estratégia nuvem híbrida e de várias nuvens é atender a esses requisitos com um plano que descreve:

  • que cargas de trabalho serão executadas ou migradas para cada ambiente computacional;
  • que padrões serão aplicados às várias cargas de trabalho;
  • que tecnologia e topologia de rede serão usadas.

É essencial que qualquer estratégia de nuvem híbrida e de várias nuvens seja decorrente dos requisitos de negócios. No entanto, a maneira como fazer isso raramente está clara. As cargas de trabalho, as tecnologias e os padrões de arquitetura escolhidos não somente dependem dos requisitos de negócios, mas também têm influência uns sobre os outros de maneira cíclica. O diagrama a seguir ilustra esse ciclo.

Como cargas de trabalho, padrões e tecnologias afetam e dependem dos requisitos de negócios

Como definir uma visão

Nessa trama de dependências e restrições, no mínimo, é difícil definir um plano que considere todas as cargas de trabalho e os requisitos, especialmente quando se trata de um ambiente de TI complexo. Além disso, o planejamento é demorado e pode resultar em conflitos de interesses entre as partes envolvidas.

Para evitar esse tipo de situação, primeiro desenvolva uma declaração de visão que tenha como foco a perspectiva dos negócios e responda às seguintes questões:

  • Por que a abordagem atual e o ambiente computacional não são suficientes?
  • Quais são as principais métricas que você quer otimizar usando a nuvem pública?
  • Por quanto tempo você planeja usar uma configuração de nuvem híbrida ou de várias nuvens? Você acha que essa configuração será permanente ou funcionará apenas provisoriamente, durante a migração completa para a nuvem?

A declaração de visão não deverá abordar como essas metas serão alcançadas.

Concordar com a visão e conseguir a aprovação das partes interessadas relevantes dá a base para a realização das próximas etapas do processo de planejamento.

Como projetar uma estratégia de nuvem híbrida e de várias nuvens

Depois de estabelecer a visão, elabore a estratégia:

  1. Realize uma avaliação inicial das cargas de trabalho. Considerando as metas definidas no documento de visão, identifique uma lista de cargas de trabalho atuais e planejadas que poderiam se beneficiar da implantação ou da migração para a nuvem pública. Discutimos esse tópico em mais detalhes na seção a seguir.

  2. Começando pelas cargas de trabalho indicadas, identifique os padrões aplicáveis. Com base nesses padrões, identifique as possíveis topologias.

    Se você identificar mais de um padrão e topologia aplicáveis, refine a seleção das cargas de trabalho para estabelecer um único padrão e topologia. Repita esse processo, conforme necessário.

    Aplicar vários padrões e topologias é uma abordagem viável para organizações de grande porte. Mas raramente essa é uma abordagem ideal devido à maior complexidade, o que pode desacelerar o progresso.

  3. Priorize suas cargas de trabalho. Devido aos muitos requisitos, é melhor adotar uma abordagem iterativa.

  4. Selecione uma primeira carga de trabalho a ser colocada na nuvem pública. Garanta que ela não seja crítica para os negócios ou muito difícil migrar. No entanto, essa carga de trabalho deve ser representativa o suficiente para servir como modelo para as próximas implantações ou migrações.

    Enquanto você seleciona uma carga de trabalho para a migração, comece a preparar o ambiente do GCP.

  5. Configure a organização, os projetos e as políticas do GCP que você precisará para preparar o ambiente em nuvem para as primeiras implantações.

  6. Implemente a topologia de rede e estabeleça a conectividade necessária entre o GCP e seus ambientes computacionais particulares.

Cargas de trabalho

A decisão sobre quais cargas de trabalho devem ser executadas em cada ambiente computacional tem um impacto profundo na eficácia da estratégia de nuvem híbrida e de várias nuvens. Colocar a carga de trabalho errada na nuvem pode complicar sua implantação e trazer poucos benefícios. Colocar a carga de trabalho apropriada no lugar certo não apenas é vantajoso para a própria carga de trabalho, mas também ajuda você a aprender sobre os benefícios de cada ambiente.

Priorização da nuvem

Uma maneira comum de começar a usar a nuvem pública é adotar uma abordagem de priorização da nuvem. Nesse tipo de abordagem, as cargas de trabalho novas são implantadas na nuvem pública. Nesse caso, pense na implantação clássica em um ambiente computacional particular somente se a implantação na nuvem não for possível por motivos técnicos ou organizacionais.

A estratégia de priorização da nuvem tem vantagens e desvantagens. Como ponto positivo, ela é voltada para o futuro. É possível implantar novas cargas de trabalho de maneira limpa e nativa da nuvem, evitando (ou pelo menos minimizando) as dificuldades de migrar as cargas de trabalho atuais.

Como ponto negativo, usar uma estratégia que prioriza a nuvem pode fazer com que você perca oportunidades de beneficiar as cargas de trabalho atuais. As novas cargas de trabalho podem ser apenas uma fração das cargas de trabalho gerais de TI, com impacto limitado no desempenho e nos gastos de TI globais. O tempo gasto na migração de uma carga de trabalho atual pode gerar mais vantagens ou economias do que tentar ajustar uma nova carga de trabalho na nuvem.

Seguir uma estratégia de priorização estrita da nuvem também implica o risco de aumentar a complexidade geral do ambiente de TI. Essa abordagem pode criar redundâncias, reduzir o desempenho devido à comunicação excessiva entre ambientes ou resultar em um ambiente computacional inadequado cada carga de trabalho individual.

Levando todos esses riscos em consideração, talvez seja melhor usar uma abordagem de priorização da nuvem somente para cargas de trabalho específicas. Assim, você se concentrará apenas nas cargas de trabalho que colherão os melhores benefícios da migração ou implantação em nuvem. Essa abordagem também leva em conta a modernização das cargas de trabalho atuais, um assunto que discutiremos na próxima seção.

Migração e modernização

Nuvem híbrida/várias nuvens e modernização da TI são conceitos distintos, mas conectados em um círculo virtuoso. Usar a nuvem pública pode facilitar e simplificar a modernização das cargas de trabalho de TI, e a modernização da TI ajudará você a aproveitar melhor a nuvem.

Os principais objetivos de modernizar as cargas de trabalho são:

  • ter mais agilidade para se adaptar às mudanças nos requisitos;
  • reduzir os custos de infraestrutura e operações;
  • aumentar a confiabilidade e a resiliência para minimizar o risco aos negócios.

Migração lift-and-shift

A migração lift and shift é o processo em que uma carga de trabalho é migrada de um ambiente computacional particular para a nuvem pública sem que ela sofra alterações significativas. Geralmente, esse processo envolve a migração de máquinas virtuais (VMs, na sigla em inglês) atuais e imagens correspondentes para o Compute Engine.

Executar VMs no Compute Engine, em vez de em um ambiente computacional particular, traz os seguintes benefícios:

  • Provisionamento rápido de recursos computacionais e de armazenamento, evitando os atrasos causados pela aquisição e instalação de equipamentos em data centers clássicos (particulares ou locais).

  • Pagamento apenas pelos recursos computacionais utilizados, sem a necessidade de firmar um compromisso ou realizar qualquer investimento inicial.

  • Automação das tarefas operacionais e, como resultado, redução do esforço e dos custos.

Além disso, se você decidir reescrever seus aplicativos para que se tornem mais nativos da nuvem, poderá ter estes outros benefícios significativos:

  • Utilização do escalonamento automático para garantir que recursos computacionais sejam provisionados somente quando necessário, evitando custos de provisionamento excessivo.

  • Utilização de gerenciadores de cluster, como o Kubernetes, para aumentar a resiliência de aplicativos, reiniciando-os automaticamente ou migrando-os para máquinas diferentes em caso de falha.

  • Redução ainda maior da sobrecarga operacional usando serviços gerenciados.

  • Automação da implantação, o que ajudará a acelerar os processos de desenvolvimento e lançamento de produtos. Dessa forma, sua empresa reagirá mais rapidamente ao feedback, às mudanças nos requisitos e às demandas do mercado.

Como modernizar uma carga de trabalho mudando e transformando um aplicativo para que seja nativo da nuvem

Como ilustrado no diagrama, ao modernizar uma carga de trabalho atual, pense não somente em migrar o aplicativo, mas também em transformá-lo para que ele se torne nativo da nuvem.

Migração do tipo transformar e mover

Ainda que seja comum transferir um aplicativo para a nuvem antes de investir na transformação, a abordagem inversa pode ser melhor em alguns casos. A ideia de transformar e mover inicia-se com a refatoração e a modernização de um aplicativo que já existe. Mesmo antes de mover o aplicativo para a nuvem, essa transformação gera inúmeros benefícios:

  • melhoria do processo de implantação

  • investimento em ferramentas e infraestrutura de integração e integração contínuas (CI/CD, na sigla em inglês) para acelerar o ritmo de lançamentos e encurtar os ciclos de feedback

Depois de transformar o aplicativo, você poderá movê-lo para a nuvem. Isso ajudará a acelerar o provisionamento de recursos e aumentará economia com o uso do escalonamento automático, o que evita o provisionamento excessivo.

Para que a migração do tipo transformar e mover funcione, pense em fazer alguns investimentos na infraestrutura e nas ferramentas locais, como configurar um registro Docker local e provisionar clusters do Kubernetes para colocar aplicativos em contêineres.

Migração do tipo romper e substituir

A migração do tipo mover e substituir refere-se a remover um sistema e substituí-lo. Em alguns casos, não é possível ou econômico evoluir o sistema e a base de código atuais. Os requisitos podem ter mudado significativamente ou, então, o aplicativo atual pode ser baseado em uma pilha de software ou hardware que não é adequada para investimentos futuros. Nesses casos, a melhor abordagem talvez seja substituir o sistema, o que significa adquirir uma solução nova ou desenvolver um aplicativo moderno nativo da nuvem do zero.

Como combinar as abordagens de migração

Cada uma das três abordagens de migração tem pontos fortes e fracos. Uma das principais vantagens de seguir uma estratégia de nuvem híbrida e de várias nuvens é que você não precisa escolher uma única abordagem. Em vez disso, é você que decide qual delas funciona melhor para cada carga de trabalho.

Escolha a migração lift-and-shift se qualquer uma das afirmações abaixo se aplicar às cargas de trabalho:

  • A carga de trabalho tem um número relativamente pequeno de dependências no ambiente.
  • Não vale a pena refatorar a carga de trabalho.
  • A carga de trabalho é baseada em software de terceiros.

Pense em adotar a migração transformar e mover para os seguintes tipos de carga de trabalho:

  • A carga de trabalho tem dependências que precisam ser desatadas.
  • A carga de trabalho depende de sistemas operacionais, de hardware ou de banco de dados que não podem ser ajustados para a nuvem.
  • A carga de trabalho não faz um uso eficiente dos recursos computacionais ou de armazenamento.
  • Não é possível implantar automaticamente a carga de trabalho com facilidade.

Por fim, a migração romper e substituir pode ser a ideal para os seguintes tipos de carga de trabalho:

  • A carga de trabalho não satisfaz mais aos requisitos atuais.
  • A carga de trabalho é baseada em tecnologia de terceiros que chegou ao fim da vida útil.
  • A carga de trabalho exige taxa de licenciamento de terceiros que não são mais econômicas.

Portabilidade

Na maioria das migrações, transferir uma carga de trabalho para a nuvem é um esforço realizado apenas uma vez e irreversível. Mas, em um cenário de nuvem híbrida e especialmente de várias nuvens, você talvez queira transferir posteriormente as cargas de trabalho entre as nuvens. Para tornar isso mais fácil, suas cargas de trabalho devem ser portáteis:

  • Tenha certeza de que é possível transferir a carga de trabalho de um ambiente computacional para outro sem realizar modificações significativas.
  • Verifique se a implantação e o gerenciamento de aplicativos são consistentes em todos os ambientes computacionais.
  • Garanta que tornar a carga de trabalho portátil não crie conflitos com o fato dela ser nativa da nuvem.

No nível da infraestrutura, use ferramentas como o Terraform para automatizar e unificar a criação de recursos como VMs e balanceadores de carga em ambientes heterogêneos. Além disso, use ferramentas de gerenciamento de configuração, como Ansible, Puppet ou Chef, para estabelecer um processo comum de implantação e configuração. Se preferir, use uma ferramenta de preparação de imagens, como o Packer, para criar imagens de VM para plataformas diferentes usando um único arquivo de configuração compartilhado. Por fim, use soluções como o Prometheus e o Grafana para garantir o monitoramento consistente nos vários ambientes.

Utilizando essas ferramentas, é possível montar uma cadeia semelhante á ilustrada no diagrama abaixo. Essa cadeia de ferramentas abstrai as diferenças entre os ambientes computacionais e permite unificar os processos de provisionamento, implantação, gerenciamento e monitoramento.

Cadeia de ferramentas que abstrai as diferenças entre os ambientes computacionais e permite unificar o provisionamento, a implantação, o gerenciamento e o monitoramento

Uma cadeia de ferramentas comum pode ajudar a alcançar a portabilidade, mas ela está sujeita a várias limitações:

  • Talvez não seja possível usar determinados recursos que o ambiente em nuvem oferece de maneira nativa. Especificamente, o uso de VMs como base comum dificulta a implementação de aplicativos verdadeiramente nativos da nuvem. Às vezes, o uso de VMs impede a utilização de serviços gerenciados, o que pode resultar na perda de oportunidades para reduzir a sobrecarga administrativa.

  • Criar e manter a cadeia de ferramentas gera custos operacionais e indiretos.

  • Com o passar do tempo, a cadeia de ferramentas pode se tornar complexa e aplicável somente à sua empresa. Essa complexidade pode resultar no aumento dos custos de treinamento.

Contêineres e Kubernetes

Criar e manter uma cadeia de ferramentas personalizada para alcançar a portabilidade de cargas de trabalhos usando VMs envolve muitos desafios. Uma solução é utilizar contêineres e o Kubernetes.

Com os contêineres, seu software continua funcionando de maneira confiável mesmo depois de migrá-lo de um ambiente para outro. Já o Kubernetes cuida da orquestração, da implantação, do dimensionamento e do gerenciamento de aplicativos em contêineres, fornecendo os serviços que formam a base de um aplicativo nativo da nuvem. Por ser possível instalar e executar o Kubernetes em uma variedade de ambientes computacionais, também é possível usá-lo para estabelecer uma camada de ambiente de execução comum nos diferentes ambientes computacionais:

  • O Kubernetes fornece os mesmos serviços e APIs para o ambiente computacional particular ou em nuvem. Além disso, o nível de abstração é muito maior do que o proporcionado pelas VMs. Na maioria das vezes, isso se traduz em menos trabalho de preparação e maior produtividade do desenvolvedor.

  • Ao contrário de uma cadeia de ferramentas personalizada, o Kubernetes é amplamente adotado tanto para o desenvolvimento e o gerenciamento de aplicativos. Dessa forma, é possível aproveitar o conhecimento especializado, a documentação e o suporte de terceiros que você já tem.

  • O Kubernetes usa contêineres Docker, um padrão adotado pelo setor para empacotamento de aplicativos que não está vinculado a qualquer fornecedor específico. O Kubernetes tem código aberto e é regido pela Cloud Native Computing Foundation.

Para evitar o esforço de instalar e operar essa solução, use uma plataforma de Kubernetes gerenciada, como o Google Kubernetes Engine (GKE). Assim, a equipe de operações pode mudar o foco de trabalho da infraestrutura para os aplicativos. O diagrama a seguir mostra o aspecto de uma plataforma de Kubernetes gerenciada.

Plataforma de Kubernetes gerenciada

Limites da portabilidade de carga de trabalho

Para que tornar as cargas de trabalho mais portáteis, o Kubernetes fornece uma camada de abstração que oculta muitas das complexidades e diferenças entre os ambientes computacionais.No entanto, essa abstração apresenta algumas limitações:

  • Um aplicativo pode ser portável para um ambiente diferente com alterações mínimas, mas isso não significa que ele terá um bom funcionamento em ambos os ambientes. Diferenças na infraestrutura subjacente de computação ou rede, além da proximidade a serviços dependentes, podem resultar em desempenhos muito diferentes.

  • A migração da carga de trabalho entre ambientes computacionais também pode exigir a migração dos dados. Além do tempo, do esforço e do orçamento necessários para copiar ou migrar dados entre ambientes computacionais, geralmente esses ambientes oferecem serviços e recursos diferentes para armazenar e gerenciar os dados.

  • O Kubernetes oferece uma maneira unificada de provisionar diferentes tipos de balanceadores de carga. No entanto, comportamento desses balanceadores não é definido em detalhes e pode apresentar diferenças sutis entre ambientes.

  • O GKE integra o controle de acesso baseado em funções (RBAC, na sigla em inglês) ao Cloud Identity and Access Management. Mas outros ambientes podem exigir maneiras diferentes de configurar o RBAC e proteger as cargas de trabalho.

Mesmo com o Kubernetes, pode ser desafiador abstrair as diferenças entre ambientes computacionais ou nuvens públicas. A portabilidade de cargas de trabalhos tem como principal objetivo simplificar as migrações entre ambientes, e não automatizá-las.

Avaliação da carga de trabalho

Quando há novos projetos em andamento e centenas ou milhares de cargas de trabalho já em execução, decidir quais cargas de trabalho serão implantadas ou migradas para cada ambiente computacional pode ser uma tarefa assustadora.

Uma solução que ajuda a tomar essas decisões de forma consistente e objetiva é categorizar e pontuar as cargas de trabalho por oportunidade, risco e dificuldade técnica.

Os fatores abaixo ajudam a avaliar as oportunidades da migração:

  • Potencial para inovar ou se diferenciar no mercado com o uso dos serviços em nuvem.
  • Potencial para economizar no custo total de propriedade de um aplicativo.
  • Potencial para melhorar a disponibilidade, a resiliência, a segurança ou o desempenho.
  • Potencial para acelerar processos de desenvolvimento e lançamento.

Os fatores abaixo ajudam a avaliar os riscos da migração:

  • Possível impacto provocado por interrupções resultantes da migração ou da experiência limitada em implantações de nuvem pública.
  • Necessidade de obedecer a todas as restrições legais ou regulatórias em vigor.

Os fatores abaixo ajudam na avaliação das dificuldades técnicas da migração:

  • Tamanho, complexidade e idade do aplicativo.
  • Número de dependências com outros aplicativos.
  • Restrições impostas por licenças de terceiros.
  • Dependências de versões específicas de sistemas operacionais, bancos de dados ou outras configurações do ambiente.

Depois de avaliar as cargas de trabalho iniciais, comece a priorizar algumas delas e identifique os padrões de arquitetura e as topologias de rede aplicáveis. Essa etapa pode exigir várias iterações. Como a avaliação pode ser diferente com o passar do tempo, também é recomendável reavaliar as cargas de trabalho depois de fazer as primeiras implantações na nuvem.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…