Startup de 1 pessoa só: Tudo sobre as Tecnologias, Infraestrutura e Frameworks

Cuidado com este vídeo, tá? Porque ele é do tipo que se você tem um emprego, por exemplo, você vai querer sair para fazer sua startup de uma pessoa só. No mínimo, fazer um side project.

Ou se você não tem um emprego, neste vídeo, você vai ver que é possível transformar aquela sua ideia massa num projeto real, numa ultra micro startup gerenciada somente por você e os seus sistemas. Eu digo isso porque para ver este vídeo, eu estudei a fundo três artigos escritos pela mesma pessoa sobre como ela montou a sua startup de uma pessoa só e mostrar em detalhes tudo o que foi feito na parte de tecnologia, quais softwares ela usou e com isso também vocês vão conhecer vários servicinhos delicinha e, inclusive, como ela organizou a infraestrutura, os servidores. .

. Mas talvez o mais importante é que essa pessoa tem um detalhe no perfil dela. Ela tem aversão a overengineering, que é o excesso de engenharia, vamos colocar assim.

. . E também aversão a overthinking, que é o excesso de pensar demais e não sair do lugar.

Inclusive, num dos artigos tem um tweet dela que se você é desse tipo de pessoa que gosta de pensar demais, talvez vai ser um soco no estômago, tá? Segura a respiração. .

. "O seu pensar demais é a minha oportunidade. " Quantas vezes você teve uma ideia massa, mas por medo de não achar que ela era o suficiente, você ficou pensando, pensando, pensando.

. . Até o ponto de ter dado tempo suficiente para você assistir outra pessoa lançando a mesma ideia na sua frente, e às vezes numa versão ainda mais porca e ver dando certo?

Aí você fica eternamente falando: "Olha lá, eu que tive a ideia primeiro. " Quem cansou disso foi o Wenbin Fang e ele descreve em detalhes como construiu sozinho a sua startup chamada ListenNotes. E a história, a sacada que ele teve é muito boa e mostra que você não precisa ter uma ideia visionária, algo que precise explodir a cabeça de alguém para dar certo.

Muito pelo contrário, ele fala isso de uma forma bem pé no chão. E falando em podcasts, o serviço dele é sobre isso e a ideia começou quando percebeu que para ele, os podcast eram a nova Wikipédia, que é muito conteúdo criado em formato de episódios. Olha só em comparação.

. . A Wikipédia tem 6 milhões de artigos em inglês.

O IMDB, que é um banco de dados de filmes e séries, tem 6. 5 milhões de títulos. O Spotify tem 50 milhões de músicas e os podcasts já somam 61 milhões de episódios.

E sabe qual que foi a ideia simples dele? Fazer um buscador de podcasts e ele começou como um site project enquanto trabalhava numa outra empresa. Ele disse que na empresa que ele estava trabalhando fulltime como um programador na época, a maioria dos colegas ficava escutando música enquanto estavam trabalhando.

Mas ele, em especial, se sentia culpado em não aprender coisas novas e ao invés disso ficar escutando música o dia todo. Cada um com suas escolhas, não é mesmo? Daí, ele começou a consumir muito podcast, mas ele começou a consumir de um jeito diferente e eu achei bem interessante.

Ele não queria mais acompanhar todos os episódios que um show em específico ia publicar, porque ele queria começar a acompanhar tópicos. Então, ele criou o ListenNotes para agregar todos os podcasts do mundo para ele começar a procurar por um tópico em específico que ele queria escutar e aprender a respeito, só que a sacada não parou por aí. Olha que legal.

. . Ao longo do tempo, ele foi adicionando mais features nesse projetinho e uma delas foi você receber notificações quando alguém no mundo publicasse algum episódio que tratava daquele tópico que você estava interessado.

E é nessa parte que o serviço dele começa a gerar uma renda para ele, inclusive ele cobra US$5 a cada cinco alertas. Aí você pensa: "Quem é que vai gastar dinheiro com isso", não é mesmo? Então.

