Antipadrões de preparação para a nuvem
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 de recuperação de desastres e problemas de disponibilidade.
Antipadrão: Suponha que os serviços liberados 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. Mas, problemas podem resultar, por estas razões:
- Os serviços de visualização geralmente não fornecem contratos de nível de serviço (SLAs) de tempo de atividade.
- Os novos serviços muitas vezes não estão tão maduros quanto os serviços em nuvem que já estão disponíveis.
Exemplo: Usar um serviço de visualização em produção
Um instituto de pesquisa usa um serviço de nuvem de visualização em produção. O serviço parece ser um bom ajuste para o seu caso de uso. Mas, o instituto não realiza diligências sobre o serviço. O instituto também não segue os requisitos e diretrizes de sua arquitetura de referência.
Problemas surgem com o serviço de visualização que levam a um tempo de inatividade inesperado. O instituto começa a pensar que os serviços em nuvem em geral não são tão maduros ou resilientes quanto prometido.
Resultado preferido: usar serviços de nuvem pré-aprovados na produção
Ao avaliar novos serviços que estão em visualização, use esses serviços apenas em cenários de prova de conceito (POC). Não use esses serviços em ambientes de produção, porque eles não têm SLAs. Encontre o equilíbrio certo entre funcionalidade e maturidade ao aprovar serviços em nuvem. Consulte Lista de verificação de diligência devida de serviços de nuvem para obter uma estrutura estabelecida que você pode usar para avaliar rapidamente os serviços de nuvem.
Antipadrão: Assuma maior resiliência e disponibilidade
A computação em nuvem geralmente oferece vantagens sobre a computação local. Exemplos incluem:
- Maior resiliência: Recuperação após falha.
- Disponibilidade: Execução em um estado íntegro sem tempo de inatividade significativo.
Como a maioria dos serviços de nuvem oferece essas vantagens, muitas empresas assumem que todos os serviços de nuvem oferecem resiliência e alta disponibilidade por padrão. Na realidade, muitas vezes, estas funcionalidades só estão disponíveis a um custo adicional e com esforço técnico adicional.
Exemplo: Suponha alta disponibilidade
Uma start-up implementa um aplicativo de missão crítica em serviços de infraestrutura como serviço (IaaS). Os desenvolvedores na start-up analisaram uma máquina virtual (VM) com um SLA de tempo de atividade de 99,9%. Como eles gostariam de cortar custos, eles usam uma única VM e armazenamento premium.
Quando a VM falha, seu aplicativo não pode se recuperar. Resultados inesperados de tempo de inatividade. Eles presumiram que a nuvem oferece alta disponibilidade por padrão. Eles não estavam cientes de que as garantias de desempenho podem diferir entre:
- Modelos de serviço como plataforma como serviço (PaaS) e software como serviço (SaaS).
- Arquiteturas técnicas, como conjuntos de disponibilidade com balanceamento de carga e zonas de disponibilidade.
Resultado preferido: reduzir falhas enquanto equilibra resiliência e custos
Consulte recursos confiáveis e maduros para obter informações sobre práticas recomendadas 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 ao aumento dos custos. Por exemplo:
- Uma única VM pode ter um SLA com um tempo de atividade garantido de 99,9%.
- Duas VMs executando 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 projetar uma solução baseada em nuvem.
Antipadrão: Torne-se um provedor de nuvem
Algumas empresas tentam tornar seu departamento interno de TI um provedor de nuvem. A TI torna-se então responsável pelas 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 core business da TI, as ofertas de serviços 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 corporação estabelece um centro de excelência em nuvem (CCoE) que serve como um intermediário entre as unidades de TI e de negócios. Para garantir que a corporação esteja em conformidade com a nuvem, o conselho de administração atribui ao CCoE a tarefa de fornecer serviços monolíticos de ponta a ponta. O CCoE configura um portal interno de compras na nuvem 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 na nuvem. Eles só obtêm acesso através do Secure Shell (SSH) e do Remote Desktop Protocol (RDP) ao servidor que eles encomendam.
Por vários motivos, o CCoE tem problemas para fornecer um serviço gerenciado monolítico para envolver 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 IaaS, projetar e projetar soluções de Internet das Coisas (IoT) e IA requer diferentes conhecimentos e conjuntos de habilidades.
- Os serviços na nuvem mudam frequentemente.
- Tentar fornecer serviços monolíticos aumenta substancialmente o tempo de comercialização, com a TI gerenciando o processo, não as unidades de negócios.
Resultado preferido: Fornecer guarda-corpos
Ao adotar tecnologias de nuvem, peça ao departamento de TI que ganhe experiência em primeira mão com a nuvem, começando com cargas de trabalho de TI. Use o Microsoft Cloud Adoption Framework for 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 pela definição de guardrails de plataforma, como governança. Em seguida, as unidades de negócios podem adotar projetos em nuvem de forma segura e consistente, dentro dos guardrails que a TI define.
Considere adotar apenas um grande provedor de nuvem pública no início, porque todas as principais plataformas diferem significativamente em configuração, gerenciamento e uso.
Use soluções SaaS tanto quanto possível para ferramentas de TI, tais como:
- Repositórios de código.
- Integração contínua e entrega contínua (CI/CD).
- Sistemas de colaboração.
Para cargas de trabalho na nuvem, aconselhe a TI a usar procedimentos familiares que operem com segurança e em escala.