Tendências em cultura e métodos de desenvolvimento para 2020 – Parte 4

Nesta quarta e última parte da minha série sobre as tendências em métodos e cultura de desenvolvimento de software para 2020 vamos explorar as duas últimas categorias de tendências segundo a pesquisa publicada pela InfoQ em março deste ano, cujo gráfico você confere abaixo.

Tendências em Cultura e Métodos 2020
Tendências em Cultura e Métodos 2020

Late Majority é, como o próprio nome diz, a maioria mais atrasada do mercado. Como bem apontado por G. Moore em Crossing the Chasm, não é apenas um crescimento comum de mercado sair do lado esquerdo da  Curva de Difusão da Inovação de E. Rogers para o lado direito. Existe um abismo que antecede a difusão de uma inovação de qualquer tipo para o grande mercado. Esse abismo se traduz como diferenças culturais gritantes entre os inovadores e os conservadores, se traduz no custo quando falamos de inovações em hardware e pode ser traduzido como também o “medo do novo”. Afinal, quem não lembra do medo de adotar métodos ágeis na primeira década deste século?

É importante ressaltar que, apesar de algumas tendências que você não conheça ou não pratique ainda estejam nesta última categoria, não as negligencie por elas não serem mais trendy. Scrum por exemplo, estar em Late Majority não indica que ele caiu em desuso, mas que sim, se tornou mainstream a ponto de estar sendo considerado como commodity em muitas empresas mais inovadoras e é uma tendência que acabara de chegar em empresas mais conservadoras.

Atenção: partes deste artigo são iguais a outros que escrevi em 2019, como esse para o blog da BossaBox e esse para o site Startupi, pois algumas das tendências ainda se mantém.

Algumas partes são citadas por mim também na palestra abaixo, onde passo superficialmente por vários itens.

Curso de Scrum e Métodos Ágeis

Late Majority, Antes tarde do que nunca…

E por fim, temos outra grande fatia do mercado que são a “maioria atrasada”. Você imagina descobrindo ou adotando hoje práticas e tecnologias dos anos 90? Pois é, estas empresas estão fazendo isso. Mas não julgue, não é uma questão de escolha, é uma forte pressão do mercado para que elas se modernizem.

Empresas que hoje, se recusem a entender a importância dos assuntos citados a seguir estão fadadas a caírem no ostracismo ou na categoria Laggards (retardatários), que a InfoQ nem mesmo perde tempo representando em seu gráfico. Apesar de estarem atrasadas, o fato de estarem olhando para estes assuntos já as põe em posição de se reinventarem, simbolizando uma luz no fim do túnel de negócios que possam estar estagnados e sofrendo com a forte concorrência.

Além disso, lembre-se que, todos estes assuntos já foram mega inovadores e são a base para entender o que veio depois deles. Pular etapas não é uma opção, na minha opinião, e se você ainda não domina eles, dificilmente conseguirá absorver os seus sucessores.

Scrum

O Scrum dispensa apresentações. Todas as pesquisas possíveis sobre métodos ágeis como a State of Agile e a State of Scrum mostram números gigantescos de adoção de Scrum nas empresas ao redor do mundo, superando 70% das empresas que dizem estar rodando algum método ágil.

Com isto, podemos dizer que o Scrum é o padrão de facto para desenvolvimento de software utilizando métodos ágeis e que toda empresa que estiver pensando em passar a desenvolver com agilidade deveria dar uma chance para este framework que já foi inovador e hoje se tornou mainstream.

Vanilla Agile

O termo Vanilla, na tecnologia, refere-se aos fundamentos de algo, fazendo uma alusão ao sabor de baunilha que é o mais genérico e básico possível dentre os sorvetes. Assim, Vanilla Agile refere-se à essência elementar da agilidade.

Aos poucos, mais e mais empresas estão descobrindo que ser ágil não é rodar Scrum. Estão descobrindo o Manifesto, descobrindo os princípios e incorporando um ou mais elementos no dia a dia.

