# Requisitos de Arquitetura

## Regras da Validação para arquitetura CCR
.
.
.
1. **Explique a modalidade de licenciamento ou contratação do produto. Quais os tipos e formas de licenciamento.**
Explique os modelos de licenciamento disponíveis (por exemplo,licença, assinatura baseada em uso) e formas de contratação (compra direta, SaaS, PaaS).

2. **Qual o padrão de Arquitetura que a empresa de vocês utilizam ?**
A arquitetura de microservices oferece vários benefícios, incluindo:

- **Escalabilidade**: Os microservices podem ser escalados de forma independente, o que permite que a empresa se adapte às mudanças no volume de tráfego.
- **Resiliência**: Os microservices são projetados para ser resilientes a falhas. Se um microservice falhar, os outros microservices podem continuar funcionando.
- **Facilidade de manutenção**: Os microservices são menores e mais simples que os aplicativos monolíticos, o que os torna mais fáceis de manter.

Na empresa que trabalho, a arquitetura de microservices é usada para todos os novos aplicativos desenvolvidos. Os microservices são implementados usando uma variedade de tecnologias, incluindo Java, Python, Node.js e Go.

Aqui estão alguns exemplos específicos de como a arquitetura de microservices é usada na empresa:

- O aplicativo de front-end é dividido em vários microservices, cada um responsável por uma funcionalidade específica.
- O aplicativo de back-end é dividido em vários microservices, cada um responsável por uma funcionalidade específica.
- Os microservices são interconectados usando APIs REST.
- A arquitetura de microservices é uma abordagem de
arquitetura de software eficaz que pode ser usada para desenvolver aplicativos robustos e escaláveis.

Para responder ao questionário para Arquiteto de Software, você pode mencionar os seguintes pontos:

- Os benefícios da arquitetura de microservices, como escalabilidade, resiliência e facilidade de manutenção.

Como a arquitetura de microservices é usada na empresa, incluindo os tipos de microservices, as tecnologias usadas e a forma como os microservices são interconectados.

Exemplos específicos de como a arquitetura de microservices é usada na empresa.

Ante ser específico e fornecer exemplos concretos. Isso mostrará ao entrevistador que você entende os conceitos envolvidos na arquitetura de microservices e que pode colocá-los em prática.

3. **O produto possui capacidade de utilizar quais Bancos de Dados e versões?**
- Oracle 11g a 12c, 13c, 19c, 21c com suporte a json e bloc chain
- Mysql 5 e 8
- Postgres 14
- Sql server
- Mongodb _ versão 4.5, a 6.0

:::info
(recomendação Utilização do Oracle devido ao suporte ao mesmo, que a empresa já possui)**
:::

4. **Deve ser definido a estrutura de acesso para consumo da nova API externa de validação e autenticação de documentos.**
A API utiliza OAuth 2.0 para autenticação
e autorização, e os endpoints são documentados em Swagger.

5. **Qual ambiente de nuvem é hospedado (AWS, Azure etc.)? Qual zona está localizado a Cloud?**
O produto está hospedado na AWS, predominantemente na região da América do Norte (us-east-1).

6. **Caso o produto esteja na Cloud, a saída (Trânsito dos dados) da CCR até a Cloud será criptografada, como seria o envio dos dados? Explique o fluxo.**
Os dados são criptografados em trânsito usando TLS
1.2. O fluxo de dados segue um padrão de API Gateway,
com verificações de segurança no ponto de entrada.

7. **O ambiente OnCloud será dedicado e exclusivo (Cloud Privada) à CCR ou está em arquitetura multi-tenant?
Se sim, como é realizado o isolamento dos clientes na sua Arquitetura Cloud?**
Utilizamos um ambiente cloud multi-tenant com isolamento rigoroso de dados e recursos entre clientes, garantido por controles de acesso e redes virtuais isolada

8. **O produto é escrito na(s) seguinte(s) linguagem(ns)- Server ?**
- **Java 17** (Spring Boot 3.2.1 ) e Node.js versão 16.20 para serviços específicos.
- **C# .net 7.0**, Visual Studio 2022 com suporte ao .NET Multi-platform App UI (.NET MAUI)
- **Python 3.11** com flask para o Desenvolvimento de Api

9. **O produto é escrito na(s) seguinte(s) linguagem(ns) - Client ?**
Angular 17, Mobile e Web React Native, Mobile Flutter.

10. **Caso o produto ofereça transações padrão (APIs) para integração com outros sistemas, marque as afirmativas verdadeiras ?**
Nossas APIs suportam REST e GraphQL. Elas são compatíveis com padrões OpenAPI e seguem as melhores práticas de segurança.

11. **A solução OnCloud está segregada com uma DMZ ou o acesso será direto ao ambiente interno? (explique detalhadamente se houver) Quais componentes de segurança existem para proteger o acesso. Ex: IDPS, WAF, Firewall, etc.**
A infraestrutura na nuvem é segregada por DMZs, com firewalls, WAF, e sistemas de detecção e prevenção de intrusões (IDPS) para proteger os acessos.

12. **Podemos ter acesso a todos os logs?**
Todos os logs podem ser acessados por meio do nosso portal de administração, com opções de exportação e análise.

13. **Tem Ci e Cd com que Programa dando Suporte ?**
* **Jenkins** - é uma das ferramentas de CI/CD mais antigas e amplamente utilizadas. É um servidor de automação open-source que permite a construção, teste e implantação automatizados de projetos de software. **Principais Características:** Altamente configurável, suporta uma grande variedade de plugins, e pode ser usado em quase qualquer tipo de projeto de software.
* **GitLab CI/CD** - GitLab oferece um serviço de CI/CD integrado em sua plataforma de gerenciamento de código-fonte.

Permite definir pipelines de CI/CD em arquivos YAML, integrado diretamente com repositórios GitLab, e fornece uma solução abrangente para o ciclo de vida do desenvolvimento de software.
* **CircleCI** - é uma ferramenta de CI/CD hospedada na nuvem que é conhecida por sua rapidez e eficiência. **Principais Características:** Oferece uma configuração fácil, execução rápida de builds, e é altamente escalável. Suporta Docker e permite
a execução de pipelines em ambientes Linux, macOS e Windows.
* **Travis CI** - é outra ferramenta popular de CI baseada em nuvem, que se integra bem com GitHub.
Características: Fácil integração com GitHub, suporte para múltiplas linguagens, configuração simples.
* **Azure DevOps** - Oferecido pela Microsoft, o Azure DevOps inclui uma série de ferramentas DevOps, incluindo Azure Pipelines para CI/CD. Integração com outros serviços Azure, suporta uma ampla gama de linguagens e plataformas.
* **AWS CodePipeline:** Parte do conjunto de serviços da Amazon Web Services, o AWS CodePipeline é uma ferramenta de CI/CD que integra bem com outros serviços AWS. Boa integração com AWS, suporte para várias etapas de pipeline, flexível.
* **Bamboo:** Desenvolvido pela Atlassian, Bamboo é uma ferramenta de integração contínua e entrega contínua que se integra bem com outras ferramentas Atlassian, como JIRA e Bitbucket. Integração com ferramentas Atlassian, suporte a construções e testes automáticos.

14. **Os dados trafegados na plataforma OnCloud são criptografados? Pode detalhar o tipo de criptografia utilizada?**
Os dados em trânsito são criptografados usando TLS 1.2, e os dados em repouso são criptografados com AES-256.

15. **Como é feito o processo de gestão de chaves de criptografia?**
A gestão de chaves de criptografia envolve várias etapas e práticas para garantir a segurança e a eficácia das chaves utilizadas para criptografar e descriptografar dados. As etapas principais incluem:

* **Geração de Chaves:** As chaves de criptografia devem ser geradas de forma segura e aleatória. Ferramentas e algoritmos específicos são usados para garantir que as chaves sejam fortes e imprevisíveis.
* **Armazenamento de Chaves:** As chaves devem ser armazenadas de forma segura, geralmente em um módulo de segurança de hardware (HSM) ou em um gerenciador de chaves, como o AWS Key Management Service (KMS) ou Azure Key Vault. Esses serviços protegem as chaves contra acesso não autorizado.
* **Controle de Acesso:** Deve ser implementado um controle de acesso rigoroso para garantir que apenas pessoas ou sistemas autorizados possam acessar as chaves de criptografia.
* **Rotação de Chaves:** Regularmente, as chaves devem ser trocadas (rotacionadas) para reduzir o risco de comprometimento a longo prazo de uma chave.
* **Auditoria e Monitoramento:** A atividade de uso das chaves deve ser monitorada e auditada para detectar e responder a atividades suspeitas.
* **Destruição de Chaves:** Quando uma chave não é mais necessária, ela deve ser destruída de forma segura para garantir que os dados que ela protegia não possam ser descriptografados.

16. **É possível a chave de criptografia também ficar em poder da CCR ?**
Sim, é possível que a CCR (Companhia de Certificação e Registro)
mantenha a posse de chaves de criptografia, desde que ela siga as práticas de segurança e gestão de chaves adequadas. Essa prática é comum em cenários onde a CCR atua como uma autoridade de confiança ou quando é necessário um controle adicional sobre o acesso aos dados.

