A otimização de uma arquitetura multicloud, simplesmente, é a capacidade de configurar a tecnologia para otimizar a arquitetura para os requisitos de negócios, bem como para minimizar custos. Para cada dólar gasto em tecnologia de nuvem, você deseja o valor máximo voltando para o negócio. A verdade é que poucas arquiteturas de nuvem são totalmente […]
A otimização de uma arquitetura multicloud, simplesmente, é a capacidade de configurar a tecnologia para otimizar a arquitetura para os requisitos de negócios, bem como para minimizar custos. Para cada dólar gasto em tecnologia de nuvem, você deseja o valor máximo voltando para o negócio.
A verdade é que poucas arquiteturas de nuvem são totalmente otimizadas. Há um certo preconceito em relação à complexidade como o principal culpado. No entanto, a causa raiz está esperando para pensar sobre a otimização da arquitetura até que ela seja implantada e em operação. Até então, é tarde demais.
Então, quais são os principais motivos pelos quais a arquitetura multicloud fica aquém de ser totalmente otimizada? Aqui estão apenas três e como abordá-los:
Um primo da complexidade é o excesso. Os arquitetos e equipes de desenvolvimento de várias nuvens frequentemente tentam adicionar o máximo de tecnologia possível na combinação de várias nuvens, normalmente para todos os tipos de requisitos que “podem” se materializar. Você pode precisar de apenas uma tecnologia de governança de serviço, mas está usando três. Você pode se safar com um recurso de armazenamento, mas tem sete. Você acaba com mais custo e nenhum valor adicional para o negócio.
Este é um problema difícil de resolver porque a maioria dos arquitetos está tentando construir para um futuro que ainda não chegou. Eles escolhem um banco de dados com tecnologia de espelhamento embutida porque podem migrar para bancos de dados totalmente distribuídos, embora provavelmente só daqui a alguns anos. Portanto, o número de tipos de banco de dados vai de dois a quatro sem um bom motivo. Lembre-se de que você deve estar construindo uma “viabilidade mínima” para chegar perto de um estado otimizado.
Requisitos – requisitos estritos, detalhados e imediatos – são bem compreendidos porque determinam principalmente como será sua arquitetura multicloud. Eles descrevem os padrões de problemas que a arquitetura precisa resolver. No entanto, vejo um grande número de projetos multicloud que estão tentando projetar e construir para requisitos gerais que têm pouca base no que o negócio precisa agora.
Eu sei que esta é a resposta “depende” que as pessoas odeiam de nós, consultores. No entanto, para avançar em direção à otimização total, os requisitos determinam sua arquitetura multicloud mínima viável, e não o contrário.
Os encarregados de criar multiclouds, mesmo que estejam se aproximando da otimização total, geralmente negligenciam a compreensão de como projetar para agilidade. Aqui, agilidade significa entender que parte da arquitetura precisa se adaptar facilmente às mudanças que ocorrerão no futuro. Vários truques de arquitetura fazem isso, e os conceitos básicos são muito fáceis de entender.
Você está procurando evitar um refazer completo de um banco de dados ou aplicativo em torno de mudanças simples, por exemplo. Digamos que você esteja aproveitando a virtualização de dados entre os bancos de dados e aplicativos, permitindo que você mude o esquema virtual quantas vezes você precisar para usar uma ferramenta de mapeamento, sem forçar mudanças caras e arriscadas nos bancos de dados físicos na multicloud.
Isso é um pouco diferente de implantar muita tecnologia, já que a mudança – incluindo o grau e a frequência – é um requisito. Não se trata de assumir ou fazer uma cobertura de apostas.
A arquitetura continua a ser mais arte do que ciência. No entanto, ao compreender as melhores práticas emergentes, as pessoas que projetam e constroem multiclouds podem retornar muito mais valor ao negócio. Esse é o objetivo.