O mais difícil, no entanto, tem sido elas não caírem em um GoHorse Gourmet como alguns estão chamando por aí. Ou seja, abrirem mão completamente de processos alegando que assim serão mais ágeis. Frameworks mais modernos como Modern Agile e Heart of Agile (este último criado por Cockburn, um dos signatários originais do Manifesto) tentam trazer um equilíbrio a essa nova situação que estamos vivendo, de descrença com algumas receitas e as armadilhas do Go Horse Gourmet.

Scaling Frameworks

Escalar métodos ágeis em grandes organizações é hoje uma arte que a todo custo estamos tentando transformar em ciência. Da adoção de agilidade pelo PMI à criação de grandes empresas em torno de frameworks como a Scaled Agile Inc, todos estão tentando resolver essa equação, de como escalar o ágil sem torná-lo outro waterfall.

Médias e grandes empresas que estão iniciando hoje suas transformações digitais tendem a assumir abordagens bimodais como a proposta do Gartner, enquanto outras tentam ir para o chamado “modelo Spotify” de escalar o ágil. Só o tempo dirá se teremos um vencedor ou se criaremos ainda outros modelos e receitas de escalar o ágil. O que não faltam hoje são opções além e SAFe e Spotify: Less, Scrum at Scale, Nexus, DAD, etc.

ALM Tools

ALM é uma sigla para Application Lifecycle Management ou Gestão do Ciclo de Vida de Aplicação. Do início dos anos 2000 para cá evoluiu-se muito em termos de ferramental para fazer a gestão das nossas aplicações. Com a popularização de arquiteturas mais modularizadas como microservices e nanoservices (serverless) e de tecnologias que elevaram essa modularização a um nível nunca visto antes, como Docker e Kubernetes, tivemos o surgimento de uma nova disciplina chamada DevOps, cada vez mais na boca dos profissionais de tecnologia de todas empresas.

Conceitos como Infra as a Code e Continuous Delivery não são mais “rocket science” e finalmente são objetivos alcançáveis a baixo custo. Absolutamente todas empresas que trabalham com software já ouviram falar disso e mesmo a categoria Late Majority deve investir pesado em pipelines e nuvem neste ano de 2020.

Cross-functional Teams

Agilidade é sobre times e quando se fala de times ágeis a primeira coisa que vem em mente é a pluralidade de habilidades. Times cross-funcionais ou multi-funcionais são aqueles que possuem todas as competências necessárias para entregar uma solução fim-a-fim (os chamados Feature Teams). É o contraponto à organização tradicional de times em silos, onde temos os especialistas de cada tecnologia ou camada de aplicação em cada silo, gerando extrema dependência de um time do outro e desacelerando a possibilidade de entregar valor em um lead time mais curto.

No famoso artigo de 1986 de Takeuchi e Nonaka, The New New Product Development Game, já se falava do poder que os times multi-funcionais estavam trazendo às empresas que adotavam esse modelo de trabalho à época. Não à toa que esse artigo inspirou o desenvolvimento do framework ágil Scrum, trazendo o conceito de time esportivo (rugby nesse caso) ao mundo do software, onde são necessárias diferentes habilidades em um mesmo time para conseguir vencer a partida. Já imaginou ter um time de futebol com 11 atacantes? Será que ele venceria todas partidas? E porque algumas empresas ainda insistem em ter times com apenas programadores de backend ou frontend? Ao menos a grande maioria já entendeu isso, segundo a pesquisa da InfoQ.

Justamente uma das principais competências trabalhadas na BossaBox é a construção de times multi-funcionais para atender às necessidades de desenvolvimento dos clientes, pois entende-se que esse é o caminho para a agilidade na entrega de valor.

E com essa quarta parte nós encerramos esta série sobre tendências em métodos e cultura de desenvolvimento de software para 2020. De forma alguma esta série cobriu tudo o que está acontecendo neste mundo de TI, e nem mesmo deu uma compreensão aprofundada de cada um dos tópicos apresentados. E a ideia nem era essa.