17. **Como a CCR possui conta na AWS, é possível armazenar a chave em nosso cofre (Se a Cloud utilizada for AWS)?**
Sim, é possível armazenar chaves de criptografia no cofre de chaves da AWS, conhecido como AWS Key Management Service (KMS) ou AWS CloudHSM, se a CCR possui uma conta na AWS. O AWS KMS é uma solução gerenciada que facilita a criação e controle de chaves de criptografia usadas para criptografar dados. O AWS CloudHSM é uma solução que oferece módulos de segurança de hardware para armazenamento e gestão de chaves em um ambiente ainda mais seguro.

18. **Como a CCR possui conta na AWS, é possível armazenar a chave em nosso cofre (Se a Cloud utilizada for AWS, Azure, GCP)?**
* **AWS KMS:** Oferece integração com outros serviços da AWS e é mais fácil de gerenciar.
* **AWS CloudHSM:** Oferece um nível mais alto de segurança, pois utiliza HSMs físicos.

Em ambos os casos, a CCR pode gerenciar as chaves de criptografia, controlar quem tem acesso a elas, e auditar seu uso. Isso permite que a CCR mantenha um alto nível de segurança e controle sobre as chaves de criptografia, mesmo quando elas são armazenadas na nuvem.

19. **O produto permite a criptografia usando a ferramenta GPG?**
O produto suporta criptografia usando GPG para e-mails e arquivos específicos.

20. **Existe um processo de sanitização dos dados? Se sim, pode descrever como funciona?**
Nosso processo de sanitização de dados está em conformidade com as melhores práticas da indústria e os padrões regulatórios, incluindo GDPR, HIPAA, entre outros. Utilizamos as mais recentes tecnologias e metodologias para garantir que a sanitização seja realizada de maneira segura, eficaz e em conformidade com os requisitos legais e éticos.
* **Anonimização de Nomes:** Substituir nomes reais por identificadores anônimos. Por exemplo, "João Silva" pode ser substituído por "Cliente 12345".
* **Pseudonimização de Contatos:** Substituir números de telefone e endereços de e-mail por valores pseudônimos. Por exemplo, o número de telefone "9999-8888" pode ser substituído por "Telefone X1Z2" e o e-mail "[e-mail]" por "[e-mail]".
* **Generalização de Endereços:** Em vez de fornecer endereços residenciais completos, que são informações muito específicas, os endereços podem ser generalizados para mostrar apenas a cidade ou o estado. Por exemplo, "Rua das Flores, 123, São Paulo, SP" pode ser simplificado para "São Paulo, SP".
* **Modificação de Datas de Nascimento:** As datas de nascimento podem ser alteradas para mostrar apenas o ano ou serem completamente removidas, dependendo da necessidade da análise de dados.
* **Banco de Dados Sanitizado:** Após o processo de sanitização, o banco de dados pode parecer algo assim:

22. **Caso tenha apontado falhas no teste de instrução e vulnerabilidade, as mesmas foram corrigidas? Se não foi, qual a previsão de correção?**
Todas as falhas identificadas são priorizadas e corrigidas de acordo com a gravidade, com a maioria sendo endereçada em até 15 dias.

23. **Quais os mecanismos de proteção contra-ataques DDOS (Descreva)?**
Implementamos várias camadas de proteção contra DDOS, incluindo balanceadores de carga, firewalls e serviços de mitigação de DDOS.

24. **Existe um documento que descreva os processos de Backup/Restore?**
Documento de Backup/Restore: Normalmente, as organizações possuem documentação detalhada sobre seus processos de backup e restauração, descrevendo procedimentos, frequência, tipos de dados salvos, etc.

25. **O procedimento de Backup/Restore foi testado? Possui evidências? (anexar a este questionário)**
*Teste de Procedimento:* Empresas geralmente realizam testes regulares de seus procedimentos de backup e restauração para garantir a eficácia e a confiabilidade. As evidências desses testes são normalmente documentadas.

26. **Existe uma cláusula no contrato padrão o qual o fornecedor se responsabiliza pela segurança do ambiente e em caso de vazamento de informação e suas devidas penalidades?**
* *Obrigação de Proteção de Dados:* O fornecedor se compromete a implementar medidas de segurança apropriadas para proteger os dados da empresa contratante contra acessos não autorizados, divulgação ou vazamento.
* *Notificação de Violação de Dados:* O fornecedor concorda em notificar prontamente a empresa contratante caso ocorra uma violação de dados que possa afetar a confidencialidade ou integridade das informações.
* *Responsabilidade Financeira:* O contrato pode estipular penalidades financeiras ou outras responsabilidades legais se o fornecedor não cumprir suas obrigações de segurança ou causar vazamento de informações.
* *Seguro de Responsabilidade Civil:* Às vezes, o contrato pode exigir que o fornecedor mantenha um seguro de responsabilidade civil para cobrir os custos associados a violações de dados.

27. **Existe alguma política interna que force o mínimo de privilégio necessário?**
Em geral as Empresas de tecnologia frequentemente adotam políticas de mínimo privilégio, garantindo que os usuários e sistemas tenham apenas os acessos estritamente necessários para suas funções.
Na Atualidade estamos utilizando o requisito de sergurança chamado zero trust.

28. **Nos últimos 6 meses foi aplicado testes de Intrusão e Vulnerabilidade (Ex.: Pentest, Ethical Hacking)? Qual foi o escopo?**
Organizações realizam periodicamente testes de intrusão e avaliações de vulnerabilidade (como pentests) para identificar e corrigir falhas de segurança. O escopo desses testes varia, mas geralmente inclui infraestrutura de rede, aplicações e sistemas críticos.

29. **Pode nos enviar o relatório do Teste de Intrusão e Vulnerabilidade? (anexar a este questionário)**
O relatório detalhado dos testes de intrusão e vulnerabilidade é normalmente disponibilizado pelasempresas após a conclusão dos testes, resumindo as descobertas e recomendações.

30. **Vocês realizam varreduras de vulnerabilidades e tem um programa para monitorar e aplicar regularmente patches de segurança à sua infraestrutura e aplicativos (usando ferramentas padrão da indústria acreditadas)?**
Empresas utilizam ferramentas padrão da indústria para realizar varreduras regulares de vulnerabilidade e aplicam patches de segurança de forma programada para manter a infraestrutura e aplicações seguras.

31. **Caso tenha apontado falhas no teste de instrução e Vulnerabilidade, as mesmas foram corrigidas? Se não foi, qual a previsão de correção?**
* **Relatório de Vulnerabilidade:** Após um pentest, a equipe de teste fornece um relatório detalhando as vulnerabilidades encontradas.
* **Análise de Vulnerabilidade:** A equipe responsável pelo sistema analisa essas vulnerabilidades para entender sua gravidade e impacto potencial.
* **Plano de Remediação:** Com base na análise, é desenvolvido um plano de remediação para corrigir as falhas. Isso pode incluir patches de software, mudanças na configuração do sistema, melhorias na arquitetura de rede, entre outros.
* **Implementação de Correções:** As correções são implementadas de acordo com o plano.
* **Reavaliação:** Após a implementação das correções, é comum realizar outro pentest para garantir que as vulnerabilidades foram efetivamente resolvidas.

32. **A empresa possui Certificações ou experiência comprovada dos funcionários nos itens Citados acima, pode descreve-las.**
As organizações de TI geralmente têm funcionários com certificações relevantes e experiência comprovada em segurança de TI, desenvolvimento de software, arquitetura de sistemas, entre outros.

33. **Quais os Designers Patterns aplicados na Arquitetura ?**
* **Singleton:** Usado quando é necessário que uma classe tenha uma única instância acessível globalmente. É comum em casos como gerenciamento de configurações ou conexões com banco de dados, onde você não quer que múltiplas instâncias controlem o recurso.
* **Factory:** Este padrão é útil quando o processo de criação de um objeto é complexo ou precisa ser isolado do código cliente. Ele permite criar objeto sem expor a lógica de criação ao cliente e referir-se aos objetos recém-criados por meio de uma interface comum.
* **Strategy:** Permite definir uma família de algoritmos, encapsular cada um deles e torná-los intercambiáveis. Este padrão é usado quando várias versões de um algoritmo existem, ou quando o algoritmo tem muitas variantes e está sujeito a mudanças frequentes
* **Observer:** Utilizado para criar um sistema de subscrição onde os objetos podem "observar" e serem notificados sobre mudanças em outros objetos. É bastante utilizado em interfaces gráficas de usuário, sistemas de eventos ou em qualquer lugar onde um objeto precisa reagir a mudanças ocorridas em outro objeto.
* **Prototype:** Cria novos objetos copiando um objeto existente, conhecido como protótipo. Este padrão é usado quando a criação direta de um objeto é considerada ineficiente.
* **Adapter (Wrapper):** Permite que a interface de uma classe existente seja usada como outra interface. É frequentemente usado para fazer com que classes incompatíveis trabalhem juntas.
* **Decorator:** Adiciona responsabilidades adicionais a um objeto de forma dinâmica. Os decoradores fornecem uma alternativa flexível à herança para estender a funcionalidade.
* **Proxy:** Fornece um substituto ou representante de outro objeto para controlar o acesso a ele. Utilizado em situações como lazy loading, controle de acesso, logging, etc.
* **Command:** Encapsula uma solicitação como um objeto, permitindo parametrizar clientes com diferentes solicitações, enfileirar ou registrar solicitações e implementar operações reversíveis.
* **State:** Permite a um objeto alterar seu comportamento quando seu estado interno muda. O objeto parecerá mudar sua classe.
* **Chain of Responsibility:** Passa uma solicitação ao longo de uma cadeia de manipuladores. Ao receber uma solicitação, cada manipulador decide se processa a solicitação ou a passa adiante na cadeia.
* **Builder:** Separa a construção de um objeto complexo da sua representação, permitindo que o mesmo processo de construção crie diferentes representações. É útil quando um objeto deve ser criado com muitas opções possíveis de configuração.
* **Composite:** Composta objetos em estruturas de árvore para representar hierarquias parte-todo. Permite aos clientes tratar objetos individuais e composições de objetos uniformemente.
* **Flyweight:** Usa compartilhamento para suportar eficientemente grandes quantidades de objetos de granularidade fina, reduzindo o custo de memória.
* **Interpreter:** Fornece uma maneira de avaliar a gramática ou expressão de uma linguagem específica. É comumente usado em compiladores e processadores de texto.
* **Iterator:** Fornece uma maneira de acessar os elementos de um objeto agregado sequencialmente sem expor sua representação subjacente.
* **Publish-Subscribe:** Semelhante ao Observer, mas com uma abordagem mais orientada a eventos, onde os assinantes se inscrevem para receber eventos/notificações de publicadores.
* **Service Locator:** Usado para localizar serviços usando JNDI lookup. Encoraja o projeto a ser independente de qualquer serviço específico, permitindo que eles sejam trocados ou adicionados dinamicamente.

