Cloud Architecture Mistakes: The High Costs Of A DIY Mindset

Republicado por Platão

seguidores: 0

Esta é uma série de cinco partes sobre os erros dispendiosos que as organizações geralmente cometem ao criar uma arquitetura de nuvem. Parte um explicou como as organizações que migram para a nuvem podem perder rapidamente a visibilidade e o controle sobre o processamento de dados e detalhou como evitar esse erro. A segunda parte analisa as maneiras pelas quais fazer você mesmo pode dar errado.

O que você faria se sua empresa exigisse que você construísse um rede em nuvem com uma arquitetura à prova de futuro e design consistente em várias nuvens? (Eu mencionei que sua rede precisará fornecer segurança integrada com visibilidade e controle operacional e, além disso, otimizar custos?)

Você iniciaria uma rede complexa de scripts de automação para construir sua própria rede?

Você prefere comprar uma arquitetura de nuvem única, consistente e repetível com suporte empresarial?

De acordo com uma recente relatório da EMA, as equipes de rede multinuvem relatam dificuldade em construir uma rede consistente em sua propriedade multinuvem, com 97% das organizações enfrentando desafios significativos – principalmente monitoramento e gerenciamento de capacidade, bem como visibilidade e largura de banda – ao implementar e gerenciar conexões entre suas redes e a nuvem. Muitas empresas que executam cargas de trabalho de missão crítica preferem comprar em vez de construir esse tipo de solução.

Surpreendentemente, notei que muitas organizações mal informadas ainda cometem o erro DIY (faça você mesmo). Eles acham que podem contratar desenvolvedores, utilizar as construções nativas de rede e segurança dos CSPs e construir uma rede em nuvem usando scripts de automação. Essa é uma abordagem falha, demorada e cara. Embora existam vários desafios com essa abordagem, vamos examinar alguns dos mais críticos.

Os scripts de automação específicos do CSP, como o CloudFormation, são relevantes apenas para um determinado CSP. Eles falharão em um cenário de várias nuvens. E de acordo com um Pesquisa da Microsoft, 95% dos tomadores de decisão de negócios disseram que a multinuvem era essencial para o sucesso de seus negócios.

O suporte ao script de automação envolveria recursos críticos para executar tarefas mundanas, em vez de fazer parte do crescimento dos negócios e das iniciativas estratégicas. Esses scripts não possuem nenhum plano de controle centralizado. Não há “cérebro ou inteligência”. É principalmente executá-lo e esquecê-lo. Se as condições da rede mudarem (por exemplo, uma nova rota BGP for aprendida), o script de automação estático não poderá executar nenhuma ação com base na nova mudança de estado. Não há loop de feedback disponível.

O comportamento da rede pode mudar a qualquer momento. Você pode ter um pico exigindo que dimensione automaticamente a infraestrutura. Você pode ter um invasor tentando injetar ransomware na rede. O script de automação sem cérebro não pode se adaptar a essas mudanças.

Se o engenheiro de automação ficar doente ou deixar a organização, todo o conhecimento se foi e será quase impossível para uma nova pessoa entender e aprimorar esse script de automação.

Sem mencionar que o custo de contratar ou substituir essa pessoa está aumentando acentuadamente devido à escassez de habilidades de rede em várias nuvens.

Recomendações

Embora uma solução faça-você-mesmo possa parecer mais fácil e econômica a curto prazo, investir em uma plataforma de rede em nuvem nascida na nuvem dedicada a manter seus negócios na vanguarda irá prepará-lo para sucesso e escalabilidade a longo prazo. . As organizações devem concentrar suas equipes na inovação e no tempo de lançamento no mercado, em vez de escrever e ajustar scripts constantemente. Os benefícios a serem procurados em um fornecedor de plataforma de rede em nuvem devem incluir, no mínimo:

Um controlador centralizado com plano de dados distribuído
Controle de rede e segurança baseado em intenção e incorporado
Recursos de autocorreção com detecção de anomalias
Análise de comportamento de rede baseada em ML
Suporte robusto ao Terraform que permitiria que você escrevesse o Terraform independente do CSP
Suporte para todos os principais CSPs para executar seus aplicativos essenciais aos negócios

As armadilhas do fornecedor a serem evitadas incluem:

Os fornecedores de hardware herdados com opções imaturas e centradas em hardware que são inadequadas para cargas de trabalho modernas e críticas aos negócios
Fornecedores específicos de segurança para suas necessidades de rede em nuvem
Fornecedores tentando “lavar na nuvem” sua tecnologia de hardware herdada levantando e mudando o código de hardware como VM e chamando-a de solução de rede em nuvem

Conclusão

Fazer você mesmo na nuvem – usando a estrutura de rede e segurança nativa de um CSP e muitos scripts automatizados – pode parecer um atalho acessível a princípio, mas pode levar rapidamente a um arranjo aleatório que cria ineficiências e aumenta os custos. Os scripts somente CSP não funcionarão em um ambiente multinuvem, e os scripts automatizados desafiam o controle centralizado. Uma plataforma de rede em nuvem inteligente, por outro lado, fornece controle centralizado, recursos de autocorreção, capacidade de empregar melhor o aprendizado de máquina e suporte para todos os principais CSPs.

Em seguida: A parte três examinará os perigos de opções inadequadas de showback e chargeback, e a vantagem de ter uma solução de cobrança construída em uma plataforma agnóstica de CSP.