[pt] Enable link checking and normalize links

.htmltest.yml

@@ -3,6 +3,6 @@ DirectoryPath: public
 # IgnoreDirectoryMissingTrailingSlash: true # FIXME
 IgnoreInternalEmptyHash: true # FIXME
 IgnoreDirs:
-  - ^(bn|de|es|hi|it|ko|pt.*?|ru|tr|ur|zh.*?)/
+  - ^(bn|de|es|hi|it|ko|ru|tr|ur|zh.*?)/
 IgnoreURLs: # list of regexs of paths or URLs to be ignored
   - ^/pagefind

content/pt-br/application-programming-interface.md

@@ -13,4 +13,4 @@ Uma API (interface de programação de aplicações - do inglês: applications p
 
 ## Como isso ajuda
 
-APIs permitem que programas de computador ou aplicações interajam e compartilhem informações de uma maneira definida e compreensível. Elas são os blocos de construção para as aplicações modernas e fornecem aos desenvolvedores uma maneira de integrar aplicações. Sempre que você ouvir sobre [microsserviços](/microservices/) você pode inferir que eles interagem uns com os outros por meio de uma API.
+APIs permitem que programas de computador ou aplicações interajam e compartilhem informações de uma maneira definida e compreensível. Elas são os blocos de construção para as aplicações modernas e fornecem aos desenvolvedores uma maneira de integrar aplicações. Sempre que você ouvir sobre [microsserviços](/pt-br/microservices-architecture/) você pode inferir que eles interagem uns com os outros por meio de uma API.

content/pt-br/chaos-engineering.md

@@ -9,7 +9,7 @@ A Engenharia do Caos, ou CE, é a disciplina de experimentar em um [sistema dist
 
 ## Problema relacionado
 
-As práticas de [SRE](/pt-br/site-reliability-engineering/) e [DevOps](/pt-br/devops/)focam em técnicas para aumentar a resiliência e [confiabilidade](/pt-br/reliability/) do produto. A capacidade de um sistema de tolerar falhas enquanto garante qualidade de serviço adequada é tipicamente um requisito de desenvolvimento de software. Existem vários aspectos envolvidos que podem levar a falhas de um aplicativo, como infraestrutura, plataforma ou outras partes móveis de um aplicativo baseado em [microserviços](/pt-br/microservices/). A implantação frequente de novos recursos no ambiente de produção pode aumentar a probabilidade de tempo de inatividade e um incidente crítico — com consequências consideráveis para o negócio.
+As práticas de [SRE](/pt-br/site-reliability-engineering/) e [DevOps](/pt-br/devops/)focam em técnicas para aumentar a resiliência e [confiabilidade](/pt-br/reliability/) do produto. A capacidade de um sistema de tolerar falhas enquanto garante qualidade de serviço adequada é tipicamente um requisito de desenvolvimento de software. Existem vários aspectos envolvidos que podem levar a falhas de um aplicativo, como infraestrutura, plataforma ou outras partes móveis de um aplicativo baseado em [microserviços](/pt-br/microservices-architecture/). A implantação frequente de novos recursos no ambiente de produção pode aumentar a probabilidade de tempo de inatividade e um incidente crítico — com consequências consideráveis para o negócio.
 
 ## Como ajuda
 

content/pt-br/cloud-native-apps.md

@@ -1,5 +1,5 @@
 ---
-title: Aplicações Nativas em Nuvem 
+title: Aplicações Nativas em Nuvem
 status: Completed
 category: conceito
 tags: ["aplicação", "fundamento", ""]
@@ -9,7 +9,7 @@ As aplicações nativas em nuvem são projetadas especificamente para aproveitar
 
 ## Problema relacionado
 
-Tradicionalmente, os ambientes locais forneciam recursos de computação de maneira bastante personalizada. Cada datacenter tinha seus serviços [fortemente acoplados](/tightly-coupled-architectures/) aos aplicativos e a ambientes específicos, muitas vezes contando com o provisionamento manual para infraestrutura, como serviços e [máquinas virtuais](/pt-br/virtual-machine/). Isso, por sua vez, restringiu os desenvolvedores e seus aplicativos a esse datacenter específico. Aplicativos que não foram projetados para a nuvem não poderiam aproveitar os recursos de resiliência e dimensionamento de um ambiente em nuvem. Por exemplo, os aplicativos que exigem intervenção manual para iniciar corretamente não podem escalar automaticamente, nem podem ser reiniciados automaticamente em caso de falha.
+Tradicionalmente, os ambientes locais forneciam recursos de computação de maneira bastante personalizada. Cada datacenter tinha seus serviços [fortemente acoplados](/pt-br/tightly-coupled-architecture/) aos aplicativos e a ambientes específicos, muitas vezes contando com o provisionamento manual para infraestrutura, como serviços e [máquinas virtuais](/pt-br/virtual-machine/). Isso, por sua vez, restringiu os desenvolvedores e seus aplicativos a esse datacenter específico. Aplicativos que não foram projetados para a nuvem não poderiam aproveitar os recursos de resiliência e dimensionamento de um ambiente em nuvem. Por exemplo, os aplicativos que exigem intervenção manual para iniciar corretamente não podem escalar automaticamente, nem podem ser reiniciados automaticamente em caso de falha.
 
 ## Como isso ajuda
 

content/pt-br/devops.md

@@ -10,7 +10,7 @@ Esta metodologia vai além da implementação de um conjunto de tecnologias, req
 
 ## Problema relacionado
 
-Tradicionalmente, em organizações complexas com [aplicações monolíticas](/monolithic-apps/) de [alto acoplamento](/tightly-coupled-architectures/), o trabalho era geralmente fragmentado entre vários grupos, levando a um alto número de transferências de responsabilidade e longo prazo nas entregas. Cada vez que um componente ou atualização estava pronto, era disponibilizado em uma fila para o próximo time. Como cada pessoa trabalhava em apenas uma pequena parte do projeto, esta abordagem levava a uma falha de responsabilidade no processo como um todo. O objetivo dos times era transferir o trabalho para o próximo time, e não entregar a funcionalidade correta ao cliente - uma clara falta de alinhamento nas prioridades.
+Tradicionalmente, em organizações complexas com [aplicações monolíticas](/monolithic-apps/) de [alto acoplamento](/tightly-coupled-architecture/), o trabalho era geralmente fragmentado entre vários grupos, levando a um alto número de transferências de responsabilidade e longo prazo nas entregas. Cada vez que um componente ou atualização estava pronto, era disponibilizado em uma fila para o próximo time. Como cada pessoa trabalhava em apenas uma pequena parte do projeto, esta abordagem levava a uma falha de responsabilidade no processo como um todo. O objetivo dos times era transferir o trabalho para o próximo time, e não entregar a funcionalidade correta ao cliente - uma clara falta de alinhamento nas prioridades.
 
 No momento em que o código finalmente entrava em produção, depois de passar por diversos desenvolvedores e esperando em várias filas, tornava-se difícil rastrear a origem do problema se o código não funcionava. DevOps vira essa abordagem de cabeça para baixo.
 

content/pt-br/distributed-apps.md

@@ -5,20 +5,20 @@ category: conceito
 tags: ["arquitetura", "", ""]
 ---
 
-Uma aplicação distribuída é uma aplicação em que a funcionalidade é dividida em várias partes menores independentes. 
-As aplicações distribuídas geralmente são compostas de [microsserviços](/microservices/) individuais 
-que lidam com diferentes preocupações dentro da aplicação mais ampla. 
+Uma aplicação distribuída é uma aplicação em que a funcionalidade é dividida em várias partes menores independentes.
+As aplicações distribuídas geralmente são compostas de [microsserviços](/pt-br/microservices-architecture/) individuais
+que lidam com diferentes preocupações dentro da aplicação mais ampla.
 Em um ambiente nativo da nuvem, os componentes individuais normalmente são executados como [contêineres](/pt-br/container/) em um [cluster](/pt-br/cluster/).
 
-## Problema relacionado 
+## Problema relacionado
 
-A execução de uma aplicação em um único computador representa um único ponto de falha — se esse computador falhar, a aplicação ficará indisponível. 
-As aplicações distribuídas são frequentemente contrárias as aplicações [monolíticas](/monolithic-apps/). 
-Uma aplicação monolítica pode ser mais difícil de escalar, pois os vários componentes não podem ser redimensionados de forma independente. 
+A execução de uma aplicação em um único computador representa um único ponto de falha — se esse computador falhar, a aplicação ficará indisponível.
+As aplicações distribuídas são frequentemente contrárias as aplicações [monolíticas](/monolithic-apps/).
+Uma aplicação monolítica pode ser mais difícil de escalar, pois os vários componentes não podem ser redimensionados de forma independente.
 Eles também podem reduzir a velocidade do desenvolvimento à medida que crescem, porque mais desenvolvedores precisam trabalhar em uma base de código compartilhada, que não tem necessariamente limites bem definidos.
 
 ## Como isso ajuda
 
-Ao dividir uma aplicação em diferentes partes e executá-las em muitos lugares, o sistema geral pode tolerar mais falhas. 
-Isso também permite que uma aplicação aproveite os recursos de dimensionamento não disponíveis para uma única instância, ou seja, a capacidade de [escalar horizontalmente](/horizontal-scaling/). 
+Ao dividir uma aplicação em diferentes partes e executá-las em muitos lugares, o sistema geral pode tolerar mais falhas.
+Isso também permite que uma aplicação aproveite os recursos de dimensionamento não disponíveis para uma única instância, ou seja, a capacidade de [escalar horizontalmente](/horizontal-scaling/).
 Isso, no entanto, tem um custo: maior complexidade e sobrecarga operacional — agora você está executando muitos componentes em vez de uma aplicação.

content/pt-br/distributed-systems.md

@@ -7,11 +7,11 @@ tags: ["arquitetura", "", ""]
 
 Um sistema distribuído é uma coleção de elementos de computação autônomos conectados por uma rede que aparece para os usuários como um único sistema coerente. Geralmente referidos como [nós](/pt-br/nodes/), esses componentes podem ser dispositivos de hardware (por exemplo, computadores, telefones móveis) ou processos de software. Os nós são programados para alcançar um objetivo comum e, para colaborar, eles trocam mensagens pela rede.
 
-## Problema relacionado     
+## Problema relacionado
 
 Hoje, inúmeras aplicações modernas são tão grandes que precisariam de supercomputadores para operar. Pense no Gmail ou Netflix. Nenhum computador único é suficientemente poderoso para hospedar toda a aplicação. Ao conectar vários computadores, o poder computacional se torna praticamente ilimitado. Sem a computação distribuída, muitas das aplicações das quais dependemos hoje não seriam possíveis.
 
-Tradicionalmente, os sistemas seriam [escalados](/pt-br/scalability) verticalmente. Isso significa adicionar mais CPU ou memória a uma máquina individual. A [escalabilidade vertical](/pt-br/vertical-scaling/) é demorada, requer tempo de inatividade e atinge seu limite rapidamente.
+Tradicionalmente, os sistemas seriam [escalados](/pt-br/scalability/) verticalmente. Isso significa adicionar mais CPU ou memória a uma máquina individual. A [escalabilidade vertical](/pt-br/vertical-scaling/) é demorada, requer tempo de inatividade e atinge seu limite rapidamente.
 
 ## Como ajuda
 

content/pt-br/edge-computing.md

@@ -4,7 +4,7 @@ status: Completed
 category: Tecnologia
 ---
 
-A computação de borda é um modelo de [sistema distribuído](/pt-br/distributed-systems) que transfere parte da capacidade de armazenamento e processamento do [*data center*](/pt-br/data-center) principal para as fontes de dados.
+A computação de borda é um modelo de [sistema distribuído](/pt-br/distributed-systems/) que transfere parte da capacidade de armazenamento e processamento do [*data center*](/pt-br/data-center/) principal para as fontes de dados.
 Os dados coletados são processados localmente (por exemplo, em uma fábrica, em uma loja ou em toda uma cidade) em vez de serem enviados para um *data center* centralizado para processamento e análise.
 Essas unidades ou dispositivos de processamento locais representam a borda do sistema, enquanto o *data center* é o seu centro.
 A saída processada na borda é então enviada de volta para o *data center* principal para processamento adicional.

content/pt-br/function-as-a-service.md

@@ -5,7 +5,7 @@ category: Tecnologia
 tags: ["infraestrutura", "", ""]
 ---
 
-Função como um Serviço, (FaaS - Function as a Service ), é um tipo de [serviço](/pt-br/service/) de [computação em nuvem](/pt-br/cloud-computing/) [sem servidor](/pt-br/serverless/) que permite a execução de código em resposta a eventos sem manter a complexa infraestrutura normalmente associado à criação e lançamento de aplicações de [microsserviços](/microservices/).
+Função como um Serviço, (FaaS - Function as a Service ), é um tipo de [serviço](/pt-br/service/) de [computação em nuvem](/pt-br/cloud-computing/) [sem servidor](/pt-br/serverless/) que permite a execução de código em resposta a eventos sem manter a complexa infraestrutura normalmente associado à criação e lançamento de aplicações de [microsserviços](/pt-br/microservices-architecture/).
 
 Com FaaS, os usuários gerenciam apenas funções e dados enquanto o provedor de nuvem gerencia a aplicação.
 Isso permite que os desenvolvedores obtenham as funções necessárias sem pagar pelos serviços quando o código não está em execução.

content/pt-br/microservices.md → content/pt-br/microservices-architecture.md

@@ -5,26 +5,26 @@ category: conceito
 tags: ["arquitetura", "", ""]
 ---
 
-Os microsserviços têm uma abordagem moderna para o desenvolvimento de aplicações que aproveita as tecnologias nativas da nuvem. 
-Embora as aplicações modernas, como a Netflix, pareçam ser uma única aplicação, elas são na verdade uma coleção de serviços menores - todos trabalhando em colaboração. 
-Por exemplo, uma única página que permite acessar, pesquisar e visualizar vídeos provavelmente é alimentada por serviços menores que lidam com um aspecto (por exemplo, pesquisa, autenticação e execução de visualizações no seu navegador). 
+Os microsserviços têm uma abordagem moderna para o desenvolvimento de aplicações que aproveita as tecnologias nativas da nuvem.
+Embora as aplicações modernas, como a Netflix, pareçam ser uma única aplicação, elas são na verdade uma coleção de serviços menores - todos trabalhando em colaboração.
+Por exemplo, uma única página que permite acessar, pesquisar e visualizar vídeos provavelmente é alimentada por serviços menores que lidam com um aspecto (por exemplo, pesquisa, autenticação e execução de visualizações no seu navegador).
 Em resumo, os microsserviços referem-se a um padrão de arquitetura de aplicações geralmente contrária as [aplicações monolíticas](/monolithic-apps/).
 
 ## Problema relacionado
 
-Os microsserviços são uma resposta aos desafios colocados por aplicações monolíticas. 
-Geralmente, diferentes partes de uma aplicação precisarão ser dimensionadas separadamente. 
-Por exemplo, uma loja online terá mais visualizações de produtos do que a finalização da compra. 
-Isso significa que você precisará de mais cópias da funcionalidade de visualização do produto em execução do que a conclusão da compra. 
-Em uma aplicação monolítica, essa lógica não pode ser implantada individualmente. 
-Se você não conseguir dimensionar a funcionalidade do produto individualmente, terá que duplicar toda a aplicação com todos os outros componentes que não precisa - um uso ineficiente de recursos. 
-As aplicações monolíticas também tornam mais fácil para os desenvolvedores sucumbirem às armadilhas do projeto. 
-Como todo o código está em um só lugar, é mais fácil tornar esse [código bem acoplado](/pt-br/tightly-coupled-architectures/) e mais difícil de impor o princípio da separação de responsabilidades. 
+Os microsserviços são uma resposta aos desafios colocados por aplicações monolíticas.
+Geralmente, diferentes partes de uma aplicação precisarão ser dimensionadas separadamente.
+Por exemplo, uma loja online terá mais visualizações de produtos do que a finalização da compra.
+Isso significa que você precisará de mais cópias da funcionalidade de visualização do produto em execução do que a conclusão da compra.
+Em uma aplicação monolítica, essa lógica não pode ser implantada individualmente.
+Se você não conseguir dimensionar a funcionalidade do produto individualmente, terá que duplicar toda a aplicação com todos os outros componentes que não precisa - um uso ineficiente de recursos.
+As aplicações monolíticas também tornam mais fácil para os desenvolvedores sucumbirem às armadilhas do projeto.
+Como todo o código está em um só lugar, é mais fácil tornar esse [código bem acoplado](/pt-br/tightly-coupled-architecture/) e mais difícil de impor o princípio da separação de responsabilidades.
 Os monólitos geralmente exigem que os desenvolvedores entendam toda a base de código antes que possam ser produtivos.
 
 ## Como isso ajuda
 
-Separar a funcionalidade em diferentes microsserviços facilita a implantação, atualização e escala de forma independente. 
-Ao permitir que diferentes equipes se concentrem em sua própria e pequena parte de uma aplicação maior, você também torna mais fácil para elas trabalharem em suas aplicações sem afetar negativamente o resto da organização. 
-Embora os microsserviços resolvam muitos problemas, eles também criam sobrecarga operacional — as coisas que você precisa para implantar e acompanhar têm um aumento na ordem de grandeza ou mais. 
+Separar a funcionalidade em diferentes microsserviços facilita a implantação, atualização e escala de forma independente.
+Ao permitir que diferentes equipes se concentrem em sua própria e pequena parte de uma aplicação maior, você também torna mais fácil para elas trabalharem em suas aplicações sem afetar negativamente o resto da organização.
+Embora os microsserviços resolvam muitos problemas, eles também criam sobrecarga operacional — as coisas que você precisa para implantar e acompanhar têm um aumento na ordem de grandeza ou mais.
 Muitas [tecnologias nativas da nuvem](/pt-br/cloud-native-tech/) visam tornar os microsserviços mais fáceis de implantar e gerenciar.