34. **Utiliza arquitetura Hexagonal ?**
A arquitetura hexagonal, também conhecida como Portas
e Adapters, é adotada em alguns projetos para promover a separação de preocupações e facilitar a manutenção e testabilidade.

35. **UTiliza DDD, TDD, BDD. Se sim, onde vocês utilizam no Projeto.**
Utilizamos Domain-Driven Design (DDD), Test-Driven Development (TDD) e Behavior-Driven Development (BDD)
para aprimorar a qualidade e a eficiência do
desenvolvimento de software.

36. **Utilizada Arquitetura Orientado Para Componentes, Se o projeto é um Legado, qual o Servidor, exemplo. WebLogic, Webshphere, JBoss. Qual o modelo de CiCd aplicado .**
Arquitetura Orientada a Componentes: Esta abordagem se concentra na decomposição do design em componentes funcionais ou lógicos reutilizáveis. Em sistemas legados, os componentes podem ser implementados como módulos, bibliotecas ou serviços que executam funções específicas e podem ser integrados para formar aplicações mais complexas.

* **Servidores de Aplicações em Projetos Legados:**
* **WebLogic:** Uma plataforma da Oracle frequentemente usada em sistemas empresariais. É conhecida por sua estabilidade e funcionalidades robustas de clustering, carga de trabalho e gerenciamento de transações.
* **WebSphere:** Desenvolvido pela IBM, o WebSphere é outro servidor de aplicações popular em ambientes corporativos, oferecendo suporte a Java EE, integrações de sistema e melhorias na performance.
* **JBoss:** Agora conhecido como WildFly e mantido pela Red Hat, é uma opção de código aberto para servidores de aplicações, oferecendo uma plataforma leve e flexível, mas ainda poderosa para aplicações empresariais.
* **Modelo de CI/CD em Projetos Legados:**
* **Continuous Integration (CI):** Em um projeto legado, a integração contínua envolveria a automação de builds e testes sempre que uma mudança de código é feita. Isso pode ser desafiador em sistemas legados devido à falta de testes automatizados ou integração com ferramentas modernas de CI.
* **Continuous Delivery/Deployment (CD):** A entrega ou implantação contínua em projetos legados pode exigir a modernização de processos de implantação, com a adoção de ferramentas de automação para garantir implantações consistentes e confiáveis. A entrega contínua é mais desafiadora em ambientes legados devido à possibilidade de dependências rígidas e complexas.

O modelo de CI/CD aplicado dependerá do quão modernizado o sistema legado está e das ferramentas que são compatíveis com a sua stack tecnológica. Em alguns casos, pode ser necessário um trabalho significativo para adaptar práticas modernas de CI/CD a um ambiente legado, especialmente se houver uma mistura de tecnologias antigas e novas. Ferramentas como Jenkins, GitLab CI/CD, CircleCI, entre outras, podem ser adaptadas para sistemas legados, mas isso geralmente requer uma abordagem personalizada.

37. **Como vocês fazem o a utilização das integrações via txt, json, xml wsld.**
Integrações são realizadas usando diversos formatos como txt, JSON, XML, WSDL, dependendo dos requisitos do sistema e da compatibilidade entre os sistemas envolvidos.

38. **Qual o modelo de Messageria Utilizado por vocês. Tem experiência com a Kafka stream, cloud Confluent, ou RabbitMqStream**
Modelos de mensageria como Kafka Stream, Cloud Confluent são usados para gerenciar fluxos de dados e mensagens em sistemas distribuídos.

39. **Utiliza trabalho de Observabilidade com qual tipo de Soluções voltadas para o Log, Como Grafana defindo a medição dos eventuais bugs que o sistema pode apresentar.**

Utilizamos a Observabilidade e Monitoramento. **Observabilidade** é uma abordagem de monitoramento que se concentra em coletar dados abrangentes sobre o sistema e permite entender seu comportamento em tempo real. Envolve a coleta de dados de várias fontes, incluindo logs, métricas (dados quantitativos), e traces (registros detalhados das transações) para obter uma imagem completa do sistema. O objetivo principal da observabilidade é fornecer informações detalhadas que permitam aos desenvolvedores identificar e resolver problemas rapidamente, melhorar o desempenho e otimizar os sistemas.

**Ferramentas de Observabilidade:** Para implementar a observabilidade, as organizações usam uma variedade de ferramentas, incluindo:
* **Ferramentas de Logs:** Como o Grafana, que ajudam a coletar, armazenar e visualizar registros (logs) gerados pelo sistema.
* **Ferramentas de Métricas:** Como o Prometheus, que coletam dados quantitativos sobre o sistema, como uso de CPU, memória, tráfego de rede, etc.
* **Ferramentas de Traces:** Como o Jaeger ou o Zipkin, que registram detalhes sobre as transações do sistema para rastrear o fluxo de informações e identificar gargalos ou problemas de desempenho.

Grafana como Ferramenta de Observabilidade:

O Grafana é uma ferramenta de visualização de dados poderosa e flexível, frequentemente usada em conjunto com outras ferramentas de observabilidade.
Ele permite que desenvolvedores criem dashboards personalizados para visualizar e analisar dados de log, métricas e traces de forma centralizada.

O Grafana oferece suporte a uma variedade de fontes de dados, o que significa que você pode integrá-lo com diferentes sistemas de coleta de dados, como Prometheus, InfluxDB, Elasticsearch, entre outros.

Os desenvolvedores podem criar painéis interativos, gráficos de séries temporais, tabelas e alertas com base nos dados coletados, facilitando a identificação de tendências e anomalias.
Benefícios do Grafana na Observabilidade:

O Grafana simplifica a visualização de dados complexos, tornando mais fácil para os desenvolvedores entenderem o que está acontecendo no sistema em tempo real.

Os painéis personalizáveis permitem que as equipes de operações e desenvolvimento criem visualizações específicas para suas necessidades e objetivos.
A capacidade de configurar alertas no Grafana permite que os desenvolvedores sejam notificados imediatamente quando ocorrem problemas ou desvios nos dados monitorados.

40. Quais os modelos de Diagramas de Arquitetura que apresentaram para a proposta.

41. A defesa do Diagrama de Arquitetura.

42. Como faz o seu Deploy canary, A/B, Blue-Green,circle Ci-cd, down time.

Implantação blue-green
 
A/B Testing e Canary Releases

A/B testing e releases canary são duas estratégias de teste de software que podem ser usadas para reduzir o risco de implantação de novas versões de software.

A/B Testing

O A/B testing é uma estratégia de teste que envolve a exibição de duas ou mais versões de uma mesma página, email ou outro item de conteúdo para diferentes grupos de usuários. A versão que obtém os melhores resultados é então escolhida para ser implantada para todos os usuários.

O A/B testing pode ser usado para testar uma variedade de coisas, incluindo:

Novas funcionalidades: O A/B testing pode ser usado para testar novas funcionalidades para ver se elas são bem recebidas pelos usuários.
Alterações de design: O A/B testing pode ser usado para testar alterações de design para ver se elas melhoram a experiência do usuário.
Alterações de conteúdo: O A/B testing pode ser usado para testar alterações de conteúdo para ver se elas aumentam as conversões.
Canary Releases

Um release canary é uma estratégia de implantação que envolve a implantação de uma nova versão de software para um pequeno grupo de usuários antes de implantá-la para todos os usuários. O grupo de usuários que recebe a nova versão é chamado de "canary".

Os releases canary podem ser usados para testar uma variedade de coisas, incluindo:

