rip

Porquê sou contra o conceito de Multicloud

Vejo no mercado uma tendência pela opção do Multicloud. Mas, o que é multicloud?

Algo mais complexo do que uma nuvem híbrida (tipicamente um acoplamento de nuvens públicas e privadas). Multicloud adiciona mais nuvens à mistura (e ao meu ver, mais complexidade na administração e segurança).  Talvez dois ou mais provedores de IaaS (públicas) e outros de PaaS (privadas), sistemas de gestão de segurança, etc. Integra diferentes tecnologias para criar um sistema de gestão que atenda às nossas necessidades específicas.

Em uma matéria no Baguete, entitulada: “Por que não optar apenas por uma nuvem“, onde são apresentados 10 motivos para a adoção de Multicloud, os mesmos 10 motivos podem ser utilizados para a determinação de somente um provedor de nuvem. Vamos a eles:

Orquestração é a chave na gestão
“A necessidade de escala é, particularmente, importante para as empresas. Hoje, a utilização da orquestração permite, através de código e a automação, definir a infraestrutura executada em várias nuvens.”

Quando pensamos em fornecedores Cloud, a definição de escalabilidade e múltiplas regiões já faz parte dos prereqs da escolha. Provedores como AWS (Amazon), Azure (Microsoft) e Google Plataform (Google) possuem escala e várias regiões para atender as principais necessidades.

Além de que, ao manter o mesmo provedor, o nível de automação é muito menor, além da padronização. Quando atuamos com Chef, Puppet ou outra ferramenta, apesar da automação, temos que criar scripts distintos dependendo do fornecedor de Cloud. As chances de erro (usar scripts de deploy de um provedor em outro, por exemplo) tornam-se maiores.

Governança é foco no multicloud
“Hoje, os dados hoje são a maior riqueza das empresas e a forma como são tratados e protegidos são determinados pelo método de gerenciamento escolhido. Uma das vantagens da escolha pela estratégia multicloud é poder ter várias localidades e serviços de armazenamento e recuperação de dados. “

Várias localidades e serviços de armazenamento são premissas dos fornecedores de Cloud Computing. O serviço IaaS da AWS e da Azure são acessíveis (e replicáveis) em várias regiões e zonas de  disponibilidade; banco de dados MySQL, Oracle) são disponibilizados com a possibilidade de replicação em múltiplas zonas de disponibilidade. Além disto, o balanceamento de carga entre regiões e zonas de disponibilidade é muito mais efetivo se utilizarmos a ferramenta do fornecedor de nuvem – quer seja AWS, Azure, ou Google.

Armazenamento de dados se tornam resilientes
“O aprimoramento de recursos é algo fundamental na otimização de custos e desempenho com base no tempo de armazenamento. Considerando que há diferença entre os principais fornecedores de nuvens, é importante ressaltar a latência desejada, a durabilidade dos objetos e a recuperação de dados. Se a redundância é algo vital para o seu negócio, você deve considerar a utilização de diversos provedores em nuvem.”

OK. Vamos começar com a latência desejada… Quando pensamos em armazenamento de dados, pensamos em arquivos (armazenamento Blob) e banco de dados. A premissa de qualquer sistema (web ou não) é que os dados precisam estar o mais próximo possível da aplicação. Em se tratando de provedores cloud, mantendo seus dados em um provedor e sua aplicação em outro, você será taxado pelo tráfego IN-OUT de um provedor para outro, além de ter sua latência aumentada. O segundo ponto é a redundância. Serviços como o S3 da AWS possuem a opção de redundância reduzida (já que a redundância já faz parte do serviço!), além de oferecer um SLA para durabilidade de até 99,999999999% e uma disponibilidade de 99,99% de objetos.

Flexibilidade de recursos infinita
“Ao utilizar os diversos recursos oferecidos entre provedores, é possível montar táticas combinando API entre nuvens e assim proporcionar, a longo prazo, uma grande economia de recursos financeiros.”

Novamente, aumento de complexidade, já que as APIs para Cloud Computing ainda não possuem um padrão de mercado. Clouds baseadas em OpenStack (como rackspace, por exemplo) x Clouds baseadas em CloudStack x AWS. Apesar de OpenStack e CloudStack estarem adaptando suas APIs para similaridade com a AWS, ainda não são 100% compatíveis, o que não irá “proporcionar economia a longo prazo de recursos financeiros”.

Segurança fortalecida
“Com a combinação entre diversos ambientes, a segurança conquistada através da identificação e autenticação entre diversas nuvens é fortalecida dentro da sua estratégia.”

