Clusters multinuvem do MongoDB Atlas
Avalie esse Podcast
Neste capítulo do podcast, Nic e eu nos juntamos a Andre Davidson, VP de produtos de nuvem no MongoDB. Andrew compartilha alguns detalhes da inovação mais recente no MongoDB Atlas e fala sobre algumas das maneiras pelas quais os clusters multinuvem 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. Portanto, isso permite que você implante e gerencie suas instâncias do MongoDB na nuvem nos 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 algumas semanas ocupadas e estou super animado por estar aqui para falar com vocês sobre o que estamos fazendo.
michael lynn (01:05): Com certeza. Vamos falar sobre multinuvem hoje e novidade adicionada ao MongoDB Atlas. Mas antes de chegarmos lá, Andrew, eu me pergunto se você apenas explicaria ou apenas se apresentaria ao 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 explicamos ao 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 período, realmente vi essa grande mudança da qual todos os envolvidos no MongoDB fizeram parte, com nosso DNA deixando de ser mais uma empresa de software para ser uma verdadeira empresa de nuvem. Foi uma realmente uma viagem de cinco anos nos últimos cinco anos. Para mim, o anúncio que fizemos na semana passada, ao qual Mike estava se referindo, é realmente o ponto culminante, em muitos aspectos, dessa jornada. Então não poderia estar mais ansioso.
michael lynn (02:12): Sim, fantástico. Oito anos. Oito anos em uma empresa de software são uma 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. Tratava-se de refazer o mapa do mundo e de criar um novo conjunto de dados de mapas usando o street view exclusivo do Google e outras informações para melhorar todos os mapas que você utiliza todos os dias no Google Maps e para que o Google pudesse desenvolver esse conjunto de dados mais rapidamente. Portanto, foi um projeto muito humano que envolveu milhares de operadores humanos fazendo uma quantidade enorme de trabalho complexo porque o resultado final era que isso não é algo que você poderia fazer com o ML naquele momento. 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 me concentrar em nosso software tradicional de gerenciamento local, chamado MongoDB Ops Manager, que era meio que o principal diferencial em nossa Enterprise Advanced. Naquela época, a empresa estava mais focada essencialmente em monetizar o lançamento, por meio de operações tradicionais de TI. Embora sempre nos preocupássemos com desenvolvedores e os desenvolvedores estivessem sempre criando ótimos aplicativos novos no banco de dados, de certa forma, 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 consegui fazer essa mudança e me concentrar novamente no desenvolvedor quando mudamos para uma verdadeira plataforma de nuvem, e isso tem sido muito divertido desde então.
michael lynn (03:52): Sim. Viagens incríveis. Do Ops Manager para o Atlas. Quero estar ciente de que nem todos os nossos ouvintes estarão familiarizados com Atlas. Então, talvez descreva o que é Atlas da sua perspectiva.
Andrew Davidson (04:08): Totalmente. Sim. O MongoDB Atlas como um serviço de banco de dados em nuvem global. Ele está disponível nos três grandes provedores de nuvem, AWS, Google Cloud e Azure. E é realmente 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 a Atlas faz todo o trabalho pesado para chegar lá, para fazer o gerenciamento do ciclo de vida. Você pode criar infraestrutura como código, gerenciar seus clusters de banco de dados no Terraform ou usar nossa bela interface de usuário para aprender e implantar. Percebemos que não basta ter um serviço de banco de dados elástico. Esse é o ponto de partida. Também não basta ter o melhor banco de dados moderno, um que seja tão nativo para desenvolvedores, que fale com aquele rico modelo de dados do MongoDB com índices secundários e todo o resto. Realmente, precisávamos Go além do banco de dados.
Andrew Davidson (04:54): Por isso, nos concentramos fortemente em ajudar nossos clientes com orientações prescritivas, conselhos sobre esquemas e sugestões de índices, e você verá que continuaremos evoluindo porque reconhecemos que, na verdade, toda semana, dezenas de milhares de pessoas estão acessando a plataforma pela primeira vez. Precisamos apenas reduzir a barreira de entrada para criar aplicativos bem-sucedidos no banco de dados. Também aumentamos o Atlas com as principais expansões da plataforma, incluindo a pesquisa. Temos índices de pesquisa baseados em Lucene agora nativos do Atlas. Assim, você não precisa fazer o ETL desses dados para um mecanismo de busca e, basicamente, criar a busca diretamente em seus aplicativos operacionais. Temos arquivamento on-line para hierarquização de dados em economia de armazenamento de objetos. 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. Portanto, tudo isso é muito empolgante, mas, fundamentalmente, o que faltava até a semana passada eram os verdadeiros clusters multinuvem, a capacidade de misturar e combinar esses bancos de dados entre as nuvens para ter réplicas que abrangem os provedores de nuvem ou para mudar perfeitamente de um provedor para outro sem tempo de inatividade, sem alteração na cadeia de conexão. Então, isso é muito empolgante.
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ê pode talvez falar sobre como isso é diferente ou para que serve realmente 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 e a maioria dos membros da comunidade têm uma plataforma de nuvem preferida e todas as plataformas de nuvem são excelentes à sua maneira. 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 cluster Atlas em seu provedor de destino, onde residem suas outras infraestruturas, onde residem suas camadas de aplicativos, etc. É onde o mundo está hoje, em sua maior parte. No entanto, sabemos que estamos à beira de uma nova mudança que está acontecendo nesse mercado em que, com o tempo, as pessoas começarão cada vez mais, misturando e aproveitando o melhor dos diferentes provedores de nuvem. Então, 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, à medida que o mercado também se move para lá.
Michael Lynn (07:21): Então, isso está disponível hoje e quais outros requisitos existem 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 depende de qual é o seu caso de uso, o 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 esse banco de dados. Portanto, em termos gerais, você vai querer ter uma camada de aplicativo capaz de conectar o banco de dados e, se estiver em várias nuvens e fizer isso por vários motivos, como, por exemplo, resiliência de alta disponibilidade para poder resistir ao ditado de um provedor de nuvem completa, então você vai querer que sua camada de aplicativo também seja multinuvem.
Andrew Davidson (08:03): Esse é o tipo de coisa que, tradicionalmente, as pessoas não achavam fácil, mas está ficando mais fácil o tempo todo. É por isso que meio que... Estamos abrindo isso na camada de dados e, em seguida, outras, a plataforma Kubernetes, etc., estão realmente abrindo essa portabilidade na camada de aplicativos e realmente tornando isso possível para o mercado. Mas antes de continuarmos nos concentrando em onde estamos hoje, acho que não faria mal retroceder um pouco e falar sobre por que a multinuvem é tão difícil.
michael lynn (08:32): Isso faz sentido.
Andrew Davidson (08:35): Tem havido duas razões principais pelas quais a multinuvem é tão difícil. Eles meio que se resumem a dados e quanta gravidade de dados existe. É claro que é isso que nosso anúncio diz sobre mudar. Em outras palavras, seus dados precisam ser armazenados em uma nuvem ou outra, ou tradicionalmente tinham que ser. Então, na verdade, mover esses dados para outra nuvem ou torná-los presentes ou disponíveis na outra nuvem, isso foi extremamente difícil e, tradicionalmente, fez com que as pessoas sentissem que a multinuvem não era essencialmente alcançável. A segunda razão principal pela qual a multinuvem tem sido tradicionalmente muito difícil é que não houve, essencialmente, uma maneira criada pela comunidade ou apoiada pela empresa de padronizar as operações em torno de uma postura multinuvem.
Andrew Davidson (09:21): Em outras palavras, você tinha que se aprofundar tanto em seu ambiente da AWS, ou do Go, do seu Azure, para gerenciar toda essa infraestrutura para se sentir completamente confortável com a governança e o gerenciamento do ciclo de vida, que a ideia de aprender a fazer isso novamente em outra cloud era simplesmente avassaladora. Quem quer fazer isso? O que está começando a mudar isso, porém, é que existem os melhores fornecedores de software da categoria, bem como ofertas de SaaS que estão começando basicamente a criar consistência na cloud e, na verdade, são as melhores 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 vai 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 pudéssemos dar uma olhada nisso. Eu sei que algumas das pessoas que ouvem isso serão exatamente isso, apenas ouvindo. Então, vamos tentar resolver isso também. Mas vamos dar uma espiada para o pessoal em como essa coisa se parece. Então vou 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 trouxer sua tela-
andrew davidson (10:55): Sim.
Nic Raboy (10:56): ... Mas, do ponto de vista do usuário, quanto envolvimento a multinuvem conecta? É algo que acontece nos bastidores e eu não preciso me preocupar com isso, ou haverá algumas configurações que veremos?
andrew davidson (11:11): Sim. É muito simples. É uma interface de usuário muito intuitiva para configurá-lo e, em seguida, boom, a multinuvem do seu cluster, que Mike mostrará, mas voltando à pergunta anterior, para levar ... Dependendo do caso de uso que você tem para multinuvem, e eu diria que há cerca de quatro tipos de casos de uso e fico feliz em analisá-los, dependendo do caso de uso, acho que há um conjunto diferente de coisas com as quais você precisará se preocupar para usar isso da perspectiva 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 é uma configuração de cluster global. Apenas para esta demonstração, vamos deixar isso fechado. Vamos deixar isso para outro dia. O segundo painel é o provedor de nuvem e a região, e é aqui que fica interessante. Agora, Andrew, 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, estamos aprofundando o que o Atlas é em todos os três provedores. Então, chegamos ao ponto em que podemos realmente pensar sobre a experiência do banco de dados de uma forma que realmente abstrai a complexidade desses provedores e todos esses anos de investimento em cada um deles, respectivamente, é o que nos permitiu uni-los hoje de uma forma que, francamente, seria apenas um verdadeiro desafio para alguém tentar fazer por conta própria.
Andre Davidson (13:28): a última coisa que você deseja 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. Temos grandes equipes de engenharia trabalhando nesse problema em tempo integral e pronto, aqui está. Então agora você pode aproveitá-la. Nós usamos uma vez, e todos podem usar mil vezes. Essa é a beleza da coisa.
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 principal produto de servidor, e fiquei absolutamente impressionado com a quantidade de horas necessárias para uma versão principal, simplesmente uma quantidade incrível de horas e, além disso, a capacidade que você obtém com o Atlas de implantá-la 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 roadmap está relacionado à demanda dos clientes e ao que ouvimos de vocês. 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 eu noto, algo novo que eu não vi antes, é que há uma caixa de chamada rotulada como "isolamento de carga de trabalho multi-cloud multi-region". 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, vejo algumas opções adicionais disponíveis e é aqui que vou especificar 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. Temos a capacidade ou a opção de adicionar nós somente leitura e podemos especificar 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. Talvez seja porque selecionei a AWS como fornecedor, mas se clicar em "Adicionar um fornecedor/região", agora posso alterar o fornecedor para, digamos, GCP, e depois selecionar uma região. Logicamente, as regiões exibem a lista de data centers do Google. Para que possa escolher algo próximo do aplicativo. Estou na Universidade de Nova York, então North Virginia é provavelmente o mais próximo. 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? Estou me perguntando qual é o processo de pensamento por trás de como ele calculou cada um desses números de nós.
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):... usaremos um protocolo de consenso semelhante ao de uma jangada, que nos permite manter a disponibilidade contínua de leitura e gravação, desde que o quórum majoritário esteja on-line. Então, se você adicionar 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ê terá que criar um número ímpar... Você terá que torná-lo 111 ou 221, etc. Isso significa que agora você pode resistir a uma interrupção global de qualquer um dos três provedores de nuvem e ainda ter seu aplicativo continuamente disponível para leitura e gravação, porque os outros dois provedores de nuvem continuarão on-line e é daí que você receberá seu quórum majoritário.
Andrew Davidson (17:03): Então, acho que o que acabamos de demonstrar aqui é um dos quatro tipos de casos de uso dominantes para multinuvem, que é a 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 nuvem. 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ê estiver no Reino Unido, na França, no Canadá, etc., seu provedor de nuvem preferido poderá ter apenas uma região nesse país. Portanto, a possibilidade de expandir para outras regiões a partir de outro provedor de nuvem, mas manter os dados em seu país devido a requisitos de soberania de dados, pode ser bastante atraente.
Michael Lynn (17:46): Então, eu nunca gostaria de implantar um único nó em cada um dos provedores de nuvem, certo? Ainda queremos um cluster altamente disponível 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ê basicamente teria direitos que passariam para a segunda região em sua lista de prioridades. Na verdade, isso é bastante razoável, se você estiver usando os direitos da maioria do ponto de vista da preocupação correta. 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, isso é escolher qual região, por padrão, terá direitos se essa região estiver online.
michael lynn (18:35): o mesmo acontece com a implantação da zona com o primário, neste caso, movi o Azure para o topo, que terá a maior prioridade e esse será meu receptor primário direito.
Andre Davidson (18:47): Exatamente. Seria onde estão as primárias. Se o Azure caísse ou o Azure Virginia caísse, o que inicialmente seria secundário no da USC na AWS seria eleito primário e é aí que os direitos começariam a funcionar.
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 preocupação correta e, basicamente, nossa melhor prática é configurar seus direitos, que é uma configuração de driver do lado do cliente do MongoDB para utilizar a maioria correta, o que basicamente diz que o driver não reconhecerá o correto da perspectiva do banco de dados e passará para a próxima operação até que a maioria dos nós no conjunto de réplicas reconheça esse direito. O que isso garante é que você não está permitindo que seus direitos sejam essencialmente ultrapassados o que seu conjunto de réplicas pode acompanhar. Então, em um mundo em que você tem direitos momentâneos muito altos, você pode considerar a preocupação correta de uma pessoa, apenas certifique-se de que ela vá para a primária, mas isso pode ter alguns riscos em grande escala. Portanto, recomendamos a 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 acesso e disponibilidade adicionais em uma região onde há apenas um data center de provedor. Vamos falar sobre algumas das outras razões pelas quais alguém gostaria de implantar multi-cloud,
Andre Davidson (20:19): Boa pergunta. O segundo, que na verdade acho que pode ser ainda mais popular, embora você possa me dizer: " Não é exatamente tão multinublado quanto o que acabamos de falar, ", mas o que eu acho que será o mais popular é poder passar 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. Então, é meio discutível, mas ter essa liberdade, essa flexibilidade e basicamente a forma como essa seria configurada, Mike, é se você clicasse em " Cancelar " aqui e voltar à visão de um único provedor de nuvem, em um mundo em que você tem um cluster implantado na AWS exatamente como você tem agora, se fosse um cluster implantado, você poderia simplesmente ir para o topo, selecionar Azure ou GCP, clicar em " Implantar, " e nós apenas mudaríamos você lá. Isso também é possível agora.
Andrew Davidson (21:07): O motivo pelo qual eu acho que esse será o mais usado é que há muitos motivos pelos quais as pessoas precisam poder migrar de um provedor de nuvem para outro. Às vezes, você tem uma organização que foi adquirida por outra organização e há um esforço de consolidação em andamento. Às vezes, há a sensação de que outro provedor de nuvem tem recursos essenciais dos quais você quer começar a aproveitar mais, então você quer fazer a mudança. Outras vezes, trata-se de realmente se sentir mais à prova de futuro e apenas ser capaz de não ficar preso e fazer essa mudança. Portanto, este, eu acho, é mais uma espécie de preocupação no nível da diretoria, bem como uma coisa de empoderamento do desenvolvedor. É muito empolgante ter na ponta dos dedos o poder de sentir que posso simplesmente mover meus dados para qualquer lugar do mundo nas regiões 79 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, realmente 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 o migo conseguiu alterar a prioridade de cada uma dessas cloud, podemos alterar a 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. Ótima observação. Em geral, com o Atlas, tradicionalmente, a filosofia sempre foi que basicamente tudo nesse construtor de clusters que o Mike está mostrando deveria ser o tipo de coisa que você poderia configurar quando fizesse a primeira implantação declarativa, e que você poderia então mudar e o Atlas apenas faria o trabalho pesado para levá-lo a esse novo estado declarativo. No entanto, até a semana passada, a única grande exceção a isso era que você não podia mudar seu provedor de nuvem. Você já pode alterar a região dentro do provedor de nuvem, alterar suas configurações de várias regiões, etc. Mas agora, você pode realmente mudar entre os provedores de nuvem, alterar a ordem de prioridade para um ambiente multirregional que envolve vários provedores de nuvem. Todas essas coisas podem ser facilmente alteradas.
Andrew Davidson (23:15): Quando você faz essas alterações, todas essas são operações sem 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 dou uma olhada em uma instância do MongoDB implantada anteriormente e posso fazer alterações da mesma maneira.
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 devemos falar rapidamente sobre alguns outros casos de uso, porque passamos por dois tipos de mobilidade preparada para o futuro, passando de um para o outro. Falamos sobre resiliência de alta disponibilidade e como isso é particularmente útil em países onde talvez você queira manter os dados no país e talvez não tenha tantas regiões de provedores de nuvem nesse país. Mas o terceiro caso de uso que é muito interessante é, e acho que capacitar mais os desenvolvedores, é que às vezes você quer aproveitar os melhores recursos dos 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 presente nesse aspecto da sua aplicação.
Andrew Davidson (24:34): Talvez você também queira aproveitar alguns dos recursos que o Google oferece em torno de aprendizado de máquina e AI, e talvez queira que os trabalhos de ML do lado do Google acessem seus dados com baixa latência nessa 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 tirar proveito das operações de desenvolvimento do Azure, simplesmente adore a centralidade do desenvolvedor que estamos vendo na Microsoft e no Azure atualmente e, novamente, ser capaz de misturar e aproveitar o provedor de nuvem que você deseja desbloqueia possibilidades e recursos funcionais que os desenvolvedores simplesmente não tinham na ponta dos dedos antes. Então isso também é muito emocionante.
michael lynn (25:18): ótimo. Há outros casos de uso que queremos mencionar?
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 nuvem no MongoDB Atlas. Para as pessoas que fazem isso, você provavelmente sabe 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 Go um provedor de nuvem diferente para atender você." Você pode brigar com eles e talvez fazer isso acontecer sem fazer isso. Mas agora você tem a capacidade de atender facilmente seus clientes finais sem que isso atrapalhe. Se eles tiverem uma regra que exija o uso de um determinado provedor de nuvem, você também poderá atendê-lo. Por isso, alimentamos tantas camadas da pilha de infraestrutura, tantos serviços e plataformas SaaS, tantos deles, que 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 de 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 de clusters, que chegará no início de 2021, como nossa declaração prospectiva atual. Obviamente, tudo o que é voltado para o futuro... Há incertezas que você quer que eu exclua, mas o que lançamos hoje é, antes de tudo, para gerenciamento sem acesso. No entanto, ao mover um cluster de uma nuvem para outra, você pode aproveitar o peering hoje ou de forma privada.
Nic Raboy (27:30): Como Mike o tem na tela, posso remover nós de uma região de cloud sob demanda, à vontade?
Andrew Davidson (27:37): Com certeza. Você pode simplesmente adicionar mais réplicas. Assim como estávamos dizendo, você pode passar de um para outro ou alterar sua ordem preferida de onde vão os direitos, você pode adicionar mais réplicas em qualquer nuvem a qualquer momento ou removê-las 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á na tela de criação de um novo cluster.
Andrew Davidson (28:25): Basicamente, a maneira como funciona é que vamos escalá-lo verticalmente. Se algum dos nós do cluster estiver, essencialmente, chegando ao ponto de precisar de escalonamento com base nos requisitos de computação subjacentes, é importante observar que é um equívoco comum, acho que se pode dizer, no MongoDB, que você pode querer escalonar apenas algumas réplicas e não outras. Em geral, você gostaria de dimensioná-los todos simetricamente. A razão para isso é que a carga de trabalho precisa ser consistente em todos os nós e conjuntos de réplicas. Isso se deve ao fato de que, apesar de os direitos Go para o primário, os secundários também precisam acompanhar esses direitos. De qualquer forma.
michael lynn (29:12): eu só queria mostrar essa pergunta de escala automática aqui.
andrew davidson (29:16):Ah, sim.
michael lynn (29:17): Sim, lá Go nós. Então, se estou implantando um M30, posso especificar no mínimo, gostaria de Go para um M20 e, no máximo, com base no perfil de leitura-gravação e no aplicativo de atividade, gostaria para Go para um máximo de um50 M , por exemplo.
Andre Davidson (29:33): Exatamente.
Nic Raboy (29:35): Mas talvez eu esteja perdendo alguma coisa ou talvez nem seja importante com base em como as coisas são projetadas. Mike está mostrando como aumentar e diminuir a escala de M20 para M50, mas e se eu quisesse que todos os novos nós aparecessem 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ê quer dizer é: e se eu quisesse escalar 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 é a forma como recomendamos o dimensionamento. Costumamos recomendar o dimensionamento vertical em vez de adicionar réplicas de leitura. [crosstalk 00:30:14]
Nic Raboy (30:14): Ok.
Andrew Davidson (30:14): A razão para isso com o MongoDB é que, se você escalar as leituras com réplicas, o risco é que você se encontre em uma situação de falha crescente, na qual você sobrecarrega todas as suas réplicas de alguma forma, e então uma delas cai e, de repente, você tem a mesma carga de trabalho indo para um pool ainda menor. Portanto, tendemos a dimensionar verticalmente e/ou introduzir o sharding quando se trata desse tipo de escala. No entanto, há cenários em que, para o seu ponto, você meio que deseja ter réplicas de leitura em outras regiões, digamos, essencialmente. atender ao tráfego dessa região com baixa latência e esses tipos de casos de uso. É aí que acho que você está 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 selecioná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 na AWS, GCP e Azure, e temos nós ímpares. OK. Está tudo bem por lá. Selecionaremos nossa camada de 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? Algum outro recurso que está faltando?
andre davidson (31:47): Não que eu possa pensar. Devo dizer que, até o momento, tivemos uma adoção inicial interessante. Não vou citar nomes, mas vimos pessoas aproveitarem a movimentação entre os provedores de nuvem e vimos algumas pessoas espalharem seus clusters por vários provedores de nuvem em um país de destino, como mencionei, podendo 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. Vimos casos de uso de serviços de emergência. Portanto, é uma ótima validação inicial ter isso no mercado e ter tanto entusiasmo com os 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? Há algo que você possa compartilhar sobre o que está por vir?
Andrew Davidson (33:13): Olha, vamos continuar crescendo, mais rápido, mais clientes, mais escala. É tão emocionante. Agora, estamos transmitindo para o Atlas alguns dos maiores jogos do mundo, alguns dos aplicativos financeiros mais populares para consumidores, aplicativos que fazem a vida dos consumidores funcionar, aplicativos que permitem que os fabricantes continuem a construir todas as coisas das quais dependemos, aplicativos que são poderosos para um público verdadeiramente global. Estamos vendo uma adesão e um crescimento incríveis e economias em desenvolvimento. É um momento muito interessante e estar na linha de frente de ver desenvolvedores realmente transformando a economia, a transformação digital que está ocorrendo.
Andrew Davidson (33:57): Vamos Go, focar em onde nossos clientes querem que Go para gerar mais valor para eles e continuar ampliando a plataforma de dados. Acho que mencionei que a pesquisa é um grande foco para nós, aumentando o banco de dados transacional operacional tradicional, o reino, a comunidade de bancos de dados móveis e, essencialmente, possibilitando a criação desses excelentes aplicativos móveis e sincronizando-os novamente com a nave-mãe da nuvem. Estou muito empolgado com isso e com a preparação global para o lançamento do 5g. Acho que será incrível assistir à possibilidade em dispositivos móveis no próximo ano. Sim, há muito. Muita coisa vai acontecer e todos nós faremos parte disso juntos.
Michael Lynn (34:34): Parece incrível.
Nic Raboy (34:34): Se as pessoas quisessem entrar em contato com você depois que o capítulo fosse ao ar, você no Twitter, LinkedIn? Onde você prefere que as pessoas entrem em contato?
andrew davidson (34:43): eu apenas recomendamos que as pessoas e-mail diretamente: 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 reservar um tempo do seu dia agitado. Esta foi uma ótima conversa. Gostei muito de aprender mais sobre multinuvem e estou ansioso para tê-lo no podcast novamente.
Andrew Davidson (35:08): Muito obrigado. Tenham um ótimo resto de dia, pessoal.
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 a replicação manual de dados, e as empresas podem focar seus recursos técnicos na criação de software diferenciado.
Confira os seguintes recursos para obter mais informações:
Avalie esse Podcast