Resistência: Os releases canary podem ser usados para testar a resistência de uma nova versão de software a erros ou problemas de desempenho.
Aceitação: Os releases canary podem ser usados para testar a aceitação de uma nova versão de software pelos usuários.
Impacto: Os releases canary podem ser usados para medir o impacto de uma nova versão de software no desempenho do sistema ou na experiência do usuário.
Vantagens e desvantagens

Ambas as estratégias têm vantagens e desvantagens.

Vantagens do A/B testing:

Pode fornecer insights valiosos sobre o que os usuários querem e precisam.
É relativamente simples de implementar.
Desvantagens do A/B testing:

Pode levar tempo para coletar dados suficientes para tirar conclusões significativas.
Pode ser frustrante para os usuários que recebem a versão perdedora do teste.
Vantagens dos releases canary:

Pode ajudar a identificar problemas com uma nova versão de software antes de implantá-la para todos os usuários.
Pode ajudar a reduzir o impacto de uma nova versão de software que não for bem recebida pelos usuários.
Desvantagens dos releases canary:

Pode ser mais complexo de implementar do que o A/B testing.
Pode ser necessário monitorar o desempenho da nova versão de software de perto para garantir que não haja problemas.
Quando usar qual estratégia?

A melhor estratégia a usar depende de uma série de fatores, incluindo:

O objetivo do teste: Se você estiver testando uma nova funcionalidade ou alteração de design, o A/B testing pode ser a melhor opção. Se você estiver testando a resistência ou aceitação de uma nova versão de software, o release canary pode ser a melhor opção.
O tamanho da sua base de usuários: Se você tiver uma base de usuários pequena, o A/B testing pode ser uma boa opção, pois você poderá implantar a versão ganhadora para todos os usuários rapidamente. Se você tiver uma base de usuários grande, o release canary pode ser uma boa opção, pois você poderá implantar a nova versão para todos os usuários gradualmente.
O tempo disponível: O A/B testing pode levar mais tempo para coletar dados suficientes para tirar conclusões significativas. Se você tiver pouco tempo, o release canary pode ser uma boa opção.
Exemplos de uso

O A/B testing e os releases canary são usados por uma variedade de empresas, incluindo:

Google: O Google usa o A/B testing para testar novos recursos e alterações de design em seus produtos, como o Gmail e o Google Maps.
Amazon: A Amazon usa o A/B testing para testar novos produtos e preços.
Netflix: A Netflix usa o A/B testing para testar novos conteúdos e recomendações.
Conclusão

O A/B testing e os releases canary são duas estratégias poderosas que podem ajudar a reduzir o risco de implantação de novas versões de software. A melhor estratégia a usar depende de uma série de fatores, incluindo o objetivo do teste, o tamanho da sua base de usuários e o tempo disponível.

#
Como funciona o CircleCI?

O CircleCI funciona utilizando pipelines. As pipelines são uma série de etapas que definem o processo de construção, teste e implantação do software. Cada etapa em uma pipeline pode ser configurada para executar um determinado comando ou script.

Quando há uma mudança no código-fonte, o CircleCI inicia automaticamente a execução da pipeline. Cada etapa da pipeline é executada sequencialmente até que todas as etapas sejam concluídas com sucesso. Se qualquer etapa falhar, o processo de implantação é interrompido e os desenvolvedores são notificados.

CircleCI é uma plataforma poderosa e versátil que pode ajudar equipes de desenvolvimento a acelerar o lançamento de software de alta qualidade. Com seus recursos abrangentes e interface fácil de usar, o CircleCI é uma ótima opção para equipes de todos os tamanhos.
#
Blue-Green Deployment: Implantação Sem Downtime
O Blue-Green deployment é uma estratégia de implantação de software que visa minimizar o tempo de inatividade (downtime) durante a atualização da aplicação. Ele funciona criando dois ambientes idênticos:

Ambiente Blue: ambiente de produção atual, acessível pelos usuários.
Ambiente Green: ambiente novo, onde a nova versão da aplicação é instalada e testada.
Como funciona:

Preparação: A nova versão da aplicação é construída e enviada para o ambiente Green.
Testes: A nova versão é rigorosamente testada no ambiente Green, simulando o cenário de produção.
Validação: Após os testes serem concluídos com sucesso, a nova versão é considerada estável e pronta para migração.
Troca de tráfego: O roteamento de tráfego é redirecionado do ambiente Blue para o ambiente Green. Isso pode ser feito de forma instantânea ou gradual, dependendo da estratégia escolhida.
Descomissionamento: O ambiente Blue desativado e removido após a confirmação da estabilidade da nova versão no ambiente Green.
Vantagens:
 
Zero downtime: Usuários finais não experimentam tempo de inatividade, pois a nova versão é implementada em um ambiente separado até ser validada.
Redução de risco: Problemas na nova versão não impactam a produção imediatamente, pois são detectados e corrigidos no ambiente Green antes da migração final.
Rollbacks fáceis: Em caso de falhas críticas, é possível reverter o tráfego para o ambiente Blue rapidamente, preservando a continuidade do serviço.
Implantação contínua: Facilita a implementação de atualizações frequentes, pois o ciclo de desenvolvimento e teste ocorre em um ambiente dedicado, sem afetar a produção.
Desvantagens:

Custo de infraestrutura: A necessidade de dois ambientes idênticos pode aumentar o custo de infraestrutura.
Complexidade operacional: Requer um plano de roteamento de tráfego bem definido e uma boa infraestrutura de gerenciamento de ambientes.
Migração de dados: Em aplicações com dados persistentes, o processo de migração deve ser planejado com cuidado para evitar perda de dados.

Downtime é o tempo durante o qual um serviço ou aplicação está indisponível para os usuários. Zero downtime é o objetivo de não ter nenhum downtime durante um processo de implantação.

Blue-green deployment é uma estratégia de implantação que envolve a criação de duas instâncias paralelas de uma aplicação, uma na versão atual e outra na versão nova. Uma vez que a versão nova esteja testada e aprovada, o tráfego é redirecionado para a nova instância, e a instância antiga é desativada.

Canary deployment é uma estratégia de implantação que envolve o lançamento da nova versão da aplicação para um pequeno grupo de usuários, geralmente em um ambiente de teste. O desempenho e a funcionalidade da nova versão são monitorados, e se tudo estiver bem, a nova versão é lançada para o resto dos usuários.

A principal diferença entre essas estratégias é a forma como o tráfego é redirecionado para a nova versão da aplicação. No blue-green deployment, todo o tráfego é redirecionado para a nova versão de uma só vez. No canary deployment, o tráfego é redirecionado para a nova versão gradualmente, começando com um pequeno grupo de usuários.

O blue-green deployment é uma estratégia mais simples de implementar, mas pode ser mais disruptiva para os usuários, pois todo o tráfego é redirecionado para a nova versão de uma só vez. O canary deployment é uma estratégia mais complexa de implementar, mas pode ser menos disruptiva para os usuários, pois o tráfego é redirecionado para a nova versão gradualmente.

A estratégia ideal de implantação depende de uma série de fatores, incluindo o tipo de aplicação, o volume de tráfego e os requisitos de disponibilidade.

Aqui está uma tabela que resume as principais diferenças entre as três estratégias:

## Funcionamento Aws
43.Recursos e serviços AWS .

A Amazon Web Services (AWS) oferece uma ampla gama de recursos e serviços em seu portfólio para atender às necessidades de infraestrutura de empresas, desenvolvedores e organizações em todo o mundo. Aqui estão alguns dos principais recursos e serviços da AWS:

Computação:

Amazon EC2 (Elastic Compute Cloud): Oferece máquinas virtuais escaláveis em nuvem para executar aplicativos.
AWS Lambda: Permite a execução de código sem provisionar ou gerenciar servidores.
Armazenamento:

Amazon S3 (Simple Storage Service): Armazenamento de objetos escalável e altamente durável.
Amazon EBS (Elastic Block Store): Armazenamento de blocos para instâncias EC2.
Amazon RDS (Relational Database Service): Serviço de banco de dados relacional gerenciado.
Rede:

Amazon VPC (Virtual Private Cloud): Criação de redes isoladas na nuvem.
AWS Direct Connect: Conexão dedicada de rede à AWS.
Amazon Route 53: Serviço de DNS gerenciado.
Gerenciamento de Conta e Segurança:

AWS Identity and Access Management (IAM): Controle de acesso e segurança.
AWS Organizations: Gerenciamento de várias contas AWS.
AWS Trusted Advisor: Verificação de conformidade e otimização de recursos.
Monitoramento e Logging:

Amazon CloudWatch: Monitoramento e geração de logs.
AWS CloudTrail: Registro de auditoria de atividades da conta.
AWS X-Ray: Rastreamento de aplicativos para identificar problemas de desempenho.
Serviços de Aplicativos e Desenvolvimento:

AWS Elastic Beanstalk: Implantação de aplicativos web e serviços.
AWS App Runner: Implantação de contêineres e serviços em várias linguagens.
AWS Step Functions: Orquestração de serviços serverless.
IA e Machine Learning:

Amazon SageMaker: Plataforma de aprendizado de máquina.
Amazon Comprehend: Processamento de linguagem natural.
AWS Polly: Text-to-Speech (TTS) em vários idiomas.
Serviços de Contêineres e Orquestração:

