A optimização de uma arquitectura multi-nuvem, em termos simples, é a capacidade de configurar a tecnologia para optimizar a arquitectura para os requisitos do negócio, bem como para minimizar os custos. Para cada euro gasto em tecnologia de nuvem, pretende-se que o valor máximo regresse ao negócio. A verdade é que poucas arquitecturas de nuvem são totalmente optimizadas. Falei da tendência para a complexidade como um dos principais culpados. No entanto, a causa principal está à espera de pensar na optimização da arquitectura até que esta esteja implantada e em funcionamento. Até lá, é demasiado tarde.

Então, quais são as principais razões pelas quais a arquitectura multi-nuvem fica muito aquém de ser totalmente optimizada? Aqui estão apenas três:

Alavancar demasiada tecnologia. Um primo da complexidade é um excesso. Arquitectos e equipas de desenvolvimento multi-nuvem tentam frequentemente atirar o máximo de tecnologia possível para a mistura multi-nuvem, normalmente para todos os tipos de requisitos que “possam” materializar-se. Pode precisar apenas de uma tecnologia de governação de serviços, mas está a utilizar três. Pode escapar com um recurso de armazenamento, mas tem sete. Acaba com mais custos e sem valor adicional para o negócio.
Este é um problema difícil de resolver porque a maioria dos arquitectos está a tentar construir para um futuro que ainda não chegou. Escolhem uma base de dados com tecnologia de espelhamento integrada porque podem passar para bases de dados totalmente distribuídas, embora provavelmente não o façam por mais alguns anos. Assim, o número de tipos de bases de dados passa de duas para quatro sem uma razão realmente boa. Tenha em mente que deve estar a construir para uma “viabilidade mínima” para se aproximar de um estado optimizado.

Não construir para requisitos específicos. Os requisitos – estritos, detalhados e imediatos – são bem compreendidos porque determinam principalmente o que será a sua arquitectura multi-nuvem. Eles esboçam os padrões de problemas que a arquitectura precisa de resolver. Contudo, vejo um grande número de projectos multi-nuvem que estão a tentar conceber e construir para requisitos gerais que têm pouca base no que a empresa precisa agora.

Eu sei que esta é a resposta “depende” que as pessoas odeiam de nós consultores. No entanto, a fim de avançar para uma optimização total, os requisitos determinam a sua arquitectura multi-nuvem mínima viável, e não o contrário.

Não arquitectar para a mudança. Aqueles encarregados de construir multi-nuvens, mesmo que estejam a aproximar-se da plena optimização, muitas vezes negligenciam a compreensão de como projectar para agilidade. Aqui, agilidade significa compreender que parte da arquitectura precisa de se adaptar facilmente às mudanças que irão ocorrer no futuro. Numerosos truques de arquitectura conseguem isto, e os conceitos básicos são bastante fáceis de compreender.

Certifique-se de colocar a volatilidade num domínio. Procura-se evitar uma remodelação completa de uma base de dados ou aplicação em torno de alterações simples, por exemplo. Digamos que está a aproveitar a virtualização de dados entre as bases de dados e as aplicações, permitindo-lhe alterar o esquema virtual tantas vezes quantas forem necessárias para utilizar uma ferramenta de mapeamento, sem forçar alterações dispendiosas e arriscadas às bases de dados físicas na multi-nuvens.

A arquitectura continua a ser mais arte do que ciência. No entanto, ao compreender as melhores práticas emergentes, as pessoas que concebem e constroem multi-nuvens podem devolver muito mais valor ao negócio. Esse é o objectivo. SpikeCloud sabe como ultrapassar estes problemas e fazer sucesso para todos e cada um dos negócios.