Clusters multinuvem do MongoDB Atlas
Avalie esse podcast
Neste capítulo do podcast, Nic e eu nos juntamos a Andre Davidson, VP de cloud Product no MongoDB. Andrew compartilha alguns detalhes das últimas
inovação no MongoDB Atlas e fala sobre algumas das maneiras como multi-cloud
clusters podem ajudar os desenvolvedores.
michael lynn (00:00): bem-vindo ao podcast. Neste capítulo, nós dois nos reunimos com Andrew Davidson, VP de produtos de nuvem do MongoDB.
Estamos falando hoje sobre a mais recente novidade incorporada no MongoDB Atlas, nosso banco de dados como serviço multinuvem. Então, isso lhe dá o
capacidade de implantar e gerenciar suas instâncias do MongoDB na nuvem
entre os três principais provedores de nuvem: AWS, Azure e GCP. andrew nos conta tudo sobre essa novidade, como ela pode ser usada e alguns de seus benefícios. Portanto, fique atento. Esperem que tenham aproveitado o capítulo.
michael lynn (00:52): andrew davidson, VP de produto de nuvem do MongoDB.
Como vai, senhor?
andrew davidson (00:57): Que bom ver você, mike. Estou indo muito bem.
Obrigado. Foram duas semanas agitadas e estou superanimado por estar
aqui para falar com vocês sobre o que temos feito.
michael lynn (01:05): Com certeza. Vamos falar sobre multinuvem hoje e novidade adicionada ao MongoDB Atlas. Mas antes de chegarmos lá,
Andrew, gostaria de saber se você poderia explicar ou se apresentar a
o público. Quem é você e o que você faz?
andrew davidson (01:19): Sim. Sim. Sim. Então, como Mike me apresentou anteriormente, eu sou VP de produtos de nuvem aqui na MongoDB, o que basicamente significa que eu me concentro em nossos negócios de nuvem e no que estamos trazendo para o mercado para nossos clientes, e também pensando em como esses serviços para nossos clientes evoluem ao longo do tempo e o roteiro em torno deles e como nós os explicamos para o mundo também e como nossos usuários os usam e, ao longo do tempo, crescem neles em profunda parceria conosco. Então, estou no MongoDB há algum tempo, oito anos. Nesse tempo, realmente
Eu meio que vi essa grande mudança que todos os envolvidos no MongoDB tiveram
parte da mudança do nosso DNA de ser mais uma empresa de software para
sendo uma verdadeira empresa de nuvem. Foi uma realmente uma viagem de cinco anos nos últimos cinco anos. Para mim, este anúncio que fizemos na semana passada que
Mike estava apenas aludindo a isso é realmente o culminar de muitas maneiras disso
viagem. Então não poderia estar mais animado.
michael lynn (02:12): Sim, fantástico. Oito anos. Oito anos em uma empresa de software é a vida inteira. Você estava no Google antes disso. O que você fez no Google?
andrew davidson (02:23): eu estava envolvido em uma equipe especial. Eles são
chamados de Ground Truth. Estava remapeando o mundo e era tudo sobre
criar um novo conjunto de dados de mapas usando o Street View exclusivo do Google e outros
entradas para basicamente fazer todos os mapas que você utiliza todos os dias em
O Google mapeia melhor e para que o Google seja capaz de evoluir esse conjunto de dados
Rápido. Portanto, foi um projeto muito humano que envolveu milhares de pessoas
operadores fazendo uma enorme quantidade de trabalho complexo porque o fundo
linha era, isso não é algo que você poderia fazer com ML naquele momento
de qualquer maneira. Estou certo de que eles evoluíram um pouco desde então. Já faz muito tempo.
michael lynn (02:59): fantástico. Então, em seus oito anos, que outras coisas você fez no MongoDB?
Andrew Davidson (03:05): Então, eu realmente comecei a focar em nosso software tradicional de gerenciamento local, algo chamado MongoDB Ops Manager, que era meio que o principal diferencial em nossa empresa oferta avançada. Naquela época, a empresa estava mais focada em
essencialmente, monetizando a decolagem, por meio da TI tradicional
Operações. Embora sempre tratássemos de desenvolvedores e desenvolvedores
estávamos sempre construindo novos aplicativos excelentes no banco de dados, de certa forma,
meio que mudamos nosso foco de uma perspectiva de monetização para uma
visão mais centrada nas operações, e eu fui uma grande parte disso. Mas eu era capaz de
fazer essa mudança e meio que recentralizar, recentralizar no desenvolvedor quando
meio que mudou para uma verdadeira plataforma de cloud e isso tem sido muito divertido
desde então.
michael lynn (03:52): Sim. Viagens incríveis. Então do Ops Manager para o Atlas. Quero estar ciente de que nem todos os nossos ouvintes serão
familiarizado com o Atlas. Então, talvez descreva o que é Atlas da sua perspectiva.
Andre Davidson (04:08): Totalmente. Sim. O MongoDB Atlas como um serviço global de banco de dados em nuvem. Ele está disponível nos três grandes provedores de nuvem, AWS, Google Cloud e Azure. E é verdadeiramente elástico e declarativo,
o que significa que você pode descrever um cluster de banco de dados em qualquer parte do mundo, em
qualquer região, regiões 79 entre os três fornecedores e o Atlas faz todas as
trabalho pesado para chegar lá, para fazer o gerenciamento do ciclo de vida. Você pode fazer infraestrutura como código, pode gerenciar seus clusters de banco de dados no Terraform ou pode usar nossa bonita interface de usuário para aprender e implementar. Percebemos que não basta ter um serviço de banco de dados elástico.
Esse é o ponto de partida. Também não é suficiente ter o melhor banco de dados moderno, um que é tão nativo para os desenvolvedores, um que fala com esse rico modelo de dados do MongoDB com os índices secundários e todo o resto.
Realmente, precisávamos Go além do banco de dados.
Andrew Davidson (04:54): Então, nos concentramos fortemente em ajudar nossos clientes
com orientação prescritiva, conselhos de esquema, sugestões de índice e você
nos ver continuar evoluindo lá, porque reconhecemos que realmente a cada semana,
Dezenas de milhares de pessoas estão entrando na plataforma pela primeira vez
Hora. Precisamos apenas diminuir a barreira de entrada para construir com sucesso
aplicativos no banco de dados. Também aumentamos o Atlas com expansões de plataforma chave incluindo pesquisa. Temos índices de pesquisa baseados em Lucene agora nativos do Atlas. Portanto, você não precisa ETL esses dados para um
mecanismo de pesquisa e, basicamente, construa a pesquisa diretamente em seu operacional
Aplicativos. Temos um arquivo on-line para classificação de dados em objetos economia de armazenamento. Com o MongoDB Realm, agora temos sincronização desde o banco de dados móvel Realm e serviços de acesso a dados, todos nativos da plataforma. Então é tudo muito emocionante, mas fundamentalmente
o que estava faltando até a semana passada era o verdadeiro multi-cloud
clusters, a capacidade de misturar e combinar esses bancos de dados nas nuvens
ter réplicas que abrangem os provedores de nuvem ou mover-se perfeitamente
de um provedor para outro sem tempo de inatividade, sem alteração na conexão
corda. Então isso é realmente emocionante.
Nic Raboy (06:02): Ei, Andrew, tenho uma pergunta para você. Esta é uma pergunta que recebai um pouco. Então, ao configurar seu Atlas cluster, é claro que você será solicitado a escolher entre Amazon, Google e Microsoft para sua hospedagem. Você poderia falar sobre como isso é
diferente ou para que realmente serve em comparação com a multinuvem
de que estamos falando hoje?
andrew davidson (06:25): Sim, com certeza. Olha, sendo intelectualmente honesto,
a maioria dos nossos clientes, a maioria dos desenvolvedores, a maioria dos membros da comunidade
tem uma plataforma de nuvem preferida e todas as plataformas de nuvem são ótimas
à sua maneira. Eu acho que eles brilham de muitas maneiras. Há muitos motivos pelos quais as pessoas começarão no Google, no Azure ou na AWS. Normalmente, há esse fornecedor preferencial. Portanto, a maioria dos usuários implantará um Atlas cluster em seu provedor de destino, onde fica sua outra infraestrutura, onde fica sua camada de aplicativos etc.
É onde o mundo está hoje em grande parte. No entanto, sabemos que
estamos meio que no limite de uma nova mudança que está acontecendo em
esse mercado em que, com o tempo, as pessoas começarão cada vez mais,
misture e aproveite o melhor dos diferentes provedores de nuvem.
Então eu acho que essas expectativas estão começando a mudar e com o tempo,
você provavelmente nos verá aumentar a proeminência da opção multinuvem como
o mercado meio que se move para lá também.
Michael Lynn (07:21): Então, isso está disponível hoje e que outros
requisitos estão lá se eu quiser implantar uma instância do MongoDB e
Aproveitar a multinuvem?
andrew davidson (07:30): Sim, essa é uma ótima pergunta. Fundamentalmente,
para usar o cluster de banco de dados multinuvem, acho que meio que
depende do seu caso de uso e do que você está tentando alcançar. Mas, de modo geral, o banco de dados isolado em um fornecedor de nuvem não é suficiente. Você precisa usar algo que esteja se conectando e usando isso
banco de dados. Portanto, em termos gerais, você vai querer ter uma
camada de aplicativo que seja capaz de conectar o banco de dados e, se você estiver
em várias nuvens e estiver fazendo isso por vários motivos, como
por exemplo, resiliência de alta disponibilidade para poder resistir ao
de um provedor de nuvem completa, bem, então você desejaria que sua camada de aplicativo
também seja multi-cloud.
Andrew Davidson (08:03): Esse é o tipo de coisa que tradicionalmente,
as pessoas não achavam que era fácil, mas está ficando mais fácil o tempo todo.
É por isso que meio que... Estamos abrindo isso na camada de dados e
então outras, a plataforma Kubernetes, etc., estão realmente se abrindo
essa portabilidade no nível do aplicativo e realmente tornando isso possível para o
mercado. Mas antes, continuamos nos concentrando em onde estamos.
hoje, acho que não faria mal retroceder um pouco e conversar
sobre por que a multinuvem é tão difícil.
michael lynn (08:32): Isso faz sentido.
Andrew Davidson (08:35): Houve duas razões principais pelas quais
Multi-cloud é tão difícil. Eles meio que se resumem aos dados e à quantidade de dados.
a gravidade que existe. É claro que é isso que nosso anúncio diz sobre mudar. Em outras palavras, seus dados devem ser armazenados em uma cloud ou
outro, ou tradicionalmente tinha que ser. Então, na verdade, movendo esses dados para
outra cloud ou torná-la presente ou disponível na outra cloud, que
era extremamente difícil e, tradicionalmente, fazia com que as pessoas simplesmente
senti que a multicloud era essencialmente inviável. O segundo motivo principal
tradicionalmente, a multinuvem tem sido muito difícil, é que não
foi essencialmente, uma comunidade criada ou apoiada por uma empresa de
padronizando as operações em torno de uma postura multinuvem.
Andrew Davidson (09:21): Em outras palavras, você tinha que Go tão fundo em seu
AWS, ou seu Google, seu Azure, para
gerencie toda essa infraestrutura para se sentir completamente confortável com o
governança e gestão do ciclo de vida, que a ideia de Go e
aprender a fazer isso de novo em outra cloud foi apenas
avassalador. Quem quer fazer isso? O que está começando a mudar isso
No entanto, há uma espécie de fornecedores de software de primeira linha, bem como
bem como ofertas de SaaS que estão começando a criar basicamente, essencialmente
consistência em torno da cloud e são, de fato, os melhores da categoria para fazer isso.
Então, quando você analisa o que talvez o Datadog esteja fazendo para monitoramento ou o que a HashiCorp está fazendo com Terraform e cofre, a infraestrutura é gerenciamento de código e segredos, todos os outros anúncios interessantes que eles estão sempre fazendo, essas dinâmicas estão contribuir para tornar é possível que os clientes comecem realmente a fazer isso. Então, estamos chegando agora com a verdadeira camada de dados multinuvem. Portanto, é altamente complementar com essas outras ofertas. Acho que nos próximos dois
anos, isso começará a se tornar muito popular.
michael lynn (10:26): mais ou menos como a próxima fase na evolução da computação em nuvem?
Andrew Davidson (10:29): Totalmente, totalmente.
michael lynn (10:30):Achei que seria bom se pudermos dar uma olhada. Eu sabe que algumas das pessoas que ouvirão isso serão apenas isso, apenas ouvindo. Então, vamos tentar resolver isso também. Mas vamos dar uma olhada nas pessoas em como essa coisa se parece. Então, estou começando a compartilhar minha tela aqui.
andrew davidson (10:48): legal. Sim. Enquanto você puxa isso para cima- [crosstalk 00:10:50] Go em frente, Nic. Desculpe.
Nic Raboy (10:51): Eu ia perguntar, e então talvez isso seja algo
que Mike vai mostrar quando ele abrir sua tela-
andrew davidson (10:55): Sim.
Nic Raboy (10:56): ... mas do ponto de vista do usuário, qual o envolvimento do multinuvem? É algo que só acontece por trás do
cenas e eu não preciso me preocupar nada com isso, ou vai acontecer
serão algumas configurações que vamos ver?
andrew davidson (11:11): Sim. É muito simples. É uma interface de usuário muito
interface de usuário muito intuitiva para configurá-lo e, em seguida, seu cluster é
multi-cloud, que o Mike mostrará, mas voltando à pergunta anterior
anterior, a fim de tomar... Dependendo do caso de uso que você tem para
multicloud, e eu diria que há cerca de quatro tipos de casos de uso
e ficaria feliz em analisá-los, mas, dependendo do caso de uso, acho que há
um conjunto diferente de coisas com as quais você precisará se preocupar para
usar isso do ponto de vista de seus aplicativos.
michael lynn (11:36): Ok. Então, para o pessoal que está ouvindo, abri meu navegador e estou acessando cloud.MongoDB.com. Forneci minhas credenciais e estou conectado ao console do Atlas. Então, estou na primeira guia, que é Atlas, e estou examinando a lista de clusters que implantei anteriormente. Tenho um cluster de camada gratuita e alguns clusters adicionais baseados em projeto. Digamos que eu queira implantar uma nova instância do MongoDB e quiser usar a multinuvem. A primeira coisa que direi fazer é clicar no botão "Criar Novo Cluster", e isso abrirá o assistente de implementação. É aqui que você toma todas as decisões sobre a aparência do cluster. andrew, fique à vontade para adicionar cor enquanto eu Go por isso.
Andre Davidson (12:15): Totalmente.
Michael Lynn (12:16): Então a primeira pergunta é um cluster global
configuração. Só para esta demonstração, vou deixar isso fechado. Vamos deixar isso para outro dia. O segundo painel é o provedor de nuvem e a
e região, e é aqui que as coisas ficam interessantes. Agora, Andrew, no
No início, quando você descreveu o que é o Atlas, você mencionou que o Atlas está
disponível nos três principais provedores de nuvem. Então, temos AWS, Google Cloud e Azure, mas, realmente, ele não existe acima do provedor?
andre davidson (12:46): de várias maneiras, sim. Você está certo. Veja, refletindo sobre a história de como criamos aqui, o Atlas foi lançado talvez perto de... cerca de quatro anos e meio atrás na AWS e então talvez três anos e meio atrás no Google Cloud e no Azure. Desde aquele momento, acabamos de afundar o que o Atlas é em todos os três provedores. Então, chegamos ao ponto em que podemos realmente
Pense na experiência do banco de dados de uma forma que realmente abstraia
a complexidade desses provedores e todos esses anos de investimento
em cada um deles, respectivamente, é o que nos permitiu unificar
juntos hoje de uma forma que, francamente, seria apenas um verdadeiro
desafio para alguém tentar fazer por conta própria.
Andrew Davidson (13:28): A última coisa que você quer tentar configurar é um serviço de banco de dados distribuído em várias clouds. Temos alguns clientes que tentam fazer isso e é um grande desafio. Nós temos
grandes equipes de engenharia trabalhando neste problema em tempo integral e boom, aqui
é. Então, agora, você pode tirar proveito disso. Fazemos isso uma vez, pessoal
outra pessoa pode usá-lo mil vezes. Essa é a beleza disso.
michael lynn (13:47): bonito. Fantástico. Eu estava lendo a atualização sobre
as mudanças no cronograma de lançamento do MongoDB, o produto principal do servidor, e fiquei
e fiquei absolutamente impressionado com a quantidade de horas que são dedicadas a uma
grande lançamento, uma quantidade incrível de horas e, além disso,
a capacidade que você tem com o Atlas de implementar isso em várias nuvens é
é incrível.
Nic Raboy (14:09): Deixe-me interpor aqui por um segundo. Recebemos uma pergunta do chat. Então, da banda está perguntado: "O Atlas suportará DigitalOcean ou OVH ou Ali Cloud?"
andrew davidson (14:19): ótimas perguntas. Não temos planos atuais de fazer isso, mas direi a você. Tudo em nosso roteiro é sobre a demanda do cliente e o que estamos ouvindo de você. Então, ouvir isso de você agora nos ajuda a pensar sobre isso.
michael lynn (14:31): ótimo. Adore as perguntas. Continue enviando. Então, de volta para a tela. Ativamos nosso assistente de criação de novo cluster e estou no segundo painel escolhendo o provedor de nuvem e a região. O que noto, algo novo que não tinha visto antes, é que há uma caixa de chamada rotulada como "isolamento de volume de trabalho multinuvem e multirregional". Portanto, esta é a chave para a multinuvem. Estou certo?
Andre Davidson (14:54): Isso mesmo.
Michael Lynn (14:54): Então, se eu ativar esse botão de rádio, eu vejo
algumas opções adicionais disponíveis para mim e aqui é onde eu vou
especifique os nós elegíveis em um cluster. Então, temos três configurações possíveis. Temos os nós elegíveis para alta disponibilidade. Nós
temos a capacidade ou a opção de adicionar nós somente para leitura, e podemos
especifique o provedor e a região. Temos uma opção para adicionar nós de analítica. Vamos nos concentrar nos nós elegíveis por enquanto. Por padrão, AWS está selecionado. Acho que é porque selecionei a AWS como
provedor, mas se eu clicar em " Adicionar um fornecedor/região, " agora tenho a capacidade
para alterar o provedor para, digamos, GCP, e então eu posso selecionar um
região. Logicamente, as regiões exibem a lista de data centers do Google.
Para que possa escolher algo próximo do aplicativo. Estou dentro
Filadélfia, então a Virgínia do Norte é provavelmente a mais próxima. Então, agora, temos
uma implantação em várias nuvens e vários provedores. Tem mais anotações ou coisas que você queira chamar a atenção, Andre?
Andre Davidson (16:01): Sim- [crosstalk 00:16:02]
Nic Raboy (16:01): Na verdade, Mike, bem rápido.
michael lynn (16:03): Sim.
Nic Raboy (16:04): Perdi. Quando você adicionou o GCP, você selecionou dois ou ele foi preenchido previamente com eles? Eu estou querendo saber qual é o pensamento
por trás de como calculou cada um desses números de nó.
andrew davidson (16:15): está mantendo-os ativados automaticamente. Para motores eléctricos, é necessário um número ímpar. Isso é baseado em- [crosstalk 00:16:20]
Nic Raboy (16:20): Ok.
Andrew Davidson (16:20):... vamos usar uma balsa em forma de balsa
protocolo de consenso, que nos permite manter a leitura e a gravação
disponibilidade contínua, desde que o quórum majoritário esteja on-line. Então, se
você adiciona um terceiro, se você adicionar o Azure, por exemplo, para se divertir, por que não?
O que isso significa é que agora estamos espalhados por três provedores de nuvem e
você vai ter que fazer um número ímpar... Você vai ter que
ou torne-o 111 ou 221, etc. O que isso significa é que você pode agora
resista a uma interrupção global de qualquer um dos três provedores de nuvem e ainda
faça com que seu aplicativo esteja continuamente disponível para leituras e
escreve porque os outros dois provedores de nuvem continuarão on-line
e é aí que você receberá seu quórum majoritário.
Andrew Davidson (17:03): Então, acho que o que acabamos de demonstrar aqui é
tipo de um dos quatro tipos de casos de uso dominantes para várias nuvens,
que é resiliência de alta disponibilidade. É meio que intuitivo. Na prática, muitas pessoas gostariam de usar isso no contexto de países que têm menos regiões de cloud. Nos EUA, somos um pouco malcriados. Há várias regiões da AWS, várias regiões do Azure e várias regiões do Google Cloud. Mas se você for baseado no Reino Unido, na França, no Canadá etc., seu provedor de nuvem preferido pode ter apenas uma região desse país. Portanto, ser capaz de expandir para outras regiões a partir de outro provedor de nuvem, mas manter os dados em seu país para atender aos requisitos de soberania de dados, pode ser bastante tentador.
Michael Lynn (17:46): Então, eu nunca gostaria de implantar um único nó no
cada um dos provedores de nuvem, certo? Ainda queremos um altamente disponível
cluster implantado em cada um dos provedores de nuvem individuais. Correto?
Andre Davidson (17:57): Você pode fazer 111. A desvantagem do 111 é que
durante as rodadas de manutenção, você teria essencialmente direitos que
vá para a segunda região em sua lista de prioridades. Isso é amplamente
razoável, na verdade, se você estiver usando os direitos majoritários de um direito
perspectiva de preocupação. Isso meio que depende do que você deseja otimizar. Outra coisa que quero mostrar rapidamente, Mike, é que há
pequenas linhas pontilhadas no lado esquerdo ou barras triplas no lado esquerdo.
Você pode realmente arrastar e soltar seu pedido regional preferido com isso.
Basicamente, é escolher qual região, por padrão, terá direitos se
essa região está online.
Michael Lynn (18:35): O mesmo acontece com a implantação de zona com a primária, neste
caso, mudei o Azure para o topo, que terá a maior prioridade e
esse será meu principal receptor direito.
Andre Davidson (18:47): Exatamente. Seria onde estão as primárias.
Se o Azure ficasse inativo ou o Azure Virginia ficasse inativo, então o que aconteceria?
teria sido inicialmente secundário na USC. Um na AWS seria
eleitos primários e é aí que os direitos começariam a ir.
michael lynn (19:03): Peguei você. Sim.
andrew davidson (19:04): Sim.
michael lynn (19:05): Então você mencionou direitos da maioria. Você pode explicar o que é isso para qualquer um que possa ser novo nesse conceito?
Andrew Davidson (19:12): Sim, então o MongoDB tem um conceito de direito
preocupação e, basicamente, nossa melhor prática é configurar seus direitos,
que é uma configuração de driver do lado do cliente MongoDB para utilizar o
maioria de preocupação, que essencialmente diz que o motorista não reconhecerá
à direita da perspectiva do banco de dados e passar para o próximo
operação até que a maioria dos nós no conjunto de réplicas tenha
reconheceu esse direito. O que isso garante é que você está
não permitindo que seus direitos sejam essencialmente, superar o que seu
conjunto de réplicas pode acompanhar. Então, em um mundo em que você realmente
direitos momentâneos estourados, você pode considerar uma preocupação certa de um, apenas
Certifique-se de que vai para o primário, mas isso pode ter alguns riscos em escala.
Portanto, recomendamos maioria.
Michael Lynn (20:01): Então, na lista de casos de uso, você mencionou o
primeiro e provavelmente o mais popular, que era fornecer mais
acesso e disponibilidade em uma região onde há apenas um provedor de dados
centro. Vamos falar sobre algumas das outras razões pelas quais alguém
deseja implantar várias nuvens,
Andre Davidson (20:19): Boa pergunta. O segundo, que na verdade
acho que pode até ser mais popular, embora você possa me dizer, "Não é
exatamente tão multicloud quanto o que acabamos de falar," mas o que eu acho que
será o mais popular é poder mudar de um provedor de nuvem
de um provedor de nuvem para outro sem tempo de inatividade. Em outras palavras, você é apenas multicloud durante a transição e, em seguida, está na outra cloud. Portanto
É um pouco discutível, mas ter essa liberdade, essa flexibilidade e
basicamente, a maneira como essa configuração seria feita, Mike, é se você
clicar em "Cancel" aqui e voltar para a visualização de um único provedor de nuvem,
em um mundo no qual você tem um cluster implementado na AWS, como tem agora.
como você tem agora, se esse fosse um cluster implantado, você poderia simplesmente Go para o topo,
selecionar Azure ou GCP, clicar em "Deploy (Implantar)," e nós o moveríamos para lá.
Isso também é possível agora.
Andrew Davidson (21:07): A razão pela qual eu acho que isso será o mais
comumente usado é que há muitas razões pelas quais as pessoas precisam ser capazes de
Passe de um provedor de nuvem para outro. Às vezes você tem uma espécie de
organização que foi adquirida em outra organização e há
um esforço de consolidação em andamento. Às vezes, há apenas a impressão de que outro provedor de nuvem tem recursos importantes que você deseja começar a aproveitar mais, então deseja fazer a alteração. Outras vezes,
trata-se de realmente se sentir mais à prova de futuro e apenas ser capaz de não
ser trancado e fazer essa mudança. Então este, eu acho, é mais um
uma espécie de preocupação no nível da diretoria, bem como um empoderamento do desenvolvedor
coisa. É realmente emocionante ter ao seu alcance, o poder de
sinto que posso simplesmente mover meus dados para qualquer lugar do mundo
79 regiões e nada está me impedindo de fazer isso. Quando você se senta
Em sua estação de trabalho, isso é realmente emocionante.
Michael Lynn (22:00): De volta ao comentário que você fez anteriormente, na verdade
reduzindo a gravidade dos dados-
Andre Davidson (22:05): Totalmente.
michael lynn (22:05): ... e aumentando a compliance. Sim, Go em frente, Nic.
Nic Raboy (22:09): Sim. Então você mencionou ser capaz de mover as coisas. Então, deixe-me perguntar o mesmo cenário, a mesma coisa, mas quando Mike estava
capaz de mudar a prioridade de cada uma dessas nuvens, podemos mudar o
prioridade após a implantação? Digamos que a Amazon seja nossa prioridade agora para o próximo ano, mas, depois disso, o Google é nossa agora principal prioridade. Podemos mudar isso após o fato?
Andre Davidson (22:34): Com certeza. Ponto muito bom. Em geral, com o Atlas, Tradicionalmente, a visão sempre foi de que praticamente tudo nesse construtor de cluster que ele tem mostrado deve ser o tipo de coisa que você pode configurar quando faz o primeiro lançamento declarativamente, e que você pode então alterar e o Atlas fará o trabalho pesado para chegar a esse novo estado declarativo. No entanto, até a semana passada, a única grande exceção a isso era que você não podia alterar seu provedor de nuvem. Você já pode alterar a região dentro do provedor de nuvem, alterar suas configurações de multirregiões etc. Mas agora, você pode realmente mudar entre os fornecedores de nuvem, alterar a ordem de prioridade de um ambiente de várias regiões que envolve vários fornecedores de nuvem. Todas essas coisas podem ser facilmente alteradas.
Andre Davidson (23:15): Quando você faz essas alterações, não há operações de tempo de inatividade. Tornamos isso possível fazendo tudo de forma contínua no backend e aproveitando o MongoDB, do que falvamos anteriormente, o sistema distribuído, o consenso que nos permite garantir que sempre tenhamos quorum de maioria online, e seria basta fazer todo esse trabalho pesado para chegar de qualquer estado a qualquer outro estado em uma parede que preserva essa maioria. É realmente uma coisa bonita.
Michael Lynn (23:39): Sim. E tão poderoso. Então, o que estamos mostrando aqui
é o implantador, como você disse, mas toda essa mesma tela aparece quando eu
dê uma olhada em uma instância do MongoDB implantada anteriormente e eu posso fazer
muda exatamente da mesma forma.
Andre Davidson (23:55): Exatamente.
michael lynn (23:55): muito poderoso.
Andre Davidson (23:56): Exatamente.
michael lynn (23:56): Sim.
Andrew Davidson (23:57): Então, acho que há alguns outros casos de uso
deveria falar rapidamente sobre porque passamos por dois tipos de
mobilidade preparada para o futuro, passando de um para o outro. Falamos sobre alta
disponibilidade, resiliência e como isso é particularmente útil em países
onde talvez você queira manter os dados no país e talvez não tenha
muitas regiões de provedores de nuvem nesse país. Mas o terceiro caso de uso
isso é muito empolgante, e acho que capacitar mais os desenvolvedores,
é que às vezes você quer aproveitar as melhores capacidades do
diferentes provedores de nuvem. Você pode ama AWS porque você simplesmente ama serverless e você ama Lambda, e quem não faz? Então você quer estar lá para esse aspecto do seu aplicativo.
Andrew Davidson (24:34): Talvez você também queira ser capaz de tomar
vantagem de alguns dos recursos que o Google oferece em torno da máquina
aprendizado e AI, e talvez você queira ter os trabalhos de ML em
o lado do Google ser capaz de acessar seus dados com baixa latência em que
Região do provedor de nuvem. Bem, agora você pode ter uma réplica de leitura nessa região da nuvem do Google e fazer isso lá. Talvez você queira levar
vantagem das operações de desenvolvimento do Azure, adoro a centralidade do desenvolvedor que
estamos vendo da Microsoft e do Azure atualmente e, novamente, poder
para combinar e combinar e aproveitar as vantagens do provedor de nuvem que você
queremos desbloqueia possibilidades e capacidades funcionais que os desenvolvedores
simplesmente nunca tive na ponta dos dedos antes. Então isso é lindo
emocionante também.
michael lynn (25:18): ótimo. Portanto, quaisquer outros casos de uso que quisermos
menção?
andrew davidson (25:23): Sim. A última é meio que uma categoria especial. É mais sobre dizer que, às vezes... Muitos de nossos clientes e pessoas que nos escutam são eles mesmos, criando serviços de software e de cloud no MongoDB Atlas. Para as pessoas que fazem isso, você provavelmente estará ciente de que, às vezes, seus clientes finais estipulam qual provedor de nuvem subjacente você precisa usar para eles. É um pouco desconcertante quando eles fazem isso. É como: "Nossa, preciso usar um provedor de nuvem diferente para Go atender você." Você pode brigar
e, talvez, fazer com que isso aconteça sem fazer isso. Mas agora você tem a capacidade de atender facilmente seus clientes finais sem que isso atrapalhe. Se eles tiverem uma regra de que um determinado provedor de nuvem deve ser usado, você também poderá servi-los. Então nós alimentamos assim
muitas camadas da pilha de infraestrutura, tantos serviços SaaS e
plataformas, muitas delas, isso é muito atraente.
michael lynn (26:29): Então, se eu tiver meus dados na AWS, eles tiverem uma VPC, posso estabelecer uma VPC entre o aplicativo e o banco de dados?
Andre Davidson (26:36): Correto.
michael lynn (26:37): e o mesmo com o google e o Azure.
andrew davidson (26:39): Sim. Há uma observação importante. O MongoDB Atlas oferece emparelhamento de VPC, bem como link privado no AWS e no Azure. Também oferecemos emparelhamento de VPC no Google. No contexto dos nossos clusters de várias nuvens que acabamos de anunciar, ainda não temos suporte para link privado e emparelhamento de VPC. Você usará o gerenciamento de lista de acesso IP público. Isso acontecerá, junto com o suporte global a clusters,
eles chegarão no início de 2021 como nossa visão atual
declaração. Obviamente, tudo está voltado para o futuro... Há incertezas
que você quer que eu exclua, mas o que lançamos hoje
é, antes de mais nada, para o gerenciamento sem acesso. No entanto, quando você move um cluster de uma cloud para a outra, você pode absolutamente aproveite o peering hoje ou em particular.
Nic Raboy (27:30): Porque Mike tem isso em sua tela, eu sou capaz de remover nós de uma região de cloud sob demanda, à vontade?
Andre Davidson (27:37): Com certeza. Você pode apenas adicionar mais réplicas.
Assim como estávamos dizendo, você pode passar de um para o outro ou mais ou menos
altere sua ordem preferida de onde estão os direitos, você pode adicionar mais
réplicas em qualquer nuvem a qualquer momento ou remova-as a qualquer momento [crosstalk]
00:27:53]... do escalonamento automático vertical do Atlas também.
Nic Raboy (27:55): Era isso que eu ia perguntar. Então, como isso funciona? Como você contaria, se fosse para o auto-scale, você poderia dizê-lo para o auto-scale? Como ele se equilibra entre três nuvens diferentes?
andrew davidson (28:07): Essa é uma ótima pergunta. A forma como o auto-scaling do Atlas funciona é que você realmente... Então, se você escolher um M30, poderá ver o auto-scaling lá.
Nic Raboy (28:20): Para as pessoas que estão ouvindo, tudo isso está no
Crie uma nova tela de cluster.
Andrew Davidson (28:25): Basicamente, a maneira como funciona é que vamos
dimensionar verticalmente você. Se algum dos nós do cluster estiver
essencialmente, chegando ao ponto em que exigem escalonamento com base em
requisitos de computação subjacentes, o importante a observar é que
é um equívoco comum, acho que você poderia dizer, no MongoDB que você
talvez você queira escalar apenas algumas réplicas e não outras. Em
geral, você gostaria de dimensioná-los todos simetricamente. A razão para isso
isso é que a carga de trabalho precisa ser consistente em todos os nós
e os conjuntos de réplicas. Isso se deve ao fato de que, apesar de os direitos Go para o
primários, os secundários também têm que acompanhar esses direitos. De qualquer forma.
Michael Lynn (29:12): Eu só queria mostrar aquela pergunta em escala automática
aqui.
andrew davidson (29:16):Ah, sim.
michael lynn (29:17): Sim, lá Go nós. Então, se eu estiver implantando um M30,
consiga especificar no mínimo, eu Go até um M20 e em um
máximo, com base no perfil de leitura e gravação e no aplicativo de atividade, I
Go até um máximo de M50, por exemplo.
Andre Davidson (29:33): Exatamente.
Nic Raboy (29:35): Mas talvez eu esteja perdendo alguma coisa ou talvez não
até mesmo importante com base em como as coisas são projetadas. Mike está mostrando como
aumente e diminua de M20 para M50, mas e se eu quisesse todas as novidades
os nós aparecerão apenas no meu terceiro nível de prioridade? Isso é uma coisa?
Andrew Davidson (29:55): Sim, essa é uma forma de escalonamento automático que é
definitivamente... Em outras palavras, você está basicamente dizendo ... Essencialmente
o que você está querendo dizer é o que aconteceria se eu quisesse dimensionar minha taxa de transferência de leitura
adicionando mais réplicas de leitura?
Nic Raboy (30:04): Claro.
Andrew Davidson (30:05): De um modo geral, não é assim que nós
recomendar dimensionamento. Nós tendemos a recomendar a escala vertical em vez de
adicionando réplicas de leitura. [crosstalk 00:30:14]
Nic Raboy (30:14): Ok.
AWS Davidson (30:14): A razão para isso com o MongoDB é que, se você escalar leituras com réplicas, o risco é que você possa se encontrar em uma situação de falha composta em que está sobrecarregando todas as suas réplicas de alguma forma, e então um vai para baixo e, de seguida, você tem a mesma carga de trabalho vai para um grupo ainda menor. Portanto, definimos a escala vertical e/ou introduzimos a fragmentação quando você está falando sobre esse tipo de escala. No entanto, há cenários em que, para seu ponto de vista, você meio que deseja ter réplicas de leitura em outras regiões, digamos para essencialmente. atendendo ao tráfego dessa região com baixa latência e desses tipos de casos de uso. É aqui que julgo que estás certo.
Com o tempo, provavelmente veremos formas mais exticas de auto-scaling que queremos introduzir. Não está lá hoje.
michael lynn (31:00): Ok. Então, voltemos e terminaremos nossa criação de um novo cluster. Crie um novo cluster, selecionarei multi-cloud e
Selecionarei nós elegíveis em três provedores.
Andre Davidson (31:15): Então, análises no Azure- [crosstalk 00:31:18] Tudo bem. Não há problema algum nisso.
michael lynn (31:20): Ok.
Andre Davidson (31:21): Não tem problema.
michael lynn (31:22): Ok. Portanto, um único cluster no Amazon Web Services, GCP e
Azure, e temos nós ímpares. Ok. Procurando bem lá. Selecionaremos nossa camada do cluster. Digamos que um M30 esteja correto e especifiquemos a quantidade de disco. Ok. Então, mais alguma coisa que queremos trazer para a discussão? Quaisquer outros recursos que estamos faltando?
andre davidson (31:47): Não que eu possa pensar. Eu direi que temos
definitivamente tive uma adoção precoce interessante até agora. Eu não vou
nomes de nomes, mas já vimos pessoas aproveitarem a vantagem de se mover entre
os provedores de nuvem, vimos algumas pessoas que espalharam seus
clusters em vários provedores de nuvem em um país de destino, como eu
mencionei, sendo capaz de manter meus dados no Canadá, mas em vários
provedores de nuvem. Vimos casos de uso em e-commerce. Vimos casos de uso na área da saúde. Vimos casos de uso principalmente em monitoramento. Nós temos
visto casos de uso de serviços de emergência. Portanto, é uma ótima validação antecipada
ter isso no mercado e ter tanto entusiasmo pelo
Clientes. Então, se alguém estiver interessado em experimentar isso, ele está disponível para experimentar no MongoDB Atlas hoje.
Nic Raboy (32:33): Então, este foi um capítulo muito bom. Na verdade, temos uma pergunta chegando. Vamos resolver isso primeiro. Apenas por saber que M significa multicamadas? De onde deriva essa convenção de nomenclatura?
Andrew Davidson (32:48): Essa é uma ótima pergunta. As camadas do cluster no Atlas desde o início, usamos esta nomenclatura do M10, o M20, o M30. A resposta não tão criadora é que ela significa MongoDB, [crosstalk 00:33:00], mas agora podemos começar a afirmar que ela tem a ver com multinuvem, potencialmente . Eu curto isso.
michael lynn (33:08): Você pode dizer algo sobre o roteiro? Existe
Há algo que você possa compartilhar sobre o que está por vir?
Andre Davidson (33:13): Veja, continuaremos maiores, mais rápidos, com mais clientes e com mais escala. É tão emocionante. Estamos agora
fornecendo no Atlas alguns dos maiores jogos do mundo, alguns dos
aplicativos financeiros de consumo mais populares, aplicativos que fazem
vida dos consumidores, trabalho, aplicativos que permitem aos fabricantes:
continue criando todas as coisas em que confiamos, aplicativos que
poder para um público verdadeiramente global. Estamos vendo uma adoção incrível e
crescimento e economias em desenvolvimento. É um momento muito emocionante e
estar na vanguarda de ver os desenvolvedores realmente se transformando
a economia, a transformação digital que está acontecendo.
Andre Davidson (33:57): Vamos apenas continuar, focar em onde nossos clientes querem que Go para agregar mais valor para eles, continuar ampliando a plataforma de dados. Talvez tenha mencionado que o Atlas Search é um grande foco para nós, aumentando o banco de dados operacional transacional tradicional, o realm, a comunidade de banco de dados móvel e, essencialmente, tornando possível criar esses ótimos aplicativos móveis e fazer com que eles sincronizem de volta com a nuvem. Estou super ansioso com isso e com a preparação global para o lançamento do 5g. É incrivel ver a possibilidade em dispositivos móveis no próximo ano.
Sim, há muito. Muito vai acontecer e todos nós vamos fazer parte disso juntos.
Michael Lynn (34:34): Parece incrível.
Nic Raboy (34:34): Se as pessoas quisessem entrar em contato com você depois
este episódio vai ao ar, você no Twitter, LinkedIn? Onde você prefere
pessoas para entrar em contato?
andrew davidson (34:43): eu apenas recomendaia que as pessoas escrevessem diretamente para o e-mail: Andrew.Davidson@MongoDB.com. Gostamos de ouvir o feedback do produto e saber como podemos melhorar. É para isso que estamos aqui: ouvir você diretamente, conectá-lo às pessoas certas etc.
michael lynn (34:56): fantástico. Bem, Andrew, muito obrigado por aceitar
tempo fora do seu dia agitado. Esta foi uma ótima conversa. Sério
gostei de aprender mais sobre multinuvem e estou ansioso para ter você
no podcast novamente.
Andrew Davidson (35:08): Muito obrigado. Tenha um ótimo resto de dia,
todo mundo.
Com os clusters multinuvem no MongoDB Atlas, os clientes podem realizar os benefícios de uma estratégia multinuvem com verdadeira portabilidade de dados e uma experiência de gerenciamento simplificada. Os desenvolvedores não precisam mais lidar com
replicação manual de dados, e as empresas podem focar suas técnicas
recursos na criação de software diferenciado.
Confira os seguintes recursos para obter mais informações:
Avalie esse podcast