Amazon ECS (Elastic Container Service): Orquestração de contêineres.
Amazon EKS (Elastic Kubernetes Service): Gerenciamento de clusters Kubernetes.
AWS Fargate: Gerenciamento de contêineres serverless.
Armazenamento de Dados e Análise:

Amazon DynamoDB: Banco de dados NoSQL gerenciado.
Amazon Redshift: Data warehouse gerenciado.
Amazon EMR (Elastic MapReduce): Processamento de big data.
IoT (Internet of Things):

AWS IoT Core: Gerenciamento de dispositivos IoT.
AWS IoT Greengrass: Extensão do AWS IoT para dispositivos no local.
Segurança e Identidade:

AWS Key Management Service (KMS): Gerenciamento de chaves de criptografia.
AWS Certificate Manager: Gerenciamento de certificados SSL/TLS.
AWS WAF (Web Application Firewall): Proteção contra ameaças na web.
Armazenamento de Arquivos e Mídia:

Amazon EFS (Elastic File System): Sistema de arquivos compartilhado.
Amazon FSx: Armazenamento de arquivos Windows e Lustre.
AWS Elemental MediaConvert: Conversão de mídia em escala.
Serviços de DevOps:

AWS CodePipeline: Automação de entrega contínua.
AWS CodeBuild: Compilação e testes de código.
AWS CodeDeploy: Implantação de aplicativos.
Serviços de Negócios e Análise:

Amazon QuickSight: Visualização e análise de dados.
AWS Data Pipeline: Orquestração de processamento de dados.
HPC (High Performance Computing):

Amazon EC2 Instances para HPC: Recursos de computação de alto desempenho.
Blockchain:

Amazon Managed Blockchain: Gerenciamento de redes blockchain.
Essa lista abrange apenas uma fração dos serviços e recursos disponíveis na AWS. A plataforma oferece muitos outros serviços especializados para atender às diversas necessidades de negócios e desenvolvimento. Cada serviço é projetado para ser altamente escalável, seguro e altamente disponível. A escolha dos serviços depende dos requisitos específicos do seu projeto.

User

Qual a diferença do EBS para RDs
ChatGPT
O Amazon Elastic Block Store (EBS) e o Amazon Relational Database Service (RDS) são serviços da Amazon Web Services (AWS) usados para armazenamento de dados, mas eles têm finalidades diferentes e são projetados para atender a diferentes necessidades. Aqui estão as principais diferenças entre o EBS e o RDS:

Finalidade:

EBS (Elastic Block Store): É um serviço de armazenamento de blocos que fornece volumes de armazenamento persistentes que podem ser anexados a instâncias EC2. O EBS é usado principalmente para armazenar dados que precisam ser acessados diretamente por instâncias EC2, como sistemas de arquivos, bancos de dados locais ou outros dados específicos da instância.

RDS (Relational Database Service): É um serviço de banco de dados relacional gerenciado que oferece suporte a diversos mecanismos de banco de dados, como MySQL, PostgreSQL, SQL Server, Oracle e outros. O RDS é usado para criar, operar e escalar bancos de dados relacionais na nuvem, sem a necessidade de gerenciar a infraestrutura subjacente.

Tipo de Dados Armazenados:

EBS: Armazena qualquer tipo de dados, incluindo arquivos, sistemas de arquivos, bancos de dados locais e qualquer outra forma de armazenamento de blocos. É mais flexível e pode ser usado para várias finalidades.

RDS: Especificamente projetado para armazenar e gerenciar bancos de dados relacionais, como MySQL, PostgreSQL, SQL Server e outros. É altamente otimizado para desempenho e confiabilidade de bancos de dados.

Gerenciamento:

EBS: O gerenciamento do conteúdo e do sistema de arquivos armazenado no EBS é de responsabilidade do usuário. Você precisa configurar, instalar e gerenciar o software necessário em suas instâncias EC2 para usar o EBS como desejar.

RDS: O RDS é um serviço gerenciado que cuida de tarefas operacionais, como backups, atualizações de software, dimensionamento automático e monitoramento. Isso simplifica a administração de bancos de dados, permitindo que você se concentre na lógica do aplicativo e nos dados.

Escalabilidade:

EBS: A escalabilidade é controlada manualmente. Você pode aumentar o tamanho dos volumes EBS ou anexar mais volumes conforme necessário. No entanto, isso requer intervenção manual.

RDS: Oferece opções de dimensionamento automático para aumentar ou diminuir a capacidade do banco de dados conforme a demanda. Isso é feito de forma automatizada com base nas configurações definidas.

Backup e Recuperação:

EBS: É possível criar snapshots (cópias instantâneas) dos volumes EBS para fins de backup e recuperação. Você deve configurar e gerenciar os snapshots manualmente.

RDS: O RDS fornece backup automatizado e opções de retenção de backups configuráveis. Os backups são gerenciados pelo serviço e podem ser facilmente restaurados quando necessário.

Em resumo, o EBS é um serviço de armazenamento de blocos mais genérico e flexível, adequado para armazenar dados de instâncias EC2 e outras necessidades de armazenamento de blocos, enquanto o RDS é um serviço gerenciado de banco de dados relacional projetado especificamente para armazenar e gerenciar bancos de dados relacionais, oferecendo recursos específicos para bancos de dados, como backups automáticos, dimensionamento automático e gerenciamento simplificado. A escolha entre eles depende das necessidades do seu aplicativo e dos tipos de dados que você precisa armazenar e gerenciar.

## Testes

Desenvolvimento de Testes (TDD) ?

O Desenvolvimento Orientado a Testes (TDD - Test-Driven Development) e o BDD (Behavior-Driven Development) são abordagens que enfatizam a escrita de testes antes de escrever o código de produção. Eles podem ser incorporados em projetos Spring Boot para melhorar a qualidade do código e garantir que os requisitos sejam atendidos. Para incorporar o TDD em seu projeto Spring Boot, siga estas etapas:

Crie um Plano de Teste: Antes de começar a codificar, defina claramente o que você deseja alcançar com o código que está prestes a escrever. Isso pode incluir cenários de teste, casos de uso ou requisitos específicos que você deseja atender.

Escreva Testes Unitários: Comece escrevendo testes unitários para as unidades de código mais baixas, como classes e métodos individuais. Use uma estrutura de teste, como JUnit, e execute esses testes para garantir que eles falhem inicialmente, já que o código de produção ainda não foi escrito.

Escreva o Código de Produção: Após escrever os testes que definem o comportamento desejado, escreva o código de produção para fazer com que os testes passem. Mantenha-se focado no objetivo do teste e no que você deseja alcançar.

Refatore o Código: Depois que seus testes passarem, você pode refatorar o código para melhorar a qualidade e a legibilidade. Certifique-se de que os testes ainda estejam passando após a refatoração.

Repita o Processo: Repita o processo para cada nova funcionalidade ou alteração no código existente. Sempre comece escrevendo testes que definam o comportamento esperado antes de escrever o código de produção.

Integração Contínua: Configure uma integração contínua (CI) para automatizar a execução dos testes em cada push de código. Isso garantirá que os testes sejam executados regularmente para pegar problemas o mais cedo possível.

Testes de Integração e Testes de Ponta a Ponta: Além dos testes unitários, também crie testes de integração para garantir que as várias partes do seu aplicativo funcionem bem juntas. Os testes de ponta a ponta podem ser úteis para validar o fluxo completo do aplicativo.

Testes Automatizados em Todos os Níveis: Garanta que você tenha testes automatizados em todos os níveis, desde unidades de código até testes de integração e testes de aceitação. Isso fornecerá uma cobertura completa e maior confiança na qualidade do seu aplicativo.

Revisão de Código: Faça revisões de código regularmente com colegas de equipe para garantir que os padrões de codificação e as melhores práticas sejam seguidos. Certifique-se de que todos os testes necessários estejam incluídos.

Documentação dos Testes: Mantenha a documentação dos testes atualizada para que outros membros da equipe possam entender e manter os testes à medida que o código evolui.

Lembre-se de que o TDD é uma abordagem que requer prática e disciplina. À medida que você se acostuma com essa abordagem, verá os benefícios de código mais confiável, fácil manutenção e maior rapidez na detecção de problemas. Incorporar TDD e BDD em seu projeto Spring Boot pode levar a um desenvolvimento mais eficiente e robusto.

## Microservice estilo de programação

A programação baseada em microsserviços para OpenShift envolve várias práticas e ferramentas específicas para criar e gerenciar uma arquitetura de microsserviços eficiente e escalável. O OpenShift, sendo uma plataforma que estende o Kubernetes, oferece um ambiente robusto para implantar e gerenciar microsserviços. Aqui estão os passos e considerações principais:

Design de Microsserviços:

Divisão de Responsabilidades: Divida a aplicação em componentes menores e independentes, cada um com uma responsabilidade única.
APIs e Contratos: Defina APIs claras para a comunicação entre os microsserviços. Assegure que os contratos de API sejam bem documentados e versionados.
Desenvolvimento de Microsserviços:

Linguagens e Frameworks: Escolha linguagens e frameworks adequados para cada microsserviço. Com microsserviços, é possível utilizar diferentes tecnologias em diferentes serviços.
Isolamento e Independência: Cada microsserviço deve ser independente, podendo ser desenvolvido, implantado e escalado separadamente.
Contêinerização:

