Ao determinar sua estratégia de computação em nuvem, é importante compreender que não existem duas situações comerciais iguais. As organizações podem ter diversas áreas de especialização, diferentes pressões comerciais, experiências, estruturas de equipe, responsabilidades e assim por diante.
Embora algumas empresas “nasçam na nuvem” ou já tenham fortes capacidades de nuvem, outras organizações podem ser levadas para a nuvem através dos chamados “fatores de impulso”, como produtos de infraestrutura crítica que eliminam gradualmente o suporte, ou “fatores de atração”, como como falta de CapEx disponível para investimento em servidores físicos.
A migração para nuvem é o processo pelo qual uma organização realoca parte ou todos os seus dados, aplicativos e cargas de trabalho para uma infraestrutura em nuvem.
Este artigo discutirá estratégias de migração para nuvem de alto nível para ajudá-lo a escolher a abordagem mais adequada para o seu negócio.
Depois que uma organização determina que está pronta para migrar para a nuvem, há uma série de decisões específicas ao contexto a serem tomadas. Ter uma estratégia geral e orientadora é fundamental.
Definir seus objetivos e os problemas que você espera resolver por meio de sua estratégia de migração para a nuvem pode ajudar a garantir que suas estratégias de negócios e tecnologia estejam alinhadas. o que esperas conseguir?
Esses fatores são críticos para determinar como deve ser sua estratégia de migração para a nuvem.
Para uma organização relativamente pequena com um conjunto homogêneo de requisitos de carga de trabalho, uma estratégia de nuvem de fornecedor único pode ser mais apropriada, pois há pouca necessidade de investir em vários fornecedores de nuvem para redundância técnica ou para evitar a dependência de um fornecedor.
Uma organização muito maior, como um banco global com cargas de trabalho diversas e níveis variados de requisitos técnicos, teria maior probabilidade de seguir uma estratégia multinuvem, pois isso daria a cada equipe de projeto a flexibilidade para escolher o fornecedor que melhor atende às suas necessidades. . Além disso, é mais provável que as organizações maiores tenham requisitos internos e externos de Conformidade para cumprir, e estes podem exigir a capacidade de mover cargas de trabalho entre fornecedores de nuvem num prazo relativamente curto.
Uma estratégia híbrida, na qual estejam envolvidos um centro de dados tradicional e um fornecedor de nuvem, também pode fazer sentido para empresas de médio a grande porte, especialmente se a transição para a nuvem durar vários anos. Essa estratégia também pode ser relevante se houver necessidade de evoluir suas táticas de migração para a nuvem de forma mais dinâmica, à medida que você aprende mais sobre a implementação de tecnologias de nuvem em sua empresa.
Depois de determinar suas metas de migração para a nuvem e a estratégia do fornecedor, a próxima etapa é decidir como proceder para migrar suas cargas de trabalho para a nuvem.
Primeiro, você desejará realizar uma auditoria em seu aplicativo existente. Isso pode lhe dar uma ideia do nível e da natureza do trabalho necessário para migrar para a nuvem. Durante esta auditoria, você pode classificar seu aplicativo com base na abordagem que deseja que as equipes responsáveis por ele adotem na migração para a nuvem. A AWS descreve seis “estratégias de migração comuns. Estas podem ser aplicadas de forma generalizada ou cada equipa pode escolher a estratégia mais adequada à sua configuração específica no momento, dependendo do tamanho da organização e da complexidade envolvida.
A primeira e mais simples estratégia é rehospedar seu aplicativo (também conhecido como “lift and shift”). Envolve movê-los de servidores físicos executados em um centro de dados para servidores virtuais executados na nuvem. Geralmente, isso não requer alterações no código e relativamente poucas alterações nos processos e nas tecnologias vizinhas, como redes. Também pode permitir que sua organização desenvolva as habilidades e a experiência em nuvem necessárias para outras práticas nativas em nuvem.
Também conhecida como “lift, tinker and shift”, esta abordagem é semelhante à rehospedagem, mas vai um passo além ao integrar uma série de serviços de nuvem fundamentais no nível do aplicativo. Por exemplo, o AWS IAM (Identity and Access Management) pode ser integrado ao seu aplicativo para substituir ou complementar sistemas IAM mais tradicionais orientados ao centro de dados.
Também conhecida como “drop and shop”, esta abordagem envolve a substituição de um aplicativo local existente por um serviço licenciado baseado em nuvem. Isso pode envolver a mudança do modelo de licenciamento que sua empresa usa, reduzindo o custo de manutenção e potencialmente permitindo um caminho mais rápido e fácil para a atualização.
Uma abordagem mais nativa da nuvem é pegar suas bases de código existentes e modificá-las ou estendê-las para funcionarem em serviços de nuvem mais modernos. Um exemplo é conteinerizar o código do seu aplicativo, executar a configuração e executá-lo em um serviço Kubernetes baseado em nuvem, como o EKS da Amazon ou o AKS do Azure. Isso pode envolver reescritas substanciais em sua base de código existente para permitir que ela funcione e aumente a escalabilidade; uma reescrita completa pode até ser necessária para usar ferramentas verdadeiramente nativas da nuvem (por exemplo, ferramentas sem servidor como AWS Lambda ou Azure Functions).
Com as duas últimas estratégias “passivas”, as cargas de trabalho não são migradas para a nuvem. Sua auditoria de carga de trabalho pode revelar sistemas redundantes ou que não valem mais a pena manter. Esses aplicativos podem ser retirados.
A estratégia “passiva” final, retenção, envolve manter seu aplicativo em execução e optar por não migrá-lo para a nuvem no futuro próximo. Existem vários motivos possíveis para manter seu aplicativo fora da nuvem, incluindo:
Além de decidir sua estratégia geral e classificar a abordagem tática por carga de trabalho, você precisará de um plano para construir sua infraestrutura em nuvem para dar suporte à movimentação de cargas de trabalho. Uma abordagem é deixar que cada equipe escolha como construir seus próprios sistemas na nuvem. Existem, no entanto, várias desvantagens nesta abordagem, pois as equipas podem duplicar antipadrões de implementação e repetir os erros umas das outras ou violar regras internas/externas de Conformidade.
Uma abordagem alternativa é criar uma espécie de “centro de excelência” centralizado ou equipe de infraestrutura em nuvem. Essa equipe pode optar por estabelecer os sistemas principais nos quais outras equipes poderão executar suas cargas de trabalho.
Quando se trata de estabelecer esses guarda-corpos, existem certos elementos de design que devem ser priorizados em detrimento de outros.
A unidade mais básica da sua arquitetura de nuvem é a conta da nuvem. Usar uma conta em toda a sua organização quase sempre não consegue escalar, pois você acaba esbarrando nos limites da conta. Portanto, é importante determinar os limites da conta. A conta será usada para representar uma unidade de negócios específica, uma equipe individual ou um agrupamento de serviços de software? Como isso funcionará com seu departamento financeiro? Quem deve receber a conta? É importante descobrir isso desde o início, pois os custos podem aumentar rapidamente.
A próxima unidade mais básica da arquitetura é o sistema de gerenciamento de identidade e acesso . À medida que sua infraestrutura em nuvem cresce, você precisará considerar as implicações de segurança do acesso do usuário aos diversos serviços e dados em nuvem, e quanto mais cedo melhor. A imposição destas regras retrospetivamente a sistemas que já estão em funcionamento pode ser complicada.
A migração para a nuvem envolve a virtualização da sua rede existente ou uma reformulação completa. O serviço VPC (AWS) ou VNet (Azure) permite configurar uma rede isolada para executar um conjunto separado de serviços em sua conta. É necessário considerar cuidadosamente a comunicação entre redes entre os serviços da sua organização e os recursos básicos de rede, como endereços IP.
Embora seja fácil migrar serviços de computação para a nuvem, a migração de dados pode ser um pouco mais desafiadora. Os principais armazenamentos de dados podem ser infraestruturas grandes e complexas que exigem um planejamento cuidadoso para serem movimentadas. Isso requer um conhecimento profundo o suficiente de como mover seus dados para a nuvem e, ao mesmo tempo, estar em conformidade com os padrões de desempenho, conformidade e operabilidade da sua organização.
Depois que você tiver clareza sobre sua estratégia de nuvem de alto nível, o desenvolvimento de uma estratégia de migração para a nuvem bem-sucedida requer planejamento meticuloso e consideração de todos os aspectos do seu negócio. Escolher a estratégia de fornecedor de nuvem certa para você – seja uma migração direta de um único fornecedor, uma abordagem de vários fornecedores de nuvem ou uma estratégia híbrida – é o próximo passo. Por fim, você desejará arquitetar sua migração para a nuvem considerando primeiro os principais componentes de infraestrutura antes de começar a integrar o aplicativo.
Espero que esta postagem do blog tenha sido interessante e valiosa.
Fique atento às próximas postagens do blog sobre contêineres/Kubernetes e serviços sem servidor.
Se você está começando sua jornada para a nuvem, talvez queira ler meu novo white paper sobre Cinco práticas recomendadas para migração segura para a nuvem.
Você pode ler mais sobre as soluções de Segurança de nuvem da Check Point aqui ou agendar uma demo com um dos engenheiros de Segurança de nuvem da Check Point aqui.
Para entender como projetar e implementar arquiteturas de nuvem seguras, confira este white paper.