Se você terminou de ler com o sentimento de que tem muita coisa para aprender ainda, pois é, somos dois e estou muito feliz que eu não seja o único. Esse era meu objetivo principal: tirar você da incompetência inconsciente para a incompetência consciente. Agora com essa to-do list de coisas a estudar, espero que possa se antever às mudanças que estão chegando, além é claro de buscar o que pode ter deixado para trás por descuido.

Um abraço e até a próxima!

Quer um material de referência para Transformações Ágeis em empresas? Conheça meu livro sobre o assunto clicando no banner abaixo.

Livro para Agile Coaches

Tendências em cultura e métodos de desenvolvimento para 2020 – Parte 3

Nesta terceira parte da minha série sobre as tendências em métodos e cultura de desenvolvimento de software para 2020 vamos explorar a penúltima categoria de tendências segundo a pesquisa publicada pela InfoQ em março deste ano, cujo gráfico você confere abaixo.

Tendências em Cultura e Métodos 2020
Tendências em Cultura e Métodos 2020

Early Majority é, como o próprio nome diz, a maioria do mercado mais ligada em inovação. Como bem apontado por G. Moore em Crossing the Chasm, não é apenas um crescimento comum de mercado sair do lado esquerdo da  Curva de Difusão da Inovação de E. Rogers para o lado direito. Existe um abismo que antecede a difusão de uma inovação de qualquer tipo para o grande mercado. Esse abismo se traduz como diferenças culturais gritantes entre os inovadores e os conservadores, se traduz no custo quando falamos de inovações em hardware e pode ser traduzido como também o “medo do novo”. Afinal, quem não lembra do medo de adotar métodos ágeis na primeira década deste século?

É importante ressaltar que, apesar de algumas tendências que você não conheça ou não pratique ainda estejam nesta penúltima categorias, não as negligencie por elas não serem mais trendy

Atenção: partes deste artigo são iguais a outros que escrevi em 2019, como esse para o blog da BossaBox e esse para o site Startupi, pois algumas das tendências ainda se mantém.

Algumas partes são citadas por mim também na palestra abaixo, onde passo superficialmente por vários itens.

Early Majority, Os Pragmáticos

Empresas nesta categoria são o grande filão do mercado, empresas que acabaram de perceber o que de fato está acontecendo com o desenvolvimento de software e, uma vez que muitas das empresas que eles admiram (innovators e early adopters) estão comprovadamente tendo sucesso na adoção de novas práticas, passam a adotá-las também.

Empresas pragmáticas não seguem tendências até que elas tenham cruzado o abismo, ou seja, que tenham se provado ao longo de algum tempo em diversas outras empresas. Na atualidade, são todas aquelas empresas que estão passando por transformações digitais, por exemplo, mas que em sua maioria não nasceram de tal forma.

Curso de Scrum e Métodos Ágeis

Remote-Only Teams

Times remotos. Atire a primeira pedra qual desenvolvedor de software nunca sonhou trabalhar de casa ou de qualquer outro lugar do mundo. Existem empresas com políticas flexíveis para homeoffice e existem empresas que de fato abraçaram o jeito remote-only de se trabalhar, como a BossaBox (que atua justamente na mediação dessa relação) e outras mais icônicas como Basecamp (que inclusive lançou um livro específico sobre o assunto).

Para os desenvolvedores, a flexibilidade de horário, a economia de tempo com o commuting, a ausência de dress code, silêncio, seu café e suas regras de Internet, são alguns dos benefícios, além da tão almejada geoarbitragem (gastar em Reais e ganhar em dólares ou outra moeda forte).

Para a empresa, redução de custos com infraestrutura, maior facilidade de atrair talentos de todos os cantos do mundo e, para empresas globais, a tão sonhada produtividade 24×7 (profissionais em diferentes fusos gerariam um fluxo de trabalho ininterrupto 24h por dia).

Obviamente existem desafios, mas hoje, com a situação mundial da pandemia do Covid-19, absolutamente todas empresas que desenvolvem software já estão praticando o home office e até o desenvolvimento de projetos de todos os tamanhos usando times remote-only. 

Pragmatic Agility