Docker: Empacote cada microsserviço em seu próprio contêiner usando Docker. Isso inclui o código do serviço, bem como suas dependências.
Dockerfile: Crie um Dockerfile para definir como o contêiner do microsserviço será construído.
Implantação no OpenShift:

Imagens de Contêiner: Faça o upload das imagens de contêiner para um registry (como o Red Hat Quay ou o registry integrado do OpenShift).
DeploymentConfigs/Pods: Use DeploymentConfigs no OpenShift para gerenciar o deployment dos contêineres dos microsserviços.
Serviços e Roteamento:

Kubernetes Services: Use Kubernetes Services para expor os microsserviços dentro do cluster.
Roteamento e Ingress: Utilize recursos de roteamento do OpenShift para expor os microsserviços fora do cluster.
Configuração e Gerenciamento de Estado:

ConfigMaps e Secrets: Armazene configurações e segredos usando ConfigMaps e Secrets do Kubernetes.
Persistência de Dados: Use volumes persistentes para gerenciar dados que precisam ser mantidos entre reinicializações do contêiner.
Monitoramento e Logging:

Prometheus e Grafana: Integre com ferramentas como Prometheus para monitoramento e Grafana para visualização.
Elasticsearch e Kibana: Para logging, considere uma stack como Elasticsearch, Fluentd e Kibana (EFK).
Automação e CI/CD:

Jenkins ou Tekton: Implemente pipelines de CI/CD usando Jenkins ou Tekton para automação de testes, build e deployment.
Operators: Considere o uso de Operators no OpenShift para automação operacional dos microsserviços.
Escalabilidade e Resiliência:

Autoescala: Utilize a autoescala do OpenShift para ajustar automaticamente o número de réplicas dos microsserviços com base na carga.
Padrões de Resiliência: Implemente padrões como circuit breakers, retries e timeouts para aumentar a resiliência dos microsserviços.
Segurança:

Network Policies: Aplique políticas de rede para controlar o tráfego entre os serviços.
Role-Based Access Control (RBAC): Utilize o RBAC do Kubernetes para controlar o acesso aos recursos.
Lembrando que cada microsserviço no OpenShift é uma entidade independente, o que implica em desafios específicos de integração e comunicação. É fundamental uma abordagem cuidadosa em relação ao design, desenvolvimento e manutenção dos microsserviços para garantir um sistema coeso e eficiente.

## ServerLess Kafka Java

import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.apache.kafka.clients.consumer.KafkaConsumer;

import java.util.Arrays;
import java.util.Properties;

public class KafkaTriggeredFunction {

    public void handleRequest(String topicName) {
        Properties props = new Properties();
        props.put("bootstrap.servers", "KAFKA_CLUSTER_ENDPOINT");
        props.put("group.id", "my-group");
        props.put("enable.auto.commit", "true");
        props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
        props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

        try (KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props)) {
            consumer.subscribe(Arrays.asList(topicName));

            ConsumerRecords<String, String> records = consumer.poll(1000);
            for (ConsumerRecord<String, String> record : records) {
                processMessage(record);
            }
        }
    }

    private void processMessage(ConsumerRecord<String, String> record) {
        // Processar a mensagem
        System.out.println("Recebendo mensagem: " + record.value());
        // Implemente a lógica de processamento aqui
    }
}

#
Login
oc login [URL_DO_CLUSTER] -u [NOME_USUARIO] -p [SENHA]
#
NoVo Projeto
oc new-project [NOME_DO_PROJETO]
#
Mudar para um projeto existente:
 
oc project [NOME_DO_PROJETO]

#
A partir de uma imagem Docker existente:
oc new-app [NOME_IMAGEM_DOCKER] --name=[NOME_APLICACAO]

 

#
Expor Serviços (criar uma rota externa):
oc expose svc/[NOME_SERVICO]

#

Escalonar Aplicações:

 
oc scale --replicas=[
    NUMERO_REPLICAS] deployment/[NOME_APLICACAO]

Verificar Logs:
oc logs [NOME_POD]


Executar Comandos Dentro de um Contêiner:
oc exec [NOME_POD] -- [COMANDO]



## ConfigMaps:
 
oc create configmap [NOME_CONFIGMAP] --from-literal=[CHAVE]=[VALOR]

# 

oc create secret generic [NOME_SECRET] --from-literal=[CHAVE]=[VALOR]

# 
Listar pods:
 oc get pods

#
Descrever recursos específicos (exemplo: pod):

oc describe pod [NOME_POD]

#
Criar um usuário:
oc create user [NOME_USUARIO]

#
Adicionar um usuário a um projeto:
 
