pode conectar duas infraestruturas em nuvem

Question

Eu quero usar o mecanismo de aplicativos, mas infelizmente eles não estão suportando suas consultas espaciais de banco de dados, por isso fiquei me perguntando se há uma maneira de criar meu banco de dados em uma nuvem, seja na AWS ou no Azure e no meu mecanismo de aplicativos

se for possível:

1. qual é a melhor prática para fazer isso?
2. quais serão as implicações de desempenho?
3. é melhor ter toda a minha solução em uma nuvem?

Answer 1

can two cloud infrastructures connect

Supondo que a sua definição de "conectar" é que as duas nuvens podem rotear o tráfego IP entre si, então, na grande maioria das circunstâncias, a resposta é: sim, é claro.

Mera conectividade IP, no entanto, não faz uma infraestrutura estável.

what is the best practice for doing so?

Qual é a "melhor prática" para construir um carro? Que tal escrever um livro? Perguntas difíceis, não são?

"A Melhor Prática" não é realmente aplicável aqui, pois há milhões de maneiras nas quais implantações distribuídas em várias nuvens podem ser arquitetadas. Em suma, depende completamente da sua aplicação específica.

what will be the performance implications?

Bem, o desempenho das consultas ao banco de dados será horrível .

is it better to have my entire solution on one cloud?

Mais uma vez, isso é completamente subjetivo. Depende das suas necessidades e da sua arquitetura de aplicativos.

De modo geral (devido aos impactos no desempenho de dividir seu aplicativo e camadas de banco de dados entre provedores), as pessoas escolherão um único provedor para hospedar o aplicativo - um que fornecerá a melhor funcionalidade para atender aos requisitos do aplicativo.

Você provavelmente deve listar todos os seus requisitos e avaliar vários provedores diferentes.

    

Answer 2

Vejo algumas coisas para pensar ao dividir um aplicativo em várias nuvens (ou entre nuvem e local):

• Latência . Se seus serviços exigirem latência previsível (e baixa), você poderá descobrir que esses tipos de serviços devem ser co-localizados. Depois de sair da rede de um provedor de nuvem, você passará pela Internet pública para a outra nuvem (ou local). Essa latência pode ser mais do que seu aplicativo pode tolerar.
• Custos de largura de banda . Com o Azure e a AWS, por exemplo, você tem dados de entrada gratuitos, mas paga pela saída. Você provavelmente verá custos bastante acessíveis em uma direção (por exemplo, solicitações de banco de dados) e custos de largura de banda maiores na outra (cargas de dados).
• Manutenção . Cada provedor de nuvem tem seu próprio modelo e API para manutenção de aplicativo / VM / banco de dados. Seu ambiente de devops precisará responder por isso. O mesmo para abordagens de backup.
• Segurança . Assim como conectar-se com recursos locais, você precisará pensar sobre a conectividade entre nuvens (você pode criar um túnel seguro ou usar SSL?) E controle de acesso (você pode proteger endpoints de serviços de backend como banco de dados e cache?) .
• Alta disponibilidade / recuperação de desastres . Cada provedor de nuvem oferecerá opções específicas para o HA & DR pelos seus serviços (e os seus). Você precisará considerar cuidadosamente cada um.

Tenho certeza de que há outras coisas a serem consideradas - espero que essa lista ajude.

Conclusão: arquiteturas híbridas (cloud < - > on-prem, cloud < - > cloud) existem hoje e seus requisitos específicos ajudarão você a determinar se isso funcionará para você.