Pragmatismo é a palavra-chave que separa os Early Adopters da Early Majority, certo?

Nada é mais pragmático do que olhar a agilidade com um viés de “caixa de ferramentas” e, dadas as suas necessidades, escolher aquelas mais se adequem às suas necessidades. A velha guerra das metodologias, que ainda não acabou, não produz nada de benéfico uma vez que as pessoas parecem tender a uma “futebolização” dos métodos, como se eles estivessem no mercado para competir uns contra os outros. Perguntas como: qual o melhor, Scrum ou Kanban? não possuem uma única resposta, a não ser que você esteja perguntando a um dos muitos “especialistas” que costumam ser vendedores da empresa A ou B.

Agilidade é sobre reagir à mudança. O Manifesto não fala nada sobre seguir uma única cartilha como se ela fosse a verdade universal.

Craftmanship

Craftsmanship é um termo apresentado em 2000 no livro Software Craftsmanship de Pete McBreen e propõe uma nova abordagem de ver o desenvolvimento de software, mais ligada ao artesanato do que a uma fábrica de software. McBreen disserta muito sobre essa ser uma profissão onde se evolui na base da mentoria, como os antigos artesão faziam, e não de maneira formal. De que não temos como aplicar a mesma solução para problemas diferentes, o que faz com que cada projeto seja único, como uma obra de arte. O que temos em comum entre eles? Princípios de desenvolvimento.

Fortemente baseados nestes princípios, os software craftsmen ou apenas crafters, constroem uma solução adequada para o problema do cliente, de maneira extremamente pragmática, utilizando as melhores ferramentas para o problema em questão e jamais o contrário. Colocar a tecnologia antes do problema é o primeiro passo para o fracasso técnico de um projeto.

Mais tarde, Robert C. Martin (Uncle Bob), levou adiante esses conceitos carregando muito do discurso de craftsmenship em suas obras e dissertações como Clean Code, Clean Architecture e na construção do SOLID. Por vezes Bob é assumido como idealizador do movimento, mas não o é como ele mesmo admite.

É importante ressaltar que, apesar do ‘man’ no nome, a ideia não é gerar exclusão de gênero. O termo craftsperson tem sido mais utilizado hoje em dia por ser mais inclusivo neste sentido.

BDD/DDD

Behavior Driven Development (BDD) e Domain Driven Design (DDD) são duas siglas técnicas muito populares no meio de desenvolvimento de software tem vários anos e não cabe a mim tentar explicá-las no detalhe em um artigo como esse, então me aterei a resumi-las, para fazer você ter uma ideia do motivo pelo qual as empresas pragmáticas estão adotando-os este ano.

O Desenvolvimento Orientado a Comportamento (BDD) criado por Dan North, é tida por muitos como uma evolução do TDD (Desenvolvimento Orientado a Testes). Não apenas uma mudança no hábito de programar, partindo dos testes, mas uma mudança no jeito de pensar especificação de software (de maneira colaborativa entre análise, desenvolvimento e testes) e construção do mesmo baseado no que esperamos que os usuários façam no sistema. Afinal, construímos os sistemas para eles, e não para nós, não é mesmo?

Já o Desenvolvimento Orientado a Domínio (DDD) criado por Eric Evans, é uma abordagem de desenvolvimento de software focada no domínio da aplicação. Um domínio pode ser uma atividade-chave ou uma área de conhecimento, por exemplo, o que quer dizer que o software deve se focar em atender a esse domínio acima de tudo.

Estas duas práticas tem muito a ver como a maioria das empresas de mercado tem se reinventado na forma de vender seus serviços e de projetar seus softwares, de maneiras mais centradas nas necessidades e satisfação de seus clientes e objetivos de negócio. BDD e DDD ajudam muito neste sentido.

Coaching/Mentoring

E meio a tantas hard skills dentro das corporações, duas soft skills têm ganhado muita popularidade nos últimos anos: coaching e mentoring, em especial a primeira.

