Update README.md

Author: IsaacAlves7

README.md

@@ -7,6 +7,8 @@
 
 Uma **infraestrutura de TI** (Tecnologia da Informação) é o conjunto de recursos físicos, lógicos e organizacionais que sustentam o funcionamento dos sistemas tecnológicos de uma empresa, possibilitando o armazenamento, processamento e comunicação de dados. Em outras palavras, é tudo o que dá suporte às operações digitais, desde o hardware até os serviços e políticas que garantem a disponibilidade e segurança da informação.
 
+Todos os recursos da AWS serão provisionados via CDK, o que significa que em questão de minutos você terá uma infraestrutura confiável, pronta para produção e escalável implantada na sua conta AWS, permitindo que suas equipes escalem de forma independente e entreguem iterações rápidas de negócio.
+
 Sem dúvidas, ela é uma etapa muito importante quando estamos desenvolvendo System Design, sempre temos que alinhar com a infraestrutura do nosso sistema.
 
 Ela é composta basicamente por quatro camadas principais:
@@ -255,6 +257,60 @@ Utilizando CI/CD Pipeline: Realizando testes unitários + fazendo build para ger
 </table>
 
 ## [AWS] Microfrontends Deployment
+Uma visão geral de alto nível de uma arquitetura AWS sem servidor de fato para hospedagem e implantação de micro-frontends mono-repositórios baseados no plugin Module Federation Webpack:
+
+![https___cdn-images-1 medium com_max_3342_1_T_OrAE8h81-7u_2x5DWJIw](https://github.com/user-attachments/assets/46eae732-0dbd-4076-a84d-03ffd81ccdea)
+
+A arquitetura consiste em 3 partes principais:
+
+1. Mudanças no código mono-repositório acionando pipelines específicos de implantação.
+2. Pipelines de implantação criando e implantando artefatos em bundles para direcionar recursos da AWS.
+3. Infraestrutura de hospedagem globalmente escalável, adaptada para micro-frontends do lado do cliente.
+
+<img width="226" height="276" align="right" src="https://github.com/user-attachments/assets/17cf97ef-e835-43aa-8317-ee8e7a80a1c5" />
+
+Um pouco sobre a configuração do Mono-repositório: Micro-frontends fazem parte de uma configuração mono-repositório, ou seja, um único repositório com subpastas incluindo aplicativos web independentes, colados juntos pelo plugin Webpack Module Federation e Lerna. Um vislumbre da estrutura dos repositórios pode ser visto abaixo:
+
+Se você for impaciente, pode ver como as micro-frontends são representadas por sistemas de Federação de Módulos na ideia abaixo, que será discutida em detalhes em um futuro próximo.
+
+Resumindo, o código acima nos permite modelar micro-frontends como sistemas que podem ser carregados preguiçosamente como componentes Web no seu app. O truque é injetar dinamicamente cada script de micro-frontend na página do app para que possam ser carregados remotamente pelo app host/shell. Como dito, mais novidades virão no próximo artigo. Por enquanto, vamos analisar as 3 subarquiteturas mencionadas anteriormente.
+
+Gatilhos mono-repositório: O objetivo dessa primeira etapa é capturar mudanças individuais de micro-frontend repositórios e acioná-las para uso posterior por componentes sem servidor.
+
+![https___cdn-images-1 medium com_max_2000_1_8bLIHFGWteY4F7u_OJsafA](https://github.com/user-attachments/assets/7a874b19-ab41-406a-b9a1-4621e852d188)
+
+Desenvolvedores enviam as mudanças para seu micro-frontend pertencente via Github, embora o mesmo possa ser feito em outras plataformas de versionamento bem conhecidas, como o BitBucket. Por meio de um webhook do Github, as alterações são feitas por uma função Lambda exposta como uma API Restful via um ApiGateway. O principal objetivo do Lambda é associar a mudança de código micro-frontend ao pipeline de destino. Um guia manual dessa abordagem pode ser apreciado aqui, enquanto sua implementação no CDK fará parte do próximo artigo.
+
+Pipeline de implantação
+O objetivo da segunda etapa é garantir que as mudanças individuais no repositório micro-frontend acionem pipelines de código individuais. Isso incentiva a independência da equipe, pois se apenas um micro-frontend for modificado (por exemplo: mfe-app1), queremos acionar apenas seu pipeline relacionado, e não todos os outros.
+
+<img width="656" height="592" alt="https___cdn-images-1 medium com_max_2000_1_vQTICQ0SDtJg4VKNL4PAeg" src="https://github.com/user-attachments/assets/0ed00040-b396-4e51-8048-5468efb898ad" />
+
+Uma vez que uma alteração de código é associada, um AWS Code Pipeline é iniciado. Isso inclui quatro etapas principais:
+
+O próprio Code Pipeline, que gerencia a conexão do GitHub e busca o código-fonte associado do GitHub
+
+O Code Build, que constrói o código-fonte receptor em um artefato de build. Como micro-frontends são baseados em JavaScript, eles vão aproveitar o yarn para construí-los em um conjunto de bundles a serem usados na próxima etapa.
+
+O Código Implantado. Essa etapa pega os arquivos agrupados construídos das etapas anteriores e os implanta em um único Serviço de Armazenamento Simples (S3). Cada micro-frontend será armazenado em uma "pasta" (ou chave) independente, para que possam ser implantados individualmente.
+
+A invalidação do cache da construção do código. A última etapa é mais uma etapa de Construção de Código, que garante que o cache do CloudFront seja invalidado toda vez que publicamos e implantamos novos artefatos no S3.
+
+Infraestrutura de hospedagem
+Por último, mas não menos importante, recursos fundamentais da AWS precisam ser provisionados. O objetivo dessa última etapa é garantir que isso aconteça com uma arquitetura escalável, simples, mas inteligente e confiável.
+
+![https___cdn-images-1 medium com_max_2000_1_zK1QOLn0giIQ_85rkUEUAw](https://github.com/user-attachments/assets/448e9bff-2df2-4926-a99d-388ba118811b)
+
+Com a subarquitetura acima, os usuários finais acessarão a aplicação web por meio de uma distribuição CloudFront protegida por WAF, já que as micro-frontends são aplicações otimizadas para o cliente. O CloudFront se conecta ao bucket privado S3 via uma identidade OAI, garantindo que os dados sejam acessíveis publicamente apenas via CDN e não diretamente do bucket. O CloudFront utiliza uma função Lambda@Edge para despachar corretamente para diferentes origens vindas do único balde.
+
+CDK para governar todos eles
+Tudo acima será provisionado por meio de uma aplicação CDK que inclui três stacks:
+
+A pilha da fundação. Isso prevê os recursos fundamentais da AWS usados para hospedar o app, incluindo o bucket S3, uma função Lambda@Edge, uma distribuição CloudFront e várias políticas, funções e OAI de IAM para apoiar a privacidade e segurança corretas.
+
+A segunda pilha é implícita porque é criada ao provisionar a função Lambda@Edge via a API Experimental CloudFront CDK, já que precisa implantar o Lambda@Edge em uma região AWS específica (us-east-1 é usado por padrão para todas as funções de borda).
+
+A pilha implantação ci/cd. Sua função é provisionar todos os recursos AWS associados ao ApiGateway e ao Code Pipeline.
 
 ## [AWS] Blue-Green Deployment
 <table>