. . Depois de um tempo, ele saiu da empresa que ele trabalhava como programador e tornou isso o seu trabalho fulltime.

E a gente vai ver aqui inclusive uma foto do "mega escritório de uma pessoa só" dele. E tem motivos bem interessantes para você querer pagar por um serviço como esse. Por exemplo, o que me veio em mente é.

. . Se você é um repórter e está cobrindo ou acompanhando um assunto mega importante.

Para esse repórter, seria uma mão na roda deixar um robozinho lhe avisando em tempo real, caso alguém no mundo tenha publicado alguma coisa nova, algum episódio novo cobrindo esse assunto. Ou até para o time de Marketing ou Relações Públicas de uma empresa, ou uma pessoa famosa ficar monitorando por termos e tópicos sobre a empresa para entender o que as pessoas estão falando por aí. E o legal é que em cima da mesma infraestrutura, e a gente já vai ver a parte técnica daqui a pouco, você consegue começar a engatar várias outras fontes de renda, como por exemplo.

. . Ele fez uma feature que você consegue baixar em CSV o resultado de uma busca e ele cobra pela quantidade de informações encontradas.

Outra fonte de renda dele é cobrar pelo uso de uma API que dá acesso a todo o conteúdo que foi rastreado por ele. E eu acho isso muito legal, porque todas as informações estão disponíveis no meio na internet, mas num estado completamente bagunçado. E é legal perceber que você começa a gerar valor para outras pessoas, para outras empresas, por conseguir agregar e limpar tudo isso.

Aí eu me pergunto: "Quantos temas, quantas coisas no mundo ainda ainda precisam de um agregador? Ou quantas coisas novas que vão ser criadas e que vão precisar de um agregador? " Como foi o hype das criptomoedas, por exemplo.

Vamos prestar atenção em qual vai ser o próximo hype, porque agora a gente vai ver a parte técnica, como ele levantou esse serviço, começando pela infraestrutura. Ele roda tudo na AWS. .

. Na verdade, ele começou utilizando o DigitalOcean, e aí depois migrou para AWS para construir um setup mais profissional, que ao todo utiliza 20 servidores no ambiente de produção. Esse é o print de todos eles listados e para quem está começando, isso pode intimidar um pouco.

Mas acompanha o vídeo que eu vou revisar com você a responsabilidade de cada um, inclusive com um diagrama que vai ficar mais fácil de entender a relação entre cada uma dessas peças. Aliás, eu quero publicar a mais pra frente um outro vídeo bem similar a este aqui, mas que traz quanto custa tocar um projeto assim. Então, verifica se você está inscrito para não perder essa informação, fechado?

Então sobre os servidores, o nome de cada um e as suas responsabilidades, tudo o que tem escrito production-web são servidores que hospedam o site, o "listennotes. com", que é o que você vai acessar como usuário. E como a gente pode ver, tem duas máquinas reservadas para isso.

Quem manja de infraestrutura, conhece analogia "Pets and Cattle", que é dar nomes para as máquinas, para os servidores como se fossem animais de estimação, ao invés de tratá-los como "gado". Mas deixa isso de lado, porque por enquanto, o objetivo do autor, na verdade, é ser mega simples. Então, para você chegar nos servidores production-web1 e 2, na verdade o usuário passa por um load balancer e a gente pode conferir isso na lista pelo nome production-lb1.

E como eu falei antes, a gente já vai ver um desenho mostrando o fluxo de tudo isso quando terminar aqui as explicações dos servidores. Muito importante nessa infraestrutura é o banco de dados que está representado pelo production-db1 sendo o master e mantendo uma réplica no slave production-db2. Ele está usando o Postgres para isso e encara o banco de dados como um Single Source of Truth, ou fonte única de verdade.

Ou seja, independente da existência de algum desses dados em outro lugar em formato de cache, por exemplo. . .

Não interessa o que aconteça com esse dado específico, se ele ficar desatualizado de uma forma errada. A fonte verdadeira da informação sempre vai ser o Postgres. E como a gente tocou no assunto cache, pelo fato de o ListenNotes ser um buscador, fica muito pesado fazer esse tipo de operação contra o Postgres.