Eu falei bastante de coaching no primeiro capítulo desta série. Já o mentoring é o processo de ajudar um indivíduo com orientação em uma área de conhecimento específica, de domínio do mentor. Um mentor é um profissional experiente em um determinado campo de estudo ou competência que ajuda seu aprendiz a não cometer os mesmos erros, a aprender mais rápido e a ter resultados parecidos com os seus ou até melhores. Note que na maioria dos casos o mentor já trilhou o caminho que o aprendiz está trilhando naquele assunto, sendo um profissional procurado em busca de respostas.

Processos de mentoria e coaching estão cada vez mais comuns em empresas de todos os tamanhos. É uma resposta rápida para acelerar o crescimento dos profissionais, o atingimento de metas e até mesmo para práticas mais modernas de gestão e desenvolvimento de pessoas. Não à toa, caiu nas graças da grande maioria das empresas modernas. 

Curiosamente, o Agile Coach, papel cada vez mais comum em empresas passando por transformações digitais, tem um pouco dos dois: ele é um mentor de agilidade e um coach de pessoas. 

Full-Stack Product Teams

Se temos uma máxima em times ágeis é que eles precisam ser multi-funcionais, certo? No entanto, o que mais se vê por aí são os times pseudo-multi-funcionais, ou seja, que possuem todas as skills de programação presentes mas pecam no restante do ciclo de desenvolvimento do produto quando se olha o todo. Afinal, quem dá o suporte ao produto? Quem faz o marketing do mesmo? Quem mantém a infraestrutura operando e monitorada? Entre outras tantas questões.

Dos clássicos times multifuncionais da Toyota ao vídeo do Spotify Engineering Culture, não é de agora que se fala da necessidade de se quebrar silos e construir esse tipo de time. Nesse artigo você encontra dicas práticas de quem já está fazendo isso. Nesse outro, o que se espera de um profissional full-stack de produto. Já esse outro questiona se isso é viável ou mesmo necessário, afinal, precisamos de pontos de vista diferentes, não é?

DevSecOps

No passado nós tínhamos dois departamentos muitas vezes rivais dentro da TI: desenvolvimento e infraestrutura/operações. Eram disciplinas e cultura completamente diferentes, havia pouca colaboração e cada cuidava apenas do seu “quadrado”.

Então surgiu a cultura DevOps e seu conjunto de ferramentas que tornaram a cultura de operação (Ops) mais próxima da desenvolvimento (Dev) e vice-versa. Com as tecnologias cada vez mais Cloud Native por causa da containerização/Dockerização de tudo, surgiram termos como Infra as a Code (Infraestrutura como Código), onde os servidores são “programados” ao invés de “configurados na mão”, versionamento de bases de dados assim como se fazia com código de programação, testes por todo lado, deploy com um clique e muito mais.

Mas e quanto à segurança disso tudo? Não lhe parece que tem gente demais “metendo a mão” nos servidores? Não estariam estas ferramentas de DevOps abrindo brechas de segurança nos ambientes? Não estaríamos deixando segregado outra disciplina importantíssima de TI que é a segurança?

É com este pensamento que o termo se adequou para DevSecOps, englobando a segurança no dia a dia dos times de solução, afinal, o freio não é colocado no final da linha de produção do carro, não é mesmo?

Para saber mais sobre DevSecOps, sugiro começar por esse material aqui.

Digital Transformation

Esse é um termo que está cada vez mais famoso no Brasil, certo? Mesmo por aqui, Transformações Digitais estão eclodindo em todas grandes empresas que não querem ficar de fora da profusão de matérias sobre o tema e da atenção dos investidores. No entanto, ser digital está longe de apenas informatizar processos manuais e trocar tecnologias, exige um redesenho da organização e uma evolução de sua cultura, dois elementos muito mais delicados.

A questão é que transformações de negócios, de qualquer tipo, são extremamente custosas e arriscadas. Para um negócio se tornar digital, não basta adicionar uma camada de tecnologia, você tem de inserir a mesma nas entranhas das camadas já existentes. Não é algo que você resolve investido no departamento de TI da empresa, mas distribuindo a TI por toda a empresa. Ou então o contrário, distribuindo business por toda TI. Não importa.