Quanto mais complexo, mais difícil manter a segurança. Fato. Por melhor que seja a camada de integração que irá realizar o controle e autenticação em duas nuvems distintas, os recursos entre elas não são os mesmos. As funcionalidades do IAM da AWS não existem na Azure. Ou seja, você terá que nivelar seus controles de segurança por baixo, ou seja, usando somente o que é comum entre os dois provedores.

Fora isto, além do controle de autenticação do “Provedor A” e do “Provedor B”, você irá acrescentar uma terceira camada de autenticação – e que irá manter os dados dos dois provedores. Ao invés de me preocupar com a segurança de acesso em somente um provedor, vou ter que me preocupar com 3 provedores.

Autonomia
“Utilizar técnicas e ferramentas para gerenciamento de múltiplas versões no código do software permite aos desenvolvedores o gerenciamento da infraestrutura e a otimização do tempo de provimento de recursos e a obtenção de escala.”

Gerenciamento de código independe de provedor. Ao utilizar ferramentas de Continuos Delivery/Deploy/Integration, como Jenkins, Buildbot ou Travis CI, estamos interagindo com o Sistema Operacional – que será responsável pelo deploy do código.

Quando falamos em gerenciamento de infraestrutura, falamos em Chef e Puppet, o que irá gerar a necessidade de um desenvolvimento maior e maior atenção no desenvolvimento e manutenção dos scripts – ou seja, desenvolvimento focado em dois códigos distintos, para fornecedores distintos.

Otimização a nível global
“O multicloud oferece a navegação entre diversos provedores ao redor da rede. Não pense apenas na disponibilidade de recursos de infraestrutura no multicloud: maximize as diversas particularidades oferecidas para obter o máximo desempenho através dos provedores.”

Azure, AWS e Google já são globais. A AWS definiu o baseline de recursos e tanto Azure como Google Plataform estão correndo atrás e disponibilizando recursos similares – mas, com APIs de gerenciamento DIFERENTES!

Qual o meu ganho em optar por dois provedores distintos? Nenhum! somente mais complexidade para gerenciamento de infraestrutura e serviços.

Portabilidade de ambiente
“A movimentação de dados e aplicativos de forma simultânea pelas empresas é primordial para implantar serviços de forma consistente e persistente, além de manter a integração do software como serviço.”

OK… Vou replicar meu banco de dados e minhas instâncias entre dois provedores. Além da enormidade do tempo de latência, temos questões como segurança (abertura de regras de firewall erradas – erro humano) e custos, já que o tráfego replicado será enorme.

Portabilidade de ambiente é feita com uma boa padronização no desenho da arquitetura de infraestrutura e de aplicações. Acessos a banco de dados, serviços como ElasticSearch, bancos de dados NoSQL, são sempre distintos quando utilizamos dois provedores diferentes.

TI como serviço
“O multicloud facilita a evolução da TI para um ‘service broker’, suportando as empresas na otimização do consumo e recursos de acordo com as melhores soluções.”

A definição de melhor consumo e recursos é relativo. Se eu optar por um banco de dados na Azure (o SQL é mais barato) e meu frontend na AWS (tenho auto-scalling e redução de custos), além da latência, vou ter um aumento de custos de tráfego…

Operações
“A fim de promover os resultados direcionados para a área de negócios, a velocidade proposta pela cloud exige que a área de operações se torne multidisciplinar e habilitada para sua operação.”

E um aumento considerável de custos em folha de pagamento e treinamento para o time. Tenho a necessidade de um recurso de infraestrutura com skill técnico em administração em multiplas plataformas de Cloud, além da necessidade de um desenvolvedor com conhecimento de diversas APIs de serviços distintas. O acréscimo na folha de pagamento é substancial.

Contratar um desenvolvedor com skill nas APIs da AWS já é difícil… Imagine achar um DEV com skill em outras nuvens!

Concluindo….

Acredito que o MultiCloud possa ser uma opção, mas não no momento. Quando uma padronização das APIs ocorrer – não somente do IaaS, mas também de segurança (como o IAM) e de serviços variados (como o Hadoop) – o MultiCloud possa tornar-se uma realidade.

Mas, no momento, continuo recomendando o desenho de uma boa RFP no momento de escolha do Provedor Cloud e um bom plano de saída (procedimentos) para quando ele não atender mais os requisitos da empresa.

 

OBS: Na dúvida sobre o “Porquê” do Título, consultei o site BrasilEscola. Acredito que tenha acertado 🙂