Então, ele utiliza um cluster com três máquinas com Elasticsearch, que é perfeito para fazer full text search e isso é representado pelos servidores production-es1, 2 e 3. E para rodar o crawler pela web, a busca de novos podcasts que é uma tarefa muito demorada, e também para construir manter o cache do elasticsearch atualizado para calcular o ranking dos episódios nas buscas e enviar alertas, tudo isso faz parte de uma infraestrutura que ele chama de assíncrona e isso é representado pelos production-workers que vão de 1 a 8. E quase terminando, para conseguir fornecer uma API, ele utiliza mais três máquinas.

Uma delas, a production-v1api1, é responsável por servir a primeira versão da API, que é uma versão legada, uma versão antiga. E a versão nova é servida por duas máquinas: production-v2api1 e 2. Por último, ele tem uma máquina maluca chamada production-pangu, que é uma máquina com todas as características de produção que ele usa para rodar scripts e fazer testes.

Ele não foi muito claro nessa parte, mas eu especulo que talvez ele roda scripts de migration do banco de dados. Não sei. .

. Bom, agora como prometido, vamos ver como ficam todas essas máquinas num diagrama. Vocês podem notar que a infraestrutura é segmentada em duas grandes partes: a parte síncrona, na esquerda, e a assíncrona, na direita.

A parte síncrona é um serviço web padrão, onde uma request é feita através de um navegador, e essa request bate no load balancer, que divide a carga entre as máquinas web. . .

Depois, a máquina web pede para a camada de dados, que ali ele representou como Datastore. . .

E a gente já vai ver o que tem dentro disso. . .

E o Datastore retornou dado para a aplicação web que retorna para o load balancer, que daí retorna para o usuário. A gente já vai ver, inclusive, em qual linguagem foi programado tudo isso numa versão de ilustração que mostra as tecnologias, uma versão mais micro. .

. Mas antes, só para explicar agora a parte assíncrona da infraestrutura. Nota que no topo, a gente tem aquela lista de workers, que são as máquinas responsáveis por fazer o trabalho pesado, ou um trabalho de longa duração.

E quem organiza no que esses workers vão trabalhar é o Message queue, logo ali embaixo. E se vocês notarem, tem o Scheduler ali na direita, que é um agendador de tarefas. Ele consegue ordenar que tarefas sejam executadas de tempo em tempo, por exemplo, a cada hora ordenar que os workers busquem por novos episódios na internet.

Agora, entrando naquela visão mais micro, mais detalhada, a gente sai dessa visão e vai para essa, e seguindo na mesma ordem, a gente pode ver que para o load balancer, ele utilizou Nginx e no back-end ele utilizou Django, que é um framework web escrito em Python bastante famoso, e na camada de dados, ele utilizou Postgres, Elasticsearch e Redis. Na camada assíncrona, ele utilizou o Celery para os workers que também é escrito em Python, e se comunica muito bem com o RabbitMQ. O RabbitMQ é um message broker, um intermediário de mensagens, e ele, inclusive, consegue enfileirar as mensagens e gerenciar o consumo disso.

Por último, para o Scheduler, para o agendador, ele também utiliza o Celery. Na verdade, ele utilizou o Celery Beat. Uma coisa que você pode estar querendo sugerir para ele é: "Pô, põe um docker aí.

. . Um kubernetes.

. . Serveless, que tal?

" Bom, nessa parte, ele é bastante seco na resposta. Eu entendo perfeitamente. Eu só me questiono que o "não overengeneering" de hoje em algum momento foi o overengeneering lá do passado.

Não é mesmo? ! Talvez o que define o quão over ou não você está é o quão maduras estão as abstrações que você está utilizando.

Não sei. . .

Vocês topam conversar sobre isso nos comentários? Então, para a gente fechar essa parte de back-end e infraestrutura para a gente ir para o que foi usado no front-end, uma coisa muito importante é gerenciar todo esse parque de máquinas e ele faz isso usando o Ansible. Show!

