Escrito por David Linthicum, considerado um dos maiores pioneiros em Cloud Computing.
Eu desenvolvi aplicações distribuídas por anos. Em termos simplistas, você divide uma aplicação e dados em partes que são executadas nas plataformas, fornecendo o melhor desempenho e confiabilidade possível.
Antigamente, aplicávamos em plataformas de hardware menores, como servidores baseados em x86. Precisávamos de distribuição. Usando o processamento distribuído, nós conseguimos escalar para cargas de processamento maiores e configurar sistemas de failover ativo/ativo onde um sistema pode fazer backup instantâneo do outro no caso de uma interrupção.
Muito disso não foi necessário quando as nuvens públicas chegaram na cena.
Intracloud
Nuvens públicas fizeram a distribuição de sistemas automaticamente para as pessoas, usando gerenciamento de locatário e fornecendo escalabilidade e resiliência, uma vez que você pode configurar virtualmente qualquer plataforma ou configuração de plataforma. Isso é chamado de intracloud.
Agora que multicloud é uma tópico bem comentado, continuo recebendo a pergunta: Há algum motivo para colocar partes de um aplicativo ou os dados em diferentes marcas de nuvem? Se sim, quais são as melhores práticas?
Linthicum não recomenda
Provavelmente, a melhor maneira de responder a essa pergunta é examinar um exemplo. Digamos que temos um aplicativo de vendas no varejo com o processador de interface do usuário em execução no AWS, o banco de dados em execução no Google e o sistema central de processamento de transações em execução na Microsoft. Dividido ainda mais, partes do aplicativo são executadas no local e mais subprocessamento é executado na AWS e no Google.
Essa configuração pode ser feita para funcionar. Mas eu teria preocupações reais sobre viabilidade, operações de longo prazo, complexidade e custo, sem mencionar a segurança. Em outras palavras, podemos fazer funcionar, mas devemos?
Alguns motivos pelo qual essa estratégia não é a melhor opção:
1. Seu aplicativo se torna mais vulnerável a interrupções
Por não colocar todos os ovos em uma única cesta de nuvem, pode-se pensar que um aplicativo se tornaria mais resistente a interrupções. Esse pode ser o caso de aplicativos executados de forma redundante em marcas de nuvem. No entanto, se você distribuir um único aplicativo em duas ou mais nuvens, o oposto é verdadeiro. Se uma das nuvens cair, o aplicativo para porque todos os processos devem ser executados para que funcione.
2. A segurança se torna muito mais complexa
É fácil ativar um sistema de segurança nativo da nuvem em um provedor de nuvem pública para um aplicativo executado nesse provedor. Para aplicativos distribuídos em nuvem cruzada, você terá que aproveitar a segurança nativa em cada nuvem para proteger os componentes e dados do aplicativo ou encontrar alguma solução de segurança comum que possa abranger todas as nuvens públicas. Cada abordagem significa mais custo e risco.
3. Custo mais alto do que desejado pelas empresas
Você pode executar circuitos privados de um provedor de nuvem para outro, mas a maioria das empresas não aceita o custo para fazer isso. Eles logo descobrem que a natureza explosiva da Internet aberta causa problemas de comunicação ponto a ponto que impedem a produção. Além disso, os provedores de nuvem cobram para você enviar e receber dados de e para uma nuvem pública. Você precisa entender como projetar essas despesas, e se sua empresa procura por redução de custos, essa não é a opção certa.
Estou no mercado Cloud desde 1999 e só vi a verdadeira necessidade de uma distribuição entre nuvens duas vezes. Analise, com atenção, sua própria implantação proposta.
Este artigo foi traduzido de InfoWord
Conheça o serviço de Consultoria em Nuvem que a dataRain oferece e entre em contato!
