Então vamos lá, quando a gente está falando de escalabilidade, qual é a importância disso para os nossos sistemas? Quando a gente está falando sobre este assunto específico, a primeira coisa que a gente tem aqui é resiliência, quando a gente está falando de aumento de carga, de pico. Para quem está acostumado a fazer sistema que é mais batch, sistema que tem processamento massivo, que a gente não tem um aumento de escala de acessos, isso pode parecer esquisito. Então eu vou te falar que eu já tive vários sistemas no meu domínio, já tive que trabalhar com vários sistemas que a gente processava só batch. A gente não estava processando online, a gente não estava processando cargas que ficam mudando. Ou sistemas, por exemplo, de apoio. Sistemas que cuidam ali de um pós-venda, de um segundo momento onde o cliente não está acessando diretamente de web. A cliente de web, a gente está tendo um cliente interno que acessa e assim por diante. Nesses momentos, dificilmente você vai ter cargas de pico ali no seu sistema. Então, se você tem um sistema desse, pode não ser o seu dia a dia. Mas quando a gente está falando de sistemas, por exemplo, de marketplace, como a gente falou ali, por exemplo, da Amazon, ou sistemas da Netflix, quando lança, por exemplo, um filme novo que está muito hypado na Netflix, você tem um pico, um aumento de carga surreal em todos os serviços dele, desde o serviço de autenticação até os serviços de streaming. Quando a gente está falando da Amazon, a mesma coisa, no meio de uma Black Friday, ela começa a aumentar muito a sua necessidade de ter máquinas de pé e assim por diante. Então, esses picos, eles acabam, às vezes, ou deixando a aplicação muito lentaenta ou até derrubando por timeout. Muitas vezes a gente pega isso acontecendo. Quando a gente está falando de sistemas escaláveis, eles podem lidar com isso sem você ter uma degradação tão significativa assim do desempenho do seu sistema, tanto em caso de erro quanto em limitação de tempo de resposta. Ou seja, o throughput não fica tão ruim assim. E a gente consegue até deixar taxas muito boas, por exemplo, se eu pego hoje os sistemas que eu cuido, eles têm uma velocidade de tempo de resposta extremamente rápidos, então a gente consegue fazer isso muito bem. Quando a gente está falando sobre escalabilidade, lembra do que eu falei, a gente tem tanto escalabilidade horizontal, quanto a vertical. Então, eu não preciso só colocar mais máquinas, mas eu posso também subir aqui com a AWS, no que a gente está falando sobre configurações, etc. Eu consigo subir tamanho de máquina, assim por diante, para a gente conseguir fazer as coisas serem ainda melhores. Ou seja, uma das coisas importantes da escalabilidade que ela trouxe para a gente de ferramenta é essa resiliência quando a gente tem carga de pico e tem várias outras estratégias que a gente pode fazer diferente do que a gente tinha antes. Antigamente, quando a gente tinha aqui o nosso servidor dentro da nossa empresa, assim por diante, servidor próprio, a gente precisava, como eu falei, abrir uma aquisição de compra de máquina, equipamento, fazer todo o processo de compra e venda de coisas e com isso você acabava tendo muita demora para conseguir fazer isso. Então imagina que em uma Black Friday você tinha que se preparar 3, 4 meses antes para aquele momento, para você estar preparado caso o seu sistema não estivesse até então. Uma outra coisa também é o custo de eficiência, do mesmo jeito que você pode aumentar ou seja, eu terminei de usar aquela máquina. Imagina que eu subi uma máquina muito boa para lidar aqui com um momento onde eu vou ter muito acesso. Então, eu fiz uma escala horizontal, não, vertical, perdão. Fiz uma escala vertical, aumentei máquina, equipamento, etc. Coloquei, como eu costumo dizer, coloquei lenha para o negócio aguentar. Coloquei, como eu costumo dizer, coloquei lenha para o negócio aguentar. Quando você vai lá e faz esse tipo de estratégia, passou esse problema, você pode diminuir ou até colocar isso de forma automática, para ele aumentar e diminuir essa escala de máquina. Então, essa é uma necessidade, é uma possibilidade também que pode nos ajudar. E aí você não vai gastar tanto, você consegue olhar para o seu gasto. Isso é outra coisa muito importante. Quando a gente está falando de serviços da AWS, a gente precisa fazer a gestão financeira desses serviços. Se você começar a fazer como você estava acostumado com o seu servidor próprio, ou seja, gastar tudo que tem, deixar tudo no máximo, não olhar para a infra de forma estratégica e financeira, possivelmente você vai gastar um dinheiro que não precisa e você não vai colher os benefícios de usar aplicações na AWS, beleza? Uma outra coisa também que é importante da gente pensar é a competitividade, o crescimento que a gente tem. Como você consegue fazer isso de forma rápida e exponencial, você consegue expandir seu negócio muito mais rápido, porque a infra não vai ser uma barreira para você. Você consegue testar, colocar as coisas e ir migrando conforme você entender que faz sentido ou diminuindo conforme o custo, por exemplo, do seu produto tenha ficado muito alto. Então imagina que você está colocando aqui muito equipamento, muita máquina, sua empresa ainda é pequena, é uma startup, tem que olhar para o custo nos mínimos detalhes, se você estiver errando muito você perde o mercado, porque tem alguém maior do que você que tem um ganho em cada produto menor. Se você tem essa experiência e consegue lidar com a carga e ficar oscilando quando você precisa ou não de mais recursos, você consegue diminuir o custo do seu produto conforme necessário e consegue atingir mais mercado. Então é importante você olhar para isso também. Quais são os desafios que eles trazem para gente no dia a dia normalmente quando está falando do de sistemas aqui que a gente vai trabalhar com escalabilidade horizontal principalmente tá gente quando eu vou falar de cabelos habilidade vertical nem tanto mais horizontal eu vou ter alguns problemas para resolver. Primeiro, os sistemas acabam ficando um pouco mais complexos em relação à sua segregação e quebra. Então, como eu vou ter um sistema normalmente mais microserviçado, com mais domínios bem definidos e arrumadinho, que a gente fala, no fim disso, traz uma complexidade de direcionamento de carga, de trabalhar com toda essa gestão de aplicação, de você começar a olhar para, por exemplo, como você vai fazer o seu balanceamento de rede, como é que você vai fazer, por exemplo, a sua gestão de observabilidade, onde você vai colocar os logs, porque se você matar a máquina e se deixar seus logs lá, você perde o log, você perde o tracing disso para caso dê um problema em produção, alguma coisa de errado e assim por diante. Então, você traz uma complexidade para gerenciamento desses sistemas quando eles são escaláveis, porque você pode subir uma máquina, matar uma máquina, diminuir velocidade, aumentar velocidade, tudo isso vai trazer uma complexidade grande, mas em compensação o sistema vai ser bem mais robusto. E na minha opinião, você tira a complexidade de outros lugares, tá? Quando você olha para o dia a dia, se você tiver sistemas bem organizados assim, o dia a dia do seu time depois fica muito mais rápido. Ou seja, você gasta mais para montar um bom sistema robusto e preparado, mas esse é um ativo seu. Depois, ao longo dos meses, dos anos, você vai vendo que isso fica muito tranquilo para o seu time lidar ali no dia a dia, diferente do que a gente fazia antigamente, que a gente acabava gastando um pouco menos na entrada, e depois ao longo do tempo a gente tinha que jogar aquele sistema no lixo porque ele já não estava aguentando mais, a gente não conseguia mais lidar com o que a gente precisava para o dia a dia. Então aqui a gente consegue até trabalhar de forma mais desacoplada o que a gente tem por exemplo de problemas sistêmicos das coisas que vão ficando obsoletas ou vão ficando com uma tecnologia que já não faz mais sentido, tá bom? Uma outra coisa importante também é a consistência de dados. Eu comentei aqui um pouquinho sobre log. Log é dado, então você fazer a gestão desses logs é mais difícil do que se você tivesse direto ali no seu equipamento, que ele ficava parado te esperando, você não precisa fazer a gestão disso e nem aguarda esse log da melhor forma. Pensar nos dados também, a mesma coisa, não é só para log, é para fila de mensageria, é para banco de dados, etc. Garantir a consistência, a coerência desse dado é um pouco complexo, mas também eu acho que é o caminho que a gente vai, que faz sentido e que ajuda a gente no dia a dia também, porque faz o sistema serem muito mais robustos e serem muito mais resilientes a falha, coisa que antes não eram, tá? Aqui, quando a gente está falando de escalabilidade, coisas que tem que acontecer, gente. Você tem que ter uma adoção a microserviços, se você tem um monolito, é muito mais difícil de você pensar em escalabilidade, porque você vai ter várias peças ali acopladas, por exemplo. Poxa, tem um monolito que ele bate em cinco bancos de dados diferentes. Um deles é um banco de dados SQL, outro é NoSQL. Cada um é de um jeito. Pra você escalar isso, um você vai ter que escalar de forma... Nem vai dar, vamos ser bem honestos, você não vai conseguir. Você vai topar porque não vai dar para fazer isso. Você tem um NoSQL e um SQL ali grudado junto, vai ser muito complicado você fazer uma escalada desse serviço. Outra coisa também é que você vai gastar muito dinheiro. Você vai botar um monte de coisa escalada, multiplicar o poder de processamento de um monolito, vai fazer isso ficar extremamente caro. Então tem que olhar para o microserviço, tem que saber dividir ele, quebrar as aplicações monolíticas, porque daí sim você vai conseguir fazer a escala independente e no momento que você precisa, sem ficar gastando à toa e sem gerar qualquer tipo de distúrbio de processamento, beleza? Uma outra coisa também é o uso de balanceadores de carga, que eu falei agora há pouco. Distribuir automaticamente essa carga de trabalho, ela é extremamente importante, e saber mapear isso para quando estiver dando algum tipo de falha, também é extremamente importante, criar alertas na distribuição de carga e assim por diante, para ver se você está fazendo isso de forma adequada. É muito importante para você tanto maximizar os recursos, começar a ter uma otimização da grana que você está colocando aqui, quanto para aumentar a sua disponibilidade da aplicação. Se você fizer um balançamento de carga errado, você vai ter, por exemplo, cargas batendo lá máximo de memória e outras máquinas ali que você está pagando e não estão gastando nada de memória, você está desbalanceado. Ou vice-versa, você tem alguma carga que está sendo jogada por uma aplicação que não tem comportamento não tem capacidade de processamento e não porque não tem máquina suficiente sim porque você não soube balancear isso essa é a pior coisa que pode acontecer, mas já vi acontecendo tá bom? outra coisa também é colocar automação é muito importante para você ter provisionamento das coisas de forma dinâmica. O auto scale, down scale, preparado para você não ter que ficar indo lá e organizando isso cada vez. Lógico que quando a gente está falando de down scale, up scale, é legal a gente pensar também em colocar tetos, limites, às vezes a gente trabalha desse jeito, para você também não sair igual maluco, escalando tudo de qualquer jeito. Então, você vai ter que ter ali testes de performance também, para você não sair colocando o máximo possível de auto-scale, acabar dando até outro problema, algum tipo de erro que você pode ter no seu sistema. Então, é legal você fazer os testes de performance ainda, não conta só com auto scale para fazer as coisas funcionarem, mas se você tiver automação ali vai te ajudar bastante a fazer isso de forma mais eficiente e com menos intervenção manual, tá bom? usar estratégias de cachear as nossas informações. Então, quanto mais cache a gente tiver, melhor quando for possível. Também não vamos tomar cuidado para não deixar nenhum dado exposto e nem para deixar nenhum dado ali que vai ser incoerente com o que a gente precisa para o dia a dia. Mas usar estratégias de cache é bem importante para a gente conseguir fazer com que isso também saia mais barato. Porque lembra que você paga por saída e por requisição do seu banco de dados. Então ficar indo e voltando também vai deixar isso às vezes mais caro e fora a velocidade. Porque aí você acaba ganhando muito quando você usa cash. Mas de novo, cuidado com o cash. Várias coisas tem que tomar cuidado com o cash. A gente vai entrar aqui em assuntos sobre cache também ao longo do curso, mas só para começar, não esqueçam de quando a gente está trabalhando com cache, você prestar atenção no dado que você está pondo ali, se. Se você colocar um cache e não tiver nenhuma estratégia de resiliência, você pode estar colocando uma estratégia para ser mais rápido, mas que também pode disponibilizar o seu sistema. Eu costumo dizer que cache não pode parar sistema. Cache é para deixar melhor o sistema. Caso o cache esteja fora, você tem que ter algum tipo de resiliência preparada para você fazer um graceful degradation do seu sistema, beleza? Então, é importante a gente pensar nisso também. E quando a gente está voltando a falar aqui do RDS, agora que a gente falou tudo isso, fiz essa pausa para colocar todo mundo na mesma linha, eu sei que alguns de vocês já estão baita acostumados com o assunto, falam pô, Nathan, você ficou me ensinando a historinha do ônibus, já ouvi essa historinha do ônibus 10 vezes? Tá bom, acho que você pôs aí no 2X ou até pulou. Ótimo, mas tem pessoas que não estão tão por dentro. Uma pessoa ou outra, às vezes, está fazendo e ainda não entendeu por que isso acontece. Então, achei legal a gente estar todo mundo na mesma linha para a gente daqui partir aprofundando mais no detalhe das coisas. Quando a gente está falando agora do RDS, voltando para o nosso assunto inicial, que é onde a gente estava, que é uma das aplicações que a gente está olhando ali da AWS, então quando a gente está falando do RDS, ele basicamente é preparado para a escala vertical, porque ele trabalha com bancos de dados SQL, então pelo menos até agora a gente falou sobre bancos de dados sequenciais. E dentro dessa gama de bancos de dados do RDS, a gente trabalha com a capacidade de você aumentar o processamento de CPU, memória e assim por diante. Na instância que ele já está rodando. E qual que é a ideia legal do RDS? Você consegue fazer isso enquanto ele está ali executando, no voo. Então imagina que você está lá com o seu RDS topando o CPU, você aumenta o processamento. E daí a sua chance de ter qualquer tipo de indisponibilidade durante esse tempo é muito baixa, é muito imperceptível e você não vai nem notar, vai conseguir fazer seu sistema continuar rodando e as coisas irem embora então com isso você tem bastante opção de escalamento vertical agora imagina que você está lá rodando a sua aplicação, fazendo as coisas acontecer e do nada vem um monte de gente entrando sei lá, começou a vender show da Taylor Swift vai entobando de doido lá pra comprar isso todo mundo entrou pra comprar você não vai abrir um chamado pra pedir pra subir máquina comprar coisa e daí sim você colocar ali na sua no seu on-premises um monte de máquina pra isso você teria que ter feito isso antes então você já tem que estar preparado. Então, o caso que a gente pode trabalhar muito aqui quando a gente está falando de AWS, esse seu preparo é menor. Não significa que você vai fazer isso no dia do show, na hora do show, mas você consegue fazer, sei lá, 15 dias antes. Quando antes, você tinha que fazer isso 4 meses antes. E olha lá, dependendo do tamanho da sua mudança, podia ser até maior e depois você ficava com esse BO pra cuidar nos outros dias que você ia estar vendendo, sei lá shows menos badalados do que o da Taylor, por exemplo então aqui é importante você pensar nisso de como é interessante e como esse tipo de estrutura da AWS te deixa fazer essa escala de forma muito mais gerenciável e muito mais leve. E daí possibilitou a gente a ter todos esses produtos que a gente tem hoje em dia e essa habilidade da gente criar cada vez mais coisas mais rápido e com mais qualidade. Beleza, galera? Valeu! Agora a gente vai pro hands-on. Até a próxima. Fica com meu amigo Aminadab e a gente volta em breve. Falou!