E pessoal, para a gente finalizar esse capítulo, olha só que interessante. A gente falou sobre o AWS Well-Architected, legal? Mas isso a gente está falando de uma nuvem, que é a AWS. Todos os cloud providers têm frameworks ou princípios que são inclusive muito parecidos com o que a AWS tem. Legal? Eu vou dar um exemplo aqui para vocês sobre 10 princípios de design para aplicações na Microsoft Azure. Legal? Inclusive o link está aqui embaixo para você ver. E você vai perceber que esses princípios, eles lembram muito os princípios que a gente está falando na AWS Well-Architected. Legal? Então vamos pensar nesses princípios aqui, galera. Princípio número 1. Design for self-healing. O que significa? Você vai desenhar sua aplicação para que ela possa se autocurar. O seu ambiente possa se autocurar. A gente falou disso. Outro ponto. Dee as coisas redundantes né a gente não falou na ws fique global em minutos deixar as coisas redundantes são muito importantes você consegue criar a líder em followers de banco de dados você consegue trabalhar em diferenças a diferentes a availability zone você consegue manter as suas coisas funcionando, caso uma caia, você tem outras coisas rodando do outro lado, né? Você tem confiabilidade, né? Então, olha só que ponto importante. Outro ponto, minimize a coordenação. Ou seja, quanto menos você ter que ficar colocando a mão ali para operar o negócio, vai ser muito melhor. E você só consegue fazer isso automatizando as coisas. E também usando os serviços corretos e normalmente de forma gerenciada. A gente já vai falar de serviço gerenciado aqui. Outro ponto, desenhe para escalar ou seja cria sua arquitetura de uma forma que ela vai poder escalar para manter toda sua carga de trabalho funcionando e principalmente trazendo resultado ali pra empresa outro ponto particionamento é isso mesmo separe né os seus centros de custo, consiga entender o que você está gastando, o que você está separando por cada tipo de projeto, por exemplo. Outro ponto, design for operations, ou seja, crie formas de que você vai conseguir operar no dia a dia, legal? Baseado em automações, baseado em observabilidade ou seja essas coisas elas têm que ser feitas de forma intencional outro ponto os serviços gerenciados usando serviços gerenciados você tem menos mão na massa você consegue ter menos problemas que você vai ter porque você vai ter nesse caso caso aqui, a Azure por trás dos panos gerenciando. A gente sabe que tem essa pegada de custo, mas, de forma geral, quanto mais serviço gerenciado você tem, menos chance de dar coisa errada vai ter. Use o melhor data storage para o melhor trabalho. Você tem diversos tipos de bancos de dados, você tem diversas formas de armazenar arquivos. No Azure, você tem diversos tipos de bancos de dados, você tem diversas formas de armazenar arquivos, no Azure você tem Blob Storage, você tem outros tipos de bancos de dados, normalmente esses bancos de dados, esses tipos de coisas, normalmente se equivalem a alguns outros serviços da AWS, por exemplo. Design for Evolution, ou seja, desenhe para que você consiga ter uma evolução ao longo do tempo. Legal? Então, a gente foi para 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 itens aqui que você pode utilizar como princípios para você desenhar aqui a sua arquitetura. Use sempre uma checklist dessa galera tá a microsoft a orco a google a ws e outras empresas elas são muito robustas e elas têm muitas boas práticas inclusive né os seus próprios arquitetos de solução, a maioria deles é treinada, baseada na própria documentação que é gerada e que muitas dessas documentações são públicas, são documentações que nós estamos lendo agora. Obviamente, eles têm muito documento interno, mas muitos desses princípios valem para quem é especialista, para quem trabalha na Microsoft, para quem trabalha na AWS, mas também para você que vai trabalhar com esses caras. Beleza? Espero que eu tenha conseguido dar uma visão geral. Pessoal, novamente aqui, é um conteúdo denso? É. Tem fundamento? Tem. É importante? Muito. E um arquiteto de solução tem que saber essa parada. Você não quer ser arquiteto de solução? Não tem problema. Você tendo esse conhecimento, você não vai ser mais tão, entre aspas, inocente. Ah, eu vou colocar o meu cloud infinito, ah, o meu pod não vai cair, ah, minha máquina está rodando tanto tempo, não vou me preocupar, se cair eu não sei o que eu vou fazer. Quando você tem esses pontos na sua cabeça, você vai começar a olhar o mundo de uma forma totalmente diferente. Você deixa de ser inocente. Normalmente, eu gosto de falar assim, você deixa de ser inocente. Eu gosto de falar assim, você deixa de ser inocente. Lê esses documentos que tira de um profissional que tem uma inocência, acreditando que tudo na nuvem há mil maravilhas, para um profissional sabendo que as coisas não são simples. Não tem como resolver coisas altamente complexas com soluções muito simples. Não tem como. E é por conta disso que esses guias vão te ajudar a mudar completamente a sua visão quando a gente está falando em arquitetura de solução. Beleza? É isso aí.