MindMap Gallery Best Practices and Strategic Implementation
Dive into the dynamic world of cloud-native architecture with our in-depth guide, designed to provide you with a robust understanding of building and managing modern cloud environments. Explore key components like container orchestration with Kubernetes, serverless computing with Azure Functions, and a range of database solutions from Oracle to PostgreSQL. Gain insights into the best practices for application deployment, network routing, load balancing, and firewall configuration to maintain a secure and resilient infrastructure. This resource is perfect for IT professionals, system architects, and developers seeking to leverage cloud-native technologies for enterprise-grade solutions.
Edited at 2023-11-29 18:26:35Dive into the dynamic world of cloud-native architecture with our in-depth guide, designed to provide you with a robust understanding of building and managing modern cloud environments. Explore key components like container orchestration with Kubernetes, serverless computing with Azure Functions, and a range of database solutions from Oracle to PostgreSQL. Gain insights into the best practices for application deployment, network routing, load balancing, and firewall configuration to maintain a secure and resilient infrastructure. This resource is perfect for IT professionals, system architects, and developers seeking to leverage cloud-native technologies for enterprise-grade solutions.
Este mapa mental, criado com o EdrawMind, apresenta um toolkit para avaliação do portfólio de aplicações, abrangendo etapas como assembléia de equipe, definição de domínios de software e grupos de charting. Ele inclui recursos como workshops para modelagem de capacidade empresarial e leituras recomendadas de artigos do Gartner, oferecendo insights estratégicos para alinhamento técnico-empresarial. O modelo auxilia na tomada de decisões, garantindo que o portfólio atenda aos objetivos organizacionais e às demandas dos stakeholders.
This mind map focuses on cloud-native training, container native technologies, and architecture. It offers a detailed elaboration on these highly technical subjects at various levels, aiming to help professionals deeply understand the latest trends and technologies in cloud computing and microservices architecture. Consequently, practitioners can keep pace with the rapidly evolving technological landscape and effectively design and implement advanced IT solutions.
Dive into the dynamic world of cloud-native architecture with our in-depth guide, designed to provide you with a robust understanding of building and managing modern cloud environments. Explore key components like container orchestration with Kubernetes, serverless computing with Azure Functions, and a range of database solutions from Oracle to PostgreSQL. Gain insights into the best practices for application deployment, network routing, load balancing, and firewall configuration to maintain a secure and resilient infrastructure. This resource is perfect for IT professionals, system architects, and developers seeking to leverage cloud-native technologies for enterprise-grade solutions.
Este mapa mental, criado com o EdrawMind, apresenta um toolkit para avaliação do portfólio de aplicações, abrangendo etapas como assembléia de equipe, definição de domínios de software e grupos de charting. Ele inclui recursos como workshops para modelagem de capacidade empresarial e leituras recomendadas de artigos do Gartner, oferecendo insights estratégicos para alinhamento técnico-empresarial. O modelo auxilia na tomada de decisões, garantindo que o portfólio atenda aos objetivos organizacionais e às demandas dos stakeholders.
This mind map focuses on cloud-native training, container native technologies, and architecture. It offers a detailed elaboration on these highly technical subjects at various levels, aiming to help professionals deeply understand the latest trends and technologies in cloud computing and microservices architecture. Consequently, practitioners can keep pace with the rapidly evolving technological landscape and effectively design and implement advanced IT solutions.
Cloud Native
Arquitetura
Cloud Native é um termo que se refere a aplicativos projetados para funcionar em ambientes de nuvem. Esses aplicativos dependem de micro serviços, integração e entrega contínuas (CI/CD) e podem ser usados em qualquer plataforma em nuvem.
1. Infraestrutura
A infraestrutura de TI refere-se aos componentes necessários para executar e gerenciar ambientes de TI empresarial. Esses componentes incluem hardware, software e rede, além de um sistema operacional e armazenamento de dados. A infraestrutura de TI pode ser implantada em um sistema de cloud computing ou nas próprias instalações da organização. Os componentes interconectados da rede possibilitam a comunicação, o gerenciamento e as operações de rede entre os sistemas internos e externos. Existem dois tipos principais de infraestrutura de TI: tradicional e em nuvem. A infraestrutura tradicional é gerenciada nas próprias instalações da organização, enquanto a infraestrutura em nuvem é fornecida por provedores de serviços de nuvem, como Alibaba, Amazon, Google, IBM ou Microsoft.
1.1. Containers
Pense por um momento em mercadorias viajando em um contêiner. Quando você vê grandes caixas de metal em navios de carga, percebe que todas têm o mesmo tamanho e formato. Esses contêineres facilitam o empilhamento e a movimentação de mercadorias em todo o mundo, independentemente do que esteja dentro.Os contêineres de software funcionam da mesma maneira, mas no mundo digital. Assim como um contêiner de remessa pode conter brinquedos, roupas ou eletrônicos, um contêiner de software empacota tudo o que um aplicativo precisa para ser executado. Seja no seu computador, em um ambiente de teste ou na produção de um serviço de nuvem como o Microsoft Azure, um contêiner funciona da mesma maneira em diversos contextos.
1.1.1. Kubernetes
O Kubernetes é uma plataforma em rápida evolução que gerencia aplicativos baseados em contêiner e seus componentes de rede e armazenamento associados. O Kubernetes foca nas cargas de trabalho de aplicativos, não nos componentes de infraestrutura subjacentes. O Kubernetes fornece uma abordagem declarativa para implementações, apoiada por um conjunto robusto de APIs para operações de gerenciamento. Você pode criar e executar aplicativos modernos, portáteis e baseados em micros serviços usando o Kubernetes para orquestrar e gerenciar a disponibilidade dos componentes de aplicativo. O Kubernetes suporta aplicativos sem estado e com estado, à medida que as equipes progridem através da adoção de aplicativos baseados em micros serviços. Como uma plataforma aberta, o Kubernetes permite que você construa seus aplicativos com sua linguagem de programação, sistema operacional, bibliotecas ou barramento de mensagens preferido. As ferramentas existentes de integração contínua e entrega contínua (CI/CD) podem ser integradas ao Kubernetes para agendar e implantar versões.
1.1.1.1. AKS (Azure Kubernetes Service)
O AKS (Serviço de Kubernetes do Azure) simplifica a implantação de um cluster do Kubernetes gerenciado no Azure, transferindo a sobrecarga operacional para o Azure. Como um serviço Kubernetes hospedado, o Azure lida com as tarefas críticas, como o monitoramento da integridade e a manutenção. Quando você cria um cluster AKS, um painel de controle é criado e configurado automaticamente. Esse painel de controle é oferecido sem custo como um recurso gerenciado do Azure abstraído do usuário.------------------------------Definição------------------------------On premise- Qual a versão do Kubernetes que usamos?DTH: v.1.24.6PROD: v.1.24.6- No Red Hat, usamos o open shift? Qual versão?Não usamos o open shift, para gerência dos clusters kubernetes, utilizamos o Rancher, versão 2.7.1
1.1.1.1.1. Cluster
Arquitetura de cluster do KubernetesUm cluster Kubernetes é dividido em dois componentes: - Painel de controle: fornece os serviços principais do Kubernetes e a orquestração de cargas de trabalho do aplicativo. - Nós: executam suas cargas de trabalho do aplicativo.Painel de controleQuando você cria um cluster AKS, um painel de controle é criado e configurado automaticamente. Esse painel de controle é oferecido sem custo como um recurso gerenciado do Azure abstraído do usuário. Você paga apenas pelos nós anexados ao cluster do AKS. O painel de controle e os recursos dele residem apenas na região em que você criou o cluster.O painel de controle inclui os seguintes componentes principais do Kubernetes: - kube-apiserver: O servidor de API é como as APIs do Kubernetes subjacentes são expostas. Esse componente fornece a interação para ferramentas de gerenciamento, tais como kubectl ou o painel do Kubernetes. - etcd: Para manter o estado do seu cluster e configuração do Kubernetes, o altamente disponível etcd é um armazenamento de valores chave dentro do Kubernetes. - kube-scheduler: Quando você cria ou dimensiona aplicativos, o Agendador determina quais nós podem executar a carga de trabalho e iniciá-los. - kube-controller-manager: O Gerenciador do controlador supervisiona um número de controladores menores que executam ações como replicar pods e lidar com operações de nó.O AKS oferece um painel de controle de locatário único, com um servidor de API dedicado, um agendador, etc. Você define o número e o tamanho dos nós e a plataforma Azure configura a comunicação segura entre o painel de controle e os nós. A interação com o painel de controle ocorre por meio das APIs do Kubernetes, como kubectl ou o painel do Kubernetes.Embora não seja necessário configurar componentes (como um armazenamento etcd altamente disponível) com esse painel controle gerenciado, não é possível acessá-lo diretamente. Os upgrades do painel de controle do Kubernetes e do nó são orquestrados por meio do CLI do Azure ou do portal do Azure. Para solucionar possíveis problemas, você pode examinar os logs do painel de controle por meio dos logs do Azure Monitor.NósOs nós do AKS são executados em VMs (máquinas virtuais) do Azure. Com os nós do AKS, você pode conectar o armazenamento a nós e pods, atualizar componentes do cluster e usar GPUs. O AKS dá suporte a clusters de Kubernetes que executam vários pools de nós para dar suporte a sistemas operacionais mistos e contêineres do Windows Server.Conforme a demanda por recursos vai mudando, o número de nós de cluster ou pods que executam os serviços aumenta ou diminui automaticamente. ------------------------------Definição
1. Sub Topic
1.1.1.1.2. Nodes (Nós)
On PremiseProd: 6 Node DTH: 6 Node- Quantos pods por Node?DTH: 10 PodsPROD: 10 Pods---------------------------------Para executar seus aplicativos e serviços de suporte, você precisa de um nó Kubernetes . Um cluster AKS tem pelo menos um nó, uma máquina virtual (VM) do Azure que executa os componentes do nó Kubernetes e o tempo de execução do contêiner. - kubelet: O agente Kubernetes que processa as solicitações de orquestração do plano de controle junto com o agendamento e a execução dos contêineres solicitados; - proxy kube: Lida com redes virtuais em cada nó. O proxy roteia o tráfego de rede e gerencia o endereçamento IP para serviços e pods; - tempo de execução do contêiner: Permite que aplicativos em contêineres sejam executados e interajam com recursos adicionais, como rede virtual e armazenamento. Clusters AKS usando Kubernetes versão 1.19+ para pools de nós Linux usam containerd como tempo de execução de contêiner. A partir do Kubernetes versão 1.20 para pools de nós do Windows, containerd pode ser usado na visualização do tempo de execução do contêiner, mas o Docker ainda é o tempo de execução do contêiner padrão. Os clusters AKS que utilizam versões anteriores do Kubernetes para pools de nós, utilizam o Docker como tempo de execução do contentor. O tamanho da VM do Azure para seus nós define CPUs, memória, tamanho e tipo de armazenamento disponível (como SSD de alto desempenho ou HDD normal). Planeje o tamanho do nó de acordo com a necessidade de seus aplicativos exigirem grandes quantidades de CPU e memória ou armazenamento de alto desempenho. Aumente o número de nós no seu cluster AKS para atender à procura. No AKS, a imagem VM para os nós do seu cluster baseia-se no Ubuntu Linux, Azure Linux ou Windows Server 2019. Quando cria um cluster AKS ou aumenta o número de nós, a plataforma Azure cria e configura automaticamente o número solicitado de VMs . Os nós do agente são cobrados como VMs padrão, portanto, quaisquer descontos no tamanho da VM (incluindo reservas do Azure) são aplicados automaticamente. Para discos gerenciados, o tamanho e o desempenho padrão do disco serão atribuídos de acordo com o SKU da VM selecionado e a contagem de vCPUs.
1.1.1.1.3. Nodes pools (pools de nós)
Nós da mesma configuração são agrupados em pools de nós. Um cluster Kubernetes contém pelo menos um pool de nós. O número inicial de nós e o tamanho são definidos quando você cria um cluster AKS, que cria um pool de nós padrão . Este pool de nós padrão no AKS contém as VMs subjacentes que executam os nós do agente.Você dimensiona ou atualiza um cluster AKS no pool de nós padrão. Você pode optar por dimensionar ou atualizar um pool de nós específico. Para operações de atualização, os contêineres em execução são agendados em outros nós do pool de nós até que todos os nós sejam atualizados com êxito.
1.1.1.1.4. PODs
- 26/09 - enviado pelo Cubas: - DTH: RAM: 250m vCPU: 512Mi - PROD: RAM: 250m vCPU: 512Mi-----------------------------------------------Kubernetes usa pod para executar uma instância do seu aplicativo. Um pod representa uma única instância do seu aplicativo.Os pods normalmente têm um mapeamento 1:1 com um contêiner. Em cenários avançados, um pod pode conter vários contêineres. Os pods de vários contêineres são agendados juntos no mesmo nó e permitem que os contêineres compartilhem recursos relacionados.Ao criar um pod, você pode definir solicitações de recursos para solicitar uma determinada quantidade de recursos de CPU ou memória. O Kubernetes Scheduler tenta atender à solicitação agendando os pods para execução em um nó com recursos disponíveis. Você também pode especificar limites máximos de recursos para evitar que um pod consuma muitos recursos de computação do nó subjacente. A prática recomendada é incluir limites de recursos para todos os pods para ajudar o Kubernetes Scheduler a identificar os recursos necessários e permitidos. Um pod é um recurso lógico, mas as cargas de trabalho do aplicativo são executadas nos contêineres. Os pods são normalmente recursos efêmeros e descartáveis. Os pods programados individualmente perdem alguns dos recursos de alta disponibilidade e redundância do Kubernetes. Em vez disso, os pods são implantados e gerenciados por controladores Kubernetes, como o Deployment Controller.
1.1.1.1.5. Disponibildiade
Um cluster do Serviço de Kubernetes do Azure (AKS) distribui recursos como nós e armazenamento em seções lógicas da infraestrutura subjacente do Azure. O uso de zonas de disponibilidade separa fisicamente os nós de outros nós implantados em zonas de disponibilidade diferentes. Os clusters AKS implantados com várias zonas de disponibilidade configuradas em um cluster fornecem um nível mais alto de disponibilidade para proteger contra uma falha de hardware ou um evento de manutenção planejada.Ao definir pools de nós em um cluster para abranger várias zonas, os nós em um determinado pool de nós podem continuar operando mesmo que uma única zona tenha caído. Seus aplicativos podem continuar disponíveis mesmo se houver uma falha física em um único datacenter se orquestrados para tolerar a falha de um subconjunto de nós.
1.1.1.1.5.1. Zonas de disponibilidade
As zonas de disponibilidade são uma oferta de alta disponibilidade que protege seus aplicativos e dados contra falhas no datacenter. As zonas são locais físicos exclusivos em uma região do Azure. Cada zona inclui um ou mais datacenters equipados com energia, resfriamento e rede independentes. Para garantir a resiliência, há sempre mais de uma zona em todas as regiões habilitadas para zona. A separação física das zonas de disponibilidade em uma região protege aplicativos e dados contra falhas no datacenter.Os clusters AKS implantados usando zonas de disponibilidade, podem distribuir nós em várias zonas em uma única região. Se uma única zona ficar indisponível, seus aplicativos continuarão a ser executados em clusters configurados para se espalhar por várias zonas.---------------------------------------------- SLA de uma Zona: 99,99%- SLA de 99,95% para 3x zonas
1.1.1.1.5.2. SLA Composto
SLA composto é a junção de todos os SLA do sistema, que mostra qual a sua SLA para o conjunto- Qual o SLA contido na solução de AKS - isso mostra o tempo de parada permitido por ano. Melhora o nosso suporte. - Caso queiram suporte proximos do 99,999%, melhorar os recursos do SLA composto.-
1.1.1.1.6. Logs
1.1.1.1.6.1. Centralizador de Logs
- 10/2023 - Usamos o Grafana Loki e o Prometeus - - - Log analytics, Azure, substituiria o Loki?
1.1.1.1.7. Backup
O Velero faz backup e restauração de objetos de cluster do Kubernetes e volumes persistentes - infraestrutura. - Ferramenta Open Source.Nuvem- Azure backup
1.1.1.1.8. Monitoramento & Visualização
1.1.1.1.8.1. Redes
- No metro usamo o Zabbix (on premise) -
1.1.1.1.8.2. Infraestrutura
- No metro, eles utilizam o Zabbix (on premise)-
1.1.1.1.8.3. Banco de dados
- No metro, eles utilizam o Zabbix (on premise)
1.1.1.1.8.4. Aplicações
On premiseZabbix ?Nuvem- Application Insights (extensão do Azure monitor, que permite aumentar os reuqisitos de coleta)
1.1.1.1.8.5. Inspeção de comportamento
On premise- Usamos o NeuVector (fornece inspeção, visualização e segurança de rede necessárias para ambientes de contêineres); - Detecção de comportamento anômalo, análise de tráfego em tempo real e detecção de ameaças baseada em aprendizado de máquina.Nuvem- O Azure Monitor, faz tal proposta? - Aplication insights é uma extensão do Monitor e amplia- Azure Devops - detecta comportamento anomalo? faz analise de trafego online? detecta ameça usando IA?
1.1.1.1.9. Segurança
1.1.1.1.9.1. Repositório Seguro de Segredos
Usamos tanto on premise- Azure Key Vault (armazenamento e acesso de chaves de API, senhas, certificados ou chaves criptográficas)-
1.1.1.1.10. DevOps
GMUDTemos implantado DevOps, com microserviço
1.1.1.1.11. Referencia
GMUDTemos implantado DevOps, com microserviço
1.1.1.2. Azure Containers Instances
-
1.1.1.3. Azure Containers Applications
-
1.1.1.4. IaaS (Kubernetes)
.
1.1.2. Azure Functions
Serviço serveless de funções
1.2. Land Zone
09/2023: Em conversa com algumas pessoas da Microsoft, informaram alguns precessos para nos ajudar com os modelos de referencia: Acesso com well architected (dará a nós a ideia do que pode ser melhorado) e land zone (onde podemos padronizar o uso dos recursos).Necessario analise para uso, pois depende de cada assinatura - Paulo Carneiro, verificará com o Fabio Monteiro.
1.2.1. Acesso Well-Architected Framework
- O custo de acesso é para cada Subscrição;- O custo depende de cada pilar que escolhermos (ao todo 5);- Quais são as prioridades neste momento;** Sugestão - Confiabilidade (A capacidade de um sistema de se recuperar de falhas e continuar funcionando)- Excelencia operacional (Processos de operações que mantêm um sistema em execução em produção)
1.2.1.1. Confiabilidade (Reliability)
1.2.1.2. Excelencia Operacional (Operacional Excellence)
1.2.1.3. Eficiência do desempenho (Performance Efficiency)
1.2.1.4. Segurança (Security)
1.2.1.5. Otimização de Custos (Cost Otimization)
1.2.2. Landing Zone
1.2.2.1. AA0029
1.2.2.2. AA0031
2. Dados
2.1. Banco de dados
2.1.1. Oracle
2.1.2. Azure SQL
2.1.2.1. SQL Managed Instance
2.1.2.2. SQL Database
2.1.3. MySQL
2.1.4. PostGreeSQL
2.2. Armazanamento
3. Aplicação
3.1. Front end
3.2. Back end
4. Redes
4.1. Azure ExpressRoute
- Qual a vantagem?- Teremos redundancia?- Teremos um Lock-in. Como contornar?
4.1.1. AWS Direct Connect
4.1.2. GCP Interconnect
4.2. VPN site-to-site
- Qual impacto do uso dos recusrsos Azure com os recursos on premise?-
4.3. Load Balancer
Balanceador de redes e de aplicações.-
4.4. Firewall
- 10/2023: Usamos o Azure Firewall. - É o mais apropriado? - Melhor preço?On premise- Usamos o Fortinet - Tem licemça no Azure - melhor? - Melhor preço?
4.5. RDP/SSH totalmente gerenciado
Serviço de administração que usa um ponto de acesso comum, Bastion, que fornece acesso a serviços especificos - não precisa entrar no portal.A conexão é feita com RDP/SSH e sua autenticação/autorização, depende de um gerenciador RBAC.
4.6. Classes de IPs
1 - Quais Classes de IPs usamos no Azure?2 - Quais classes de Ips usamos no on premise? - Para quais serviços?
5. Gerenciamento de identidade e acesso
5.1. KeyCloak
Usamos o KeyCloak para se comunicar com o SCAA, este realiza a autenticação e autorização dos usuários na maioria dos aplicativos do Metrô.A versão que usamos é Open Source.Na época da discussão, o Entra ID não atenderia a necessidade do Metrô - que seria usar um gerenciador de acesso e identidade, moderno, que se conectasse no SCAA e use a autenticação e autorização. Do lado do aplicativo, esses usam o KeyCloak como ´intermediario´.Não foram informados quais os problemas que o Entra ID apresentou.
5.2. Azure Entra ID (AD)
Utilizado quase todos os serviços do Metrô: Microsoft 365, Azure, computadores, etc.Somente os aplicativos, que usam o KeyCloak como intermediario com o SCAA (que possui as autenticações e autoriazações das aplicações).
6. FinOps
6.1. Cost Management + Billing
6.2. TAG
6.3. Advisor
6.4. Outras ferramentas
7. Segurança
7.1. Repositório Seguro de Segredos
7.1.1. SW Cofre de Senhas
- Usamos atualmente o Azure Key Vault - Para gerenciamento de senhas de aplicativos (secret key) -
7.1.2. HSM (HW Security Module)
- Hardware que inclui gerenciamento de senhas e certificado (fisico). Instalado no datacenter da Microsoft e com acesso direto e exclusivo do cliente.- Precisamos, por medida da lei, de um gerenciador físico? - ?
7.2. Hub-Spoke
7.3. SOC
7.4. NOC