A InfoQ construiu um Framework de Transformação Digital que, caso você esteja passando por isso ou planeja passar em breve, vale uma leitura, para jogar um pouco mais de luz sobre o assunto e organizar uma virada menos dolorida. Eu traduzi partes dele aqui no blog.

E com isso, encerramos a terceira parte desta série de artigos.

No próximo e último artigo da série (clique para ler), falarei dos métodos e elementos culturais que já chegaram até mesmo na maioria tardia, elementos extremamente consolidados e que se você não conhece ou não aplica, atenção!.

Até lá!

Quer um material de referência para Transformações Ágeis em empresas? Conheça meu livro sobre o assunto clicando no banner abaixo.

Livro para Agile Coaches

Publicando sua aplicação Node.js no Amazon LightSail (AWS) – Parte 3

No tutorial anterior de publicação de aplicação Node.js na AWS, eu lhe mostrei como instalar um certificado SSL, como configurar a sua aplicação no Apache para rotear os acessos ao seu domínio e a subir a sua aplicação Node.js via SFTP.

No tutorial de hoje, vamos ver como criar uma instância de MongoDB na AWS para que seus dados também estejam na nuvem pública #1 do mundo.

Atenção: este é um tutorial intermediário. Se você não sabe programar Node.js com MongoDB ainda, não comece com ele pois vai mais te atrapalhar do que te ajudar. Para iniciantes, eu recomendo meus livros e meu curso (inclusive no curso você encontra este conteúdo em vídeoaula). Infraestrutura/servidores para iniciantes eu recomendo a Umbler.

Arquitetura para MongoDB

Como meu foco nos últimos anos tem sido muito o desenvolvimento de aplicações usando Node.js e MongoDB, nada mais natural do que eu falar aqui de como fazer deploy do seu banco de dados também.

Já falei no passado sobre administração profissional de MongoDB na unha (aqui e aqui). É um jeito econômico de você ter as suas instâncias de MongoDB, mas é mais trabalhoso. Você pode criar uma instância no Lightsail com Linux e instalar o MongoDB ou mesmo instalar o MongoDB na mesma instância do Node.

A primeira abordagem é mais profissional, pois mantém isolados os recursos da sua solução, fazendo com que as configurações de um não impactem na do outro. Apenas certifique-se desta segunda instância ser criada na mesma zona da primeira, por questões de latência.

A segunda abordagem é a mais econômica possível, mas a menos profissional de todas.

No entanto, existe uma terceira abordagem que é a mais profissional possível, mas a mais cara: usar um DBaaS, um serviço de MongoDB em nuvem, como o Atlas.

MongoDB Atlas

O Atlas é o serviço de MongoDB em nuvem da própria empresa criadora do MongoDB, ou seja, é o melhor serviço de MongoDB existente (se você já usou o Mongolab/Mlab, saiba que foram adquiridos pelo Atlas).

Eles possuem templates/imagens de servidores para os principais players de cloud do mercado e com poucos cliques eles te montam um cluster próximo do seu servidor de Node, que é o que vou mostrar aqui neste tutorial.

Primeiro, acesse o site do MongoDB e dentro de Cloud, escolha a opção Atlas. Crie uma conta (não precisa nem mesmo informar cartão de crédito) e escolha um dentre os 3 planos existentes no Atlas:

  • Shared Cluster: parte de U$0/mês para um cluster de 3 instâncias em réplica com memória compartilhada e 512MB de espaço em disco, além de conexão criptografada e controle de acesso. Instâncias maiores custam a partir de U$9/mês.
  • Dedicated Cluster: parte de U$56,94/mês para um cluster de 3 instâncias dedicado e recursos avançados como auto escalonamento, rede dedicada e métricas em tempo real.
  • Dedicated Multi-Region Clusters: parte de U$98,55/mês para um cluster distribuído geograficamente.

Escolha a opção free, a da esquerda na imagem abaixo (desculpe meu rosto na imagem, tirei esse print durante a gravação de uma videoaula pro meu curso).