oc adm policy add-role-to-user [ROLE] [NOME_USUARIO] -n [NOME_DO_PROJET

Você escolhe o ambiente de execução do Kubernetes. Ele pode ser servidores bare-metal, máquinas virtuais (VMs), provedores de nuvem pública, nuvens privadas e híbridas. Uma das principais vantagens do Kubernetes é que ele funciona em vários tipos de infraestrutura.

Descubra com os líderes da Red Hat como os containers revolucionam a nuvem híbrida aberta.

## APIs e webhooks
Um webhook é uma função de retorno de chamada baseada em HTTP que viabiliza uma comunicação lightweight e orientada por eventos entre duas APIs. Os webhooks são usados por várias aplicações web para receber pequenos volumes de dados de outras aplicações, mas também podem ser utilizados para acionar fluxos de trabalho de automação nos ambientes do GitOps.

Em geral, os webhooks são descritos como APIs reversas ou APIs de push, porque colocam a responsabilidade da comunicação no servidor, e não no cliente. Em vez de o cliente enviar as solicitações HTTP pedindo os dados até receber uma resposta, o servidor envia para o cliente uma solicitação HTTP POST exclusiva quando os dados estiverem disponíveis. Apesar dos apelidos, os webhooks não são APIs. Eles trabalham juntos. Uma aplicação precisa ter uma API para usar um webhook.

## Gateway
O gateway de API é uma ferramenta de gerenciamento de APIs que fica entre o cliente e uma coleção de serviços de back-end.

Ele funciona como um proxy inverso, que aceita todas as chamadas da interface de programação de aplicações (API), agrega os diversos serviços necessários para realizá-las e retorna o resultado apropriado.

## Função de Api de Gateway

A função do gateway no gerenciamento da API
Um gateway de API faz parte do sistema de gerenciamento da API. Ele intercepta todas as solicitações de entrada e as envia por meio desse sistema, que processa diversas funções necessárias.

A função exata do gateway varia de uma implementação para outra. Algumas funções comuns incluem autenticação, roteamento, limitação de taxa, faturamento, monitoramento, análise, políticas, alertas e segurança.

Nossas soluções de gerenciamento de APIs
Gerencie suas APIs com o 3scale
O Red Hat® 3scale API Management é uma plataforma de gerenciamento de APIs que facilita o compartilhamento, a proteção, a distribuição, o controle e a monetização de APIs. O 3scale API Management foi desenvolvido para escalar e aceitar arquiteturas híbridas (on-premise, na nuvem ou qualquer combinação de ambos). Quer tornar público e monetizar o acesso às suas APIs? Use um portal de desenvolvedores integrado e uma plataforma de integração com Stripe, Baintree e Adyen para proporcionar funcionalidades de faturamento completas e fáceis de usar por fornecedores e consumidores de API.

O 3scale API Management é dividido entre uma camada de gerenciamento de programas de API e outra de controle do tráfego da API. Os métodos mais tradicionais de controle de tráfego são mais demorados porque exigem a autenticação da chamada de API inteira. A nova camada de controle de tráfego precisa apenas inspecionar o cabeçalho da chamada recebida. Assim, o tráfego é verificado e autenticado com mais rapidez. Com os controles de acesso, de políticas e de tráfego, fica mais fácil autenticar o tráfego, restringi-lo por política, proteger os serviços de back-end, impor limites de taxa e criar níveis de acesso.

As duas camadas se comunicam entre si de maneira assíncrona, usando estratégias de armazenamento em cache configuráveis no gateway da API. Portanto, se, por exemplo, a configuração de políticas de gerenciamento da API não estiver disponível, o programa da API continuará a funcionar sem desacelerar. Como o gateway e o gerenciador de APIs são separados, é possível escalar de maneira independente e oferecer suporte a opções de implantação mais complexas.

O 3scale API Management inclui um portal do desenvolvedor totalmente personalizável. Assim, os desenvolvedores têm acesso a tudo o que precisam (gerenciamento de contas e aplicações, análises, gerenciamento de chaves da API etc.) em um único painel fácil de usar. Além disso, há uma ferramenta interativa de documentação de APIs que permite aos desenvolvedores examinar as APIs dinâmicas, e uma plataforma de análises que fornece todos os dados necessários sobre os padrões de tráfego e o desempenho. Por fim, é possível "empacotar as APIs" de maneira diferente em soluções distintas, definindo e configurando políticas variadas para consumidores diversos da API. Assim, você tem a liberdade de criar modelos de negócios exclusivos usando as mesmas APIs para atender a necessidades de clientes diferentes.

Saiba mais sobre o 3scale API Management
Integre os recursos da sua TI com o Fuse
O Red Hat Fuse é uma plataforma de integração distribuída que possibilita aos especialistas em integração, desenvolvedores de aplicações e usuários de negócios criar soluções conectadas de maneira colaborativa ou independente. Com o desenvolvimento centrado em APIs em um ambiente nativo em nuvem do Fuse, é mais fácil ampliar e reutilizar os serviços e as integrações. A arquitetura híbrida da solução e o uso da tecnologia de containers permitem aos usuários trabalhar em qualquer ambiente que desejarem, com a certeza de que o trabalho poderá ser compartilhado e utilizado em qualquer infraestrutura (on-premise, na nuvem ou qualquer combinação de ambos). Além disso, a base compartilhada e de fácil utilização garante uma governança clara e consistente, sendo mais uma garantia de que é possível a colaboração entre usuários distintos.

Nos últimos 15 anos, o padrão do setor para a integração empresarial era implantar um Enterprise Service Bus (ESB) centralizado e gerenciado por uma única equipe do departamento de TI. Nesse modelo, a equipe central era responsável por todas as necessidades de integração da empresa inteira. Esse modelo é adequado para determinados casos de uso, pois é eficiente e permite controlar implantações de integração. No entanto, ele atrasa as práticas modernas, como DevOps e fluxos de trabalho ágeis. Atualmente, a inovação é desenvolvida por equipes muito menores que trabalham de maneira colaborativa e é implantada em padrões muito mais frequentes. Se suas equipes trabalham de maneira ágil, você precisa de uma solução de integração de API compatível com esse tipo de abordagem. O Fuse inclui mais de 200 conectores para que você possa integrar tudo, de sistemas legados a redes de parceiros.

Com a interface low-code, desenvolvida com tecnologia drag and drop e funcionalidades de autosserviço, os usuários podem usar padrões predefinidos de integração e serviços para criar soluções empresariais novas. Esse é um modo de encorajar os diversos tipos de usuários a trabalhar de maneira colaborativa, mas com independência, para integrar aplicações legadas, APIs e dispositivos de Internet das Coisas (IoT) em uma solução unificada. Os recursos de automação garantem que as tarefas de teste, provisionamento e proteção de serviços individuais sejam realizadas de maneira rotineira, para que as suas equipes mantenham um pipeline de entrega contínua.

Saiba mais sobre o Red Hat Fuse
Serviços de gerenciamento de API com o OpenShift API Management
O Red Hat OpenShift API Management é um serviço de gerenciamento de APIs hospedado e gerenciado oferecido como uma solução complementar para o Red Hat OpenShift Dedicated – serviço totalmente gerenciado da plataforma empresarial Kubernetes, o Red Hat OpenShift.

O OpenShift API Management oferece suporte a equipes que buscam uma abordagem com foco em APIs para criar aplicações baseadas em microsserviços. Com ele, é possível modernizar os sistemas existentes, aumentar a produtividade dos desenvolvedores e acelerar a entrega de novas aplicações.

A Red Hat hospeda, gerencia e oferece suporte dedicado para o OpenShift Dedicated e o OpenShift API Management, incluindo configuração, manutenção e upgrades. Dessa forma, as equipes podem se concentrar no desenvolvimento, em vez de se preocuparem com o gerenciamento da infraestrutura Kubernetes.

Com o OpenShift API Management, você pode:

Implantar, monitorar e controlar APIs durante todo seu ciclo de vida
Criar políticas de segurança e de uso
Usar sistemas de gerenciamento de identidade existentes por meio de uma política declarativa sem exigir código personalizado
Obter insights sobre a integridade e o uso das APIs
Descobrir e compartilhar APIs por meio de publicações em portais para desenvolvedores internos ou externos
O OpenShift API Management, quando adicionado ao OpenShift Dedicated, oferece uma experiência do desenvolvedor otimizada para criar, implantar e escalar aplicações nativas em nuvem. Monitore, configure e publique todas as suas APIs usando uma interface unificada e otimizada para desenvolvedores.

Com um gerenciador de APIs, você conecta aplicações internas e externas em várias nuvens, estabelece a governança e as políticas da empresa (incluindo limites de taxa e uso) e gerencia as APIs em cada estágio do ciclo de vida de desenvolvimento.

Saiba mais sobre o OpenShift API Management
Inovação open source com a Red Hat
As soluções para APIs da Red Hat são desenvolvidas com as comunidades open source em mente. Isso significa que mais pessoas estão desenvolvendo software para solução de problemas de maneira aberta, transparente e livre. Mas não basta ser open source para ser inovador.

A verdadeira inovação vem da troca de ideias e do trabalho conjunto para solucionar problemas comuns. É exatamente isso que o open source desenvolvido em parceria com as comunidades oferece. É aí que o Red Hat Open Innovation Labs entra em cena. Proporcione à sua equipe uma experiência imersiva de residência intensiva e altamente especializada para turmas de três a seis desenvolvedores. O objetivo é aprender como criar aplicações conectadas por APIs do jeito Red Hat.

Veja o ebook do Open Innovation Labs
Parece que estamos contando vantagem? Você não precisa aceitar apenas o que dizemos.
Veja alguns casos reais do setor de aviação. Saiba como uma solução de API eficaz torna tudo mais ágil, eficiente e escalável.

## Jenkins File com Open Shift

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }

        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }

        stage('Deploy to OpenShift') {
            steps {
                script {
                    openshift.withCluster('https://CLUSTER_URL') {
                        openshift.withProject('meu-projeto-spring-boot') {
                            def app = openshift.newApp('java:17', '--name=minha-aplicacao', '.')
                            app.deploy()
                        }
                    }
                }
            }
        }
    }
}

##

mvn io.quarkus:quarkus-maven-plugin:1.13.2.Final:create \
    -DprojectGroupId=org.acme \
    -DprojectArtifactId=getting-started \
    -DclassName="org.acme.getting.started.GreetingResource" \
    -Dpath="/hello"
cd getting-started


package org.acme.getting.started;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("/hello")
public class GreetingResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        return "Hello";
    }
}

java -jar target/quarkus-app/quarkus-run.jar

# 
var consumerConfig = new ConsumerConfig
{
    GroupId = "test-group",
    BootstrapServers = "localhost:9092",
    AutoOffsetReset = AutoOffsetReset.Earliest
};

using var consumer = new ConsumerBuilder<Ignore, string>(consumerConfig).Build();
consumer.Subscribe("test-topic");

CancellationTokenSource cts = new CancellationTokenSource();
Console.CancelKeyPress += (_, e) => {
    e.Cancel = true;
    cts.Cancel();
};

try
{
    while (true)
    {
        var consumeResult = consumer.Consume(cts.Token);
        Console.WriteLine($"Message: {consumeResult.Message.Value} received from {consumeResult.TopicPartitionOffset}");
    }
}
catch (OperationCanceledException)
{
    // Ctrl+C foi pressionado.
}
finally
{
    consumer.Close();
}




dotnet run



# Program.cs

using Confluent.Kafka;
using System;
using System.Threading.Tasks;

class Program
{
    public static async Task Main(string[] args)
    {
        var config = new ProducerConfig { BootstrapServers = "localhost:9092" };

        using var producer = new ProducerBuilder<Null, string>(config).Build();
        try
        {
            var result = await producer.ProduceAsync("test-topic", new Message<Null, string> { Value="Hello Kafka World!" });
            Console.WriteLine($"Delivered '{result.Value}' to '{result.TopicPartitionOffset}'");
        }
        catch (ProduceException<Null, string> e)
        {
            Console.WriteLine($"Delivery failed: {e.Error.Reason}");
        }
    }
}

 
 
 OpenShift Console: O OpenShift Console é uma interface gráfica de usuário que permite aos desenvolvedores gerenciar aplicativos e recursos do OpenShift.
O OpenShift CLI: O OpenShift CLI é uma ferramenta de linha de comando que permite aos desenvolvedores interagir com o OpenShift.
O OpenShift SDK: O OpenShift SDK é um conjunto de bibliotecas que permite aos desenvolvedores criar aplicativos para o OpenShift.

#Quarkus 

curl --header "Content-Type: application/json" \
--request POST \
--data '{"title":"The Shawshank Redemption","year":1994}' \
http://localhost:8080/movies

curl --header "Content-Type: application/json" \
--request POST \
--data '{"title":"The Godfather","year":1972}' \
http://localhost:8080/movies

curl --header "Content-Type: application/json" \
--request POST \
--data '{"title":"The Dark Knight","year":2008}' \
http://localhost:8080/movies

curl --header "Content-Type: application/json" \
--request POST \
--data '{"title":"12 Angry Men","year":1957}' \
http://localhost:8080/movies



mvn package -Pnative

dotnet add package Confluent.Kafka

using Confluent.Kafka;
using System;
using System.Threading.Tasks;

class Program
{
    public static async Task Main(string[] args)
    {
        var config = new ProducerConfig { BootstrapServers = "localhost:9092" };

        using var producer = new ProducerBuilder<Null, string>(config).Build();
        try
        {
            var result = await producer.ProduceAsync("test-topic", new Message<Null, string> { Value="Hello Kafka World!" });
            Console.WriteLine($"Delivered '{result.Value}' to '{result.TopicPartitionOffset}'");
        }
        catch (ProduceException<Null, string> e)
        {
            Console.WriteLine($"Delivery failed: {e.Error.Reason}");
        }
    }
}