Fechado essa parte do back-end, tem muita coisa legal para mostrar ainda, começando pelo. . .

Nessa camada, ele utilizou o React como framework front-end somado ao Redux para controle de estado e o Webpack como bundler. O legal é que ele fez algo bem desacoplado, porque os estáticos gerados pelo bundler, na hora do deploy, são enviados lá para o S3 na AWS e são cacheados pelo CloudFront, que é a CDN da Amazon. Uma parte importante da experiência do usuário na versão web é o player.

. . E para isso, ele utilizou react-media-player.

Na verdade, uma versão desse módulo que ele customizou tudo. E para dormir tranquilo sabendo que tudo isso aqui está de pé, a gente vai entrar agora no que ele usa para monitoramento. Ele usa um serviço que eu sempre quis usar, mas eu nunca tive oportunidade, que é o Datadog.

Parece dar gosto de utlizar de tão delicinha que é. E na boa, olha esse logo. .

. É irresistível! O massa é que ele conecta o Datadog num outro serviço chamado PagerDuty e se o Datadog identificar alguma anomalia nas estatísticas, ele avisa ao PagerDuty e a missão desse serviço é te caçar até te encontrar, seja por e-mail, SMS, push notification, ligação.

. . Até você explicitamente falar: "Ok, eu estou ciente do problema.

" Na verdade, você pode configurar várias regras e isso é muito legal quando você está trabalhando num time, por exemplo, porque você pode instruir para que ele tente ligar primeiro para uma tal pessoa, se ele não responder com tantas tentativas, tenta ligar para uma outra pessoa. . .

Se daí não conseguir, escala isso para um grupo inteiro e assim vai. E antes de a gente entrar na parte de qual programa ele utiliza para desenvolver tudo isso e até uma foto do escritório, tem um negócio que ele falou que eu achei muito legal. Sabe o Slack, que você usa para conversar em grupo?

Então, ele usa o Slack na startup de uma pessoa dele e olha que massa. . .

Como ele não tem ninguém para conversar dentro da empresa, ele fez várias automatizações para publicar numa sala do Slack informações que podem motivá-lo. Como, por exemplo, um aviso mostrando que um usuário acabou de se registrar, ou acabou de comprar um produto premium e coisas assim. Show!

E agora, a gente vai entrar na parte de desenvolvimento. Para escrever o código, ele utiliza o editor chamado PyCharm. E eu nunca utilizei.

. . Mas parece fazer sentido, dado que o back-end dele é programado todo em Python.

Sobre onde o código fica hospedado, ele utiliza o GitHub e organiza as aplicações back-end, front-end e scripts gerais, utilizando a filosofia do Monorepo. Ou seja, todas as camadas ficam dentro do mesmo repositório. No ambiente local, na máquina dele, ele utiliza o Vagrant em conjunto com o VirtualBox para simular um ambiente de produção.

Assim, ele tem uma garantia a maior do que o que está sendo programado vai de fato funcionar no ambiente final. E para trabalhar em tudo isso, ele alugou uma salinha no WeWork. E sobre por que não trabalhar de casa, na defesa dele, ele se diz muito mais produtivo num ambiente especializado para trabalho.

Bom, faz sentido. Cada caso é um caso, porque em algumas situações, de fato é difícil se concentrar em casa. E segue agora alguns outros serviços que ele utiliza para tocar a empresa no dia a dia.

E super conectado a isso, tem um vídeo aqui do canal que vai servir com uma luva, caso você não esteja com ideias do que desenvolver para sua startup de uma pessoa só. O vídeo se chama "80 Ideias para Aprender a Programar" e, inclusive, eu destaco quais dessas ideias você consegue gerar uma renda com anúncios. Em um vídeo que vai fazer sua cabeça ferver com ainda mais ideias, porque você vai misturar com o seu contexto, eu tenho certeza absoluta.

Então, para ver esse vídeo é só clicar aqui. Fechado? Valeu!