Antipadrões de preparação para a nuvem

Artigo
03/22/2023

Os clientes geralmente experimentam antipadrões durante a fase de preparação da adoção da nuvem. Esses antipadrões podem levar a tempo de inatividade inesperado, problemas na recuperação de desastre e problemas de disponibilidade.

Antipadrão: supor que os serviços lançados estão prontos para produção

Como a computação em nuvem está evoluindo rapidamente, as empresas geralmente lançam versões prévias de novos serviços. Os clientes tendem a presumir que podem usar qualquer serviço de nuvem disponível em um ambiente de produção. Porém, podem surgir problemas por estes motivos:

Os serviços em versão prévia geralmente não fornecem SLAs (contratos de nível de serviço) de tempo de atividade.
Novos serviços geralmente não estão tão maduros quanto os serviços de nuvem que já estão disponíveis.

Exemplo: Usar um serviço em versão prévia em produção

Um centro de pesquisa usa um serviço de nuvem em versão prévia em produção. O serviço parece ser uma boa ideia para seu caso de uso. Porém, o centro de pesquisa não realiza a devida inspeção no serviço. O centro de pesquisa também não segue os requisitos e as diretrizes da arquitetura de referência.

Ocorrem problemas com o serviço em versão prévia que levam a um tempo de inatividade inesperado. O centro de pesquisa começa a pensar que os serviços de nuvem em geral não estão tão maduros ou resilientes quanto o prometido.

Resultado preferencial: usar serviços de nuvem pré-aprovados em produção

Ao avaliar novos serviços que estejam em versão prévia, use esses serviços somente em cenários de POC (prova de conceito). Não use esses serviços em ambientes de produção, pois eles não têm SLAs. Encontre o equilíbrio certo entre a funcionalidade e a maturidade ao aprovar serviços de nuvem. Confira Lista das devidas inspeções dos serviços de nuvem para uma estrutura estabelecida que você pode usar para avaliar rapidamente os serviços de nuvem.

Antipadrão: pressupor maior resiliência e disponibilidade

A computação em nuvem geralmente oferece vantagens em relação à computação local. Os exemplos incluem:

Maior resiliência: Recuperação após falha.
Disponibilidade: Execução em um estado de integridade sem tempo de inatividade significativo.

Como a maioria dos serviços de nuvem oferece essas vantagens, muitas empresas supõem que todos os serviços de nuvem oferecem resiliência e alta disponibilidade por padrão. Na realidade, esses recursos geralmente só estão disponíveis a um custo extra e com esforço técnico adicional.

Exemplo: Pressupor alta disponibilidade

Uma start-up implementa um aplicativo crítico em serviços de IaaS (infraestrutura como serviço). Os desenvolvedores na start-up procuraram uma VM (máquina virtual) com um SLA de tempo de atividade de 99,9%. Como eles querem reduzir os custos, eles usam uma única VM e um armazenamento premium.

Quando a VM falha, seu aplicativo não pode se recuperar. A consequência é um tempo de inatividade inesperado. Eles presumiram que a nuvem oferece alta disponibilidade por padrão. Eles não estavam cientes de que as garantias de desempenho podem ser diferentes entre:

Modelos de serviço como PaaS (plataforma como serviço) e SaaS (software como serviço).
Arquiteturas técnicas como conjuntos de disponibilidade com balanceadores de carga e Zonas de Disponibilidade.

Resultado preferencial: reduzir falhas ao balancear a resiliência e os custos

Confira recursos confiáveis e maduros para obter informações sobre as melhores práticas de arquitetura que podem reduzir o escopo de falhas:

Identifique o equilíbrio certo entre custos e recursos, como alta resiliência e disponibilidade. O aumento da resiliência e da disponibilidade normalmente leva a custos maiores. Por exemplo:

Uma única VM pode ter um SLA com um tempo de atividade garantido de 99,9%.
Duas VMs que executam a mesma carga de trabalho forneceriam um SLA com um tempo de atividade entre 99,95 e 99,99%.

Envolva-se no processo essencial de engenharia de requisitos ao criar uma solução baseada em nuvem. Use um estimador de SLA para ajudar a calcular o SLA de ponta a ponta do aplicativo.

Antipadrão: tornar-se um provedor de nuvem

Algumas empresas tentam transformar seu departamento de TI interno em um provedor de nuvem. Então, a TI se torna responsável por arquiteturas de referência. A TI também precisa fornecer IaaS e PaaS para unidades de negócios. Como esse tipo de trabalho geralmente não faz parte do negócio principal da TI, as ofertas de serviço resultantes podem não ter usabilidade, resiliência, eficiência e segurança.

Exemplo: fornecer serviços de nuvem gerenciados monolíticos

O departamento de TI de uma empresa estabelece um CCoE (centro de excelência em nuvem) que serve como um agente entre as unidades de negócios e de IT. Para garantir que a empresa seja compatível com a nuvem, a diretoria atribui ao CCoE a tarefa de fornecer serviços monolíticos de ponta a ponta. O CCoE configura um portal de aquisição de nuvem interno que as unidades de negócios podem usar para solicitar uma VM de nuvem totalmente gerenciada como um serviço. Mas a TI controla quem pode acessar e usar toda a plataforma. Como resultado, a TI impede ativamente que as unidades de negócios aproveitem toda a gama de serviços que o Azure fornece. As unidades de negócios não podem acessar o portal de nuvem. Eles só têm acesso servidor que eles solicitarem por meio Secure Shell (SSH) e do protocolo RDP (Protocolo de Área de Trabalho Remota).

Por vários motivos, o CCoE tem problemas para fornecer um serviço gerenciado monolítico para encapsular cada serviço disponível na nuvem:

A nuvem oferece um grande número de serviços em várias áreas de solução. Em comparação com o desenvolvimento de soluções de IaaS, criar o design e a engenharia da Internet das Coisas (IoT) e de soluções de IA exige diferentes competências e conjuntos de habilidades.
Os serviços de nuvem mudam com frequência.
Tentar fornecer serviços monolíticos aumenta substancialmente o tempo de comercialização, com a TI gerenciando o processo, e não as unidades de negócios.

Resultado preferencial: fornecer proteções

Ao adotar tecnologias de nuvem, faça com que o departamento de TI ganhe experiência em primeira mão com a nuvem, começando com as cargas de trabalho de TI. Use o Microsoft Cloud Adoption Framework para o Azure para identificar seu primeiro projeto de adoção.

Use um modelo operacional de nuvem maduro, como operações centralizadas que torna a TI responsável por definir as proteções da plataforma, como governança. Então, as unidades de negócios podem adotar projetos de nuvem de maneira segura e consistente, dentro das proteções que a TI definir.

Considere a adoção de apenas um grande provedor de nuvem pública no início, pois todas as principais plataformas diferem significativamente na configuração, no gerenciamento e no uso.

Use soluções de SaaS tanto quanto possível para ferramentas de TI, como:

Repositórios de código.
CI/CD (integração contínua e entrega contínua).
Sistemas de colaboração.

Para cargas de trabalho de nuvem, aconselhamos a TI a usar procedimentos familiares que operam com segurança, inclusive em escala.

Share via