# 
var consumerConfig = new ConsumerConfig
{
    GroupId = "test-group",
    BootstrapServers = "localhost:9092",
    AutoOffsetReset = AutoOffsetReset.Earliest
};

using var consumer = new ConsumerBuilder<Ignore, string>(consumerConfig).Build();
consumer.Subscribe("test-topic");

CancellationTokenSource cts = new CancellationTokenSource();
Console.CancelKeyPress += (_, e) => {
    e.Cancel = true;
    cts.Cancel();
};

try
{
    while (true)
    {
        var consumeResult = consumer.Consume(cts.Token);
        Console.WriteLine($"Message: {consumeResult.Message.Value} received from {consumeResult.TopicPartitionOffset}");
    }
}
catch (OperationCanceledException)
{
    // Ctrl+C foi pressionado.
}
finally
{
    consumer.Close();
}



#
var consumerConfig = new ConsumerConfig
{
    GroupId = "test-group",
    BootstrapServers = "localhost:9092",
    AutoOffsetReset = AutoOffsetReset.Earliest
};

using var consumer = new ConsumerBuilder<Ignore, string>(consumerConfig).Build();
consumer.Subscribe("test-topic");

CancellationTokenSource cts = new CancellationTokenSource();
Console.CancelKeyPress += (_, e) => {
    e.Cancel = true;
    cts.Cancel();
};

try
{
    while (true)
    {
        var consumeResult = consumer.Consume(cts.Token);
        Console.WriteLine($"Message: {consumeResult.Message.Value} received from {consumeResult.TopicPartitionOffset}");
    }
}
catch (OperationCanceledException)
{
    // Ctrl+C foi pressionado.
}
finally
{
    consumer.Close();
}

# Open Shift

OpenShift, uma plataforma de contêineres baseada no Kubernetes desenvolvida pela Red Hat, oferece diferentes soluções que podem ser enquadradas em modelos de serviço como PaaS (Platform as a Service) e IaaS (Infrastructure as a Service), além de uma interface de usuário como a OpenShift Console. Vamos detalhar cada uma dessas soluções:

### 1. OpenShift como PaaS (Platform as a Service)
Descrição: No modelo PaaS, OpenShift fornece uma plataforma de desenvolvimento e implantação de aplicações em contêineres. Ele abstrai a infraestrutura subjacente, permitindo que os desenvolvedores se concentrem no código e na lógica de negócios, sem se preocuparem com a gestão da infraestrutura.
Características:
Gerenciamento automático de recursos, como escalonamento, balanceamento de carga, e gerenciamento de saúde.
Integração com ferramentas de CI/CD para automação do processo de desenvolvimento e implantação.
Suporte a uma variedade de linguagens de programação e frameworks.
Uso: Ideal para desenvolvedores e equipes que desejam se concentrar no desenvolvimento de aplicações sem a complexidade de gerenciar a infraestrutura.
### 2. OpenShift em um Ambiente IaaS (Infrastructure as a Service)
Descrição: Quando implantado em uma infraestrutura IaaS, o OpenShift opera em cima de uma infraestrutura de nuvem fornecida por serviços como AWS, Azure, Google Cloud ou em um ambiente de nuvem privada.
Características:
Os usuários têm controle sobre a infraestrutura subjacente, incluindo configurações de rede, armazenamento e computação.
Flexibilidade para personalizar o ambiente de acordo com necessidades específicas, como conformidade regulatória ou requisitos de desempenho.
Gestão de custos com base no uso da infraestrutura.
Uso: Adequado para organizações que necessitam de controle detalhado sobre sua infraestrutura ou que têm requisitos específicos que não podem ser atendidos em um modelo PaaS puro.
### 3. OpenShift Console
Descrição: A OpenShift Console é uma interface gráfica de usuário que facilita a interação com o cluster OpenShift. Ela fornece uma visão geral do estado do cluster, aplicações implantadas, recursos de rede, armazenamento, entre outros.
Características:
Interface intuitiva e fácil de usar, tornando acessível para usuários que não estão familiarizados com a linha de comando.
Permite realizar muitas tarefas administrativas e de desenvolvimento, como criar projetos, implantar aplicações, monitorar recursos e configurar aspectos de segurança.
Visualização gráfica de recursos e métricas, facilitando o gerenciamento e o monitoramento do cluster e das aplicações.
Uso: Ideal para administradores de sistemas, desenvolvedores e outros stakeholders que precisam gerenciar e monitorar aplicações e serviços no OpenShift.
Cada uma dessas soluções oferece diferentes níveis de controle, flexibilidade e facilidade de uso, permitindo que organizações de diferentes tamanhos e com diferentes necessidades técnicas tirem proveito da plataforma OpenShift de maneiras que melhor atendam aos seus requisitos.

## Rede CDN
Substituir uma Rede de Distribuição de Conteúdo (CDN) em uma rede pode ser um desafio, pois as CDNs são projetadas especificamente para otimizar a entrega de conteúdo em larga escala e reduzir a latência. No entanto, existem algumas alternativas e estratégias que você pode considerar, dependendo de seus requisitos específicos e da estrutura da sua rede:

## 1. Otimização de Conteúdo na Origem
Descrição: Melhorar a eficiência do servidor de origem, otimizando o conteúdo que está sendo servido. Isso inclui compactação de arquivos, minificação de CSS e JavaScript, e otimização de imagens.
Aplicação: Útil para sites com tráfego menor ou focado em regiões geográficas específicas.
## 2. Servidores de Cache Distribuídos
Descrição: Configurar seus próprios servidores de cache em locais estratégicos. Isso é semelhante ao que uma CDN faz, mas requer mais gerenciamento.
Aplicação: Pode ser eficaz para empresas com uma base de usuários concentrada geograficamente.
## 3. Balanceamento de Carga Geográfico
Descrição: Usar balanceadores de carga para distribuir o tráfego de forma eficiente entre vários servidores ou centros de dados.
Aplicação: Eficiente para distribuir solicitações uniformemente e melhorar a disponibilidade.
## 4. Redes Peer-to-Peer (P2P)
Descrição: Distribuir conteúdo usando uma rede peer-to-peer, onde os usuários finais fornecem parte do conteúdo uns aos outros.
Aplicação: Mais comum para distribuição de arquivos grandes ou streaming de mídia, como usado por alguns serviços de vídeo.
## 5. Armazenamento em Cache do Navegador
Descrição: Otimizar o uso do cache do navegador para garantir que os recursos estáticos sejam armazenados localmente pelos usuários após a primeira visita.
Aplicação: Útil para melhorar tempos de carregamento em visitas subsequentes ao seu site.
## 6. Serviços de Nuvem com Presença Global
Descrição: Utilizar serviços de nuvem que tenham uma presença global para hospedar seu aplicativo ou site.
Aplicação: Pode melhorar o desempenho para usuários em diferentes regiões, mas pode não ser tão eficaz quanto uma CDN tradicional.
7. Otimização de Protocolos de Rede
## Descrição: Implementar tecnologias como HTTP/2, QUIC ou TLS 1.3 para otimizar a entrega de conteúdo.
### Aplicação: Pode melhorar o desempenho de carregamento e a eficiência da entrega de conteúdo.
### Considerações Importantes
### Custo vs. Benefício: Criar e gerenciar sua própria rede de entrega de conteúdo pode ser mais caro e complexo do que usar uma CDN existente.
### Complexidade Técnica: Gerenciar servidores de cache, balanceamento de carga e otimização de conteúdo requer conhecimento técnico especializado.
### Escalabilidade: As CDNs são projetadas para escalabilidade fácil, algo que pode ser mais desafiador de replicar em uma solução interna.
### Em resumo, enquanto é possível criar alternativas para uma CDN usando uma combinação de otimizações na origem, cache distribuído e outras técnicas, essas abordagens geralmente envolvem trade-offs em termos de complexidade, custo e eficácia. Para muitas organizações, usar uma CDN existente continua sendo a solução mais prática e eficiente para entrega de conteúdo em larga escala.

## OPENSHIFT

### O OpenShift Developer Tools: O OpenShift Developer Tools é um conjunto de ferramentas que ajudam os desenvolvedores a criar, implantar e gerenciar aplicativos no OpenShift.
### O OpenShift Learning Center: O OpenShift Learning Center oferece recursos de treinamento e documentação para ajudar os desenvolvedores a aprender sobre o OpenShift.
### A comunidade OpenShift: A comunidade OpenShift é um recurso valioso para desenvolvedores que buscam ajuda e suporte.

##

import rx
from rx import operators as ops

# Criar um observable que emite números de 1 a 5
observable = rx.from_iterable([1, 2, 3, 4, 5])

# Definir uma função que será executada quando o observable emitir um valor
def on_next(x):
    print(f"Recebeu: {x}")

# Inscrever um observador no observable
observable.pipe(
    ops.map(lambda x: x * x),  # Multiplica cada elemento por ele mesmo
).subscribe(on_next)

## Quarkus

./gradlew --console=plain quarkusDev