Planos do Atlas
Planos do Atlas

Em Cloud Provider & Region, escolha AWS em N. Virginia, pois é onde criamos nossa instância de Node.js nos tutoriais anteriores, lembra?

É importante que, apesar do Node e do Mongo ficarem em instâncias separadas, que eles fiquem na mesma região por questões de performance. Aguarde alguns minutos até a criação do seu cluster gratuito.

Criando o cluster
Criando o cluster

Logo abaixo, você tem mais configurações do cluster, sendo que a opção free é a M0 Sandbox, existindo opções pagas com 2GB e até 5GB de armazenamento. O legal desse plano inicial do Atlas é que ele é grátis pra sempre, ou seja, pode usar ele mesmo em produção, desde que não ultrapasse seus limites.

Configurando o cluster
Criando o cluster

Curso Node.js e MongoDB

Configurando o Cluster

Após o cluster ter sido criado, você terá acesso a um dashboard de monitoramento do mesmo, falarei dele mais tarde. Antes disso, acesse no menu da esquerda a opção Database Access e depois clique no grande botão verde de “Add New Database User”, como abaixo.

Database Access
Database Access

Isso irá abrir um formulário de criação de usuário, com alguns campos a serem configurados. Em Authentication Method, escolha Password, crie um username e um password para esse usuário. Em Database User privileges, temos 4 opções:

  • Atlas admin: administrador geral de todo o cluster, evite esta opção;
  • Read and write to any database: um usuário com permissão em todas bases deste cluster;
  • Only read any database: um usuário com permissão de leitura em todas as bases deste cluster;
  • Select custom role: personalizável;

Para simplificar neste momento, sugiro a opção “Read and write any database”, como mostrado na imagem abaixo. Mais tarde, dê um estudada nos privilégios existentes e crie um user para cada database, pois fica mais seguro assim.

New Database User
New Database User

O próximo passo é permitir que a nossa instância de Node.js na AWS possa acessar a instância de MongoDB. Por padrão, o cluster bloqueia qualquer tentativa de acesso externo a ele e para que seja possível a conexão entre nossas instâncias, devemos colocar nosso IP na whitelist do cluster.

Para fazer isso, acesse o menu Network Access na esquerda e clique em “Add IP Address”.

Network Access
Network Access

Digite o IP estático do seu servidor de Node.js na AWS e deixe um comentário que explique o que é esse IP (sugiro citar que é do servidor Node.js). De forma alguma recomendo usar a opção “Allow Access from Anywhere” pois ela abre o seu MongoDB para o mundo poder se conectar e isso não é legal.

Whitelist IP
Whitelist IP

Agora é hora de conectar no nosso cluster, para que nossa aplicação Node.js utilize de fato o nosso servidor de MongoDB.

Volte à tela inicial dos clusters e clique no botão Connect do seu cluster. Ele te dá algumas opções, queremos a Connect your application. As outras opções incluem informações de como se conectar via terminal de linha de comando e de como se conectar usando a aplicação MongoDB Compass, que nada mais é do que um client visual de MongoDB.

Selecione o driver e versão que estiver usando do Node.js e copie a sua connection string. Note que ela estará sem a senha, que você deve preencher manualmente por uma questão de segurança. Se estiver usando um arquivo .ENV para as configurações de acesso a dados na sua aplicação, você deve colocar essa connection string de produção no .ENV de dentro do seu servidor de Node.js.

Pronto, sua instância de MongoDB está pronta e acessível pela sua aplicação Node.js que está na AWS. Aliás, ps dois serviços são agora vizinhos na AWS!

Para saber como utilizar ela da melhor forma, sugiro ler a minha série de tutoriais de MongoDB para Iniciantes em NoSQL e/ou meu livro MongoDB para Iniciantes. Em ambos eu ensino como fazer import/export ou dump/restore da sua base local em um servidor remoto.

* Espero que este artigo tenha sido útil para você que está aprendendo Node.js e MongoDB. Para conteúdo mais aprofundado, recomendo meus livros. Para videoaulas, recomendo o meu curso online.