wiki

Platform Engineering

Revisão de 12h49min de 14 de agosto de 2024 por Henrique Bastos (discussão | contribs)

Fase I - Estudo


Título da Ideia

Platform Engineering

Objetivos

  • Analisar o modelo de desenvolvimento e operações proposto no Platform Engineering, suas principais diferenças com os modelos atuais, assim como suas vantagens e desvantagens para um modelo de negócios.
  • Participar de comunidades e fóruns do Platform Engineering, conhecendo pessoas e empresas que façam parte desse sistema, possibilitando futuras parcerias (intelectuais ou comerciais).
  • Estar a par de novas tecnologias e meio digitais inovadores.


Conceito



"Platform Engineering" é um campo emergente no desenvolvimento de software que se concentra na construção e manutenção de plataformas tecnológicas que suportam o desenvolvimento, a implementação e a operação de aplicações. A ideia central é fornecer uma infraestrutura consistente, eficiente e reutilizável, permitindo que as equipes de desenvolvimento se concentrem nos aspectos específicos de seus projetos, em vez de se preocupar com a configuração e manutenção da infraestrutura subjacente.

Platform Engineering envolve a criação de uma infraestrutura robusta e reutilizável, que facilita o desenvolvimento e a operação de software de maneira eficiente e segura. Isso permite que as equipes de desenvolvimento se concentrem na entrega de valor de negócio, evitando a duplicação de esforços e otimizando recursos. Além disso, promove a padronização de processos, a automação de tarefas repetitivas e a integração contínua de novas tecnologias, assegurando que o ambiente de desenvolvimento seja ágil e escalável.

Em resumo, Platform Engineering capacita as organizações a inovar e entregar produtos de alta qualidade mais rapidamente, ao mesmo tempo em que reduz a complexidade e aumenta a confiabilidade da infraestrutura tecnológica.



Segundo muitas das palestras e dos vídeos de interação com os especialistas, o Platform Engineering, embora seja interessante para todo tipo de empresa que tem uma relação de DevOps, ele é muito mais atraente, e resulta em impactos maiores quando aplicado em níveis de média e grande escala.

Outro conceito interessante de trabalharmos é o de CI/CD, isto é, Continuous Integration/Continuous Deployment ou Continuous Delivery. O CI/CD é uma abordagem de automação no desenvolvimento de software que visa acelerar o processo de entrega de aplicações, garantindo qualidade e confiabilidade. A ideia central do CI/CD é integrar mudanças de código de forma contínua e automática, realizar testes automatizados e, em seguida, implantar as atualizações em um ambiente de produção ou de teste. Isso permite que as equipes de desenvolvimento entreguem novos recursos e correções de bugs de forma rápida e eficiente.

Continuous Integration (CI)

  • Definição: Prática de integrar mudanças de código de todos os desenvolvedores em um repositório compartilhado várias vezes ao dia.
  • Objetivo: Detectar e corrigir erros rapidamente, melhorar a qualidade do software e reduzir o tempo de integração.
  • Ferramentas Comuns: Jenkins, Travis CI, GitLab CI, CircleCI.

Continuous Deployment (CD)

  • Definição: Processo de implantar automaticamente cada mudança que passa pelos testes automatizados em um ambiente de produção.
  • Objetivo: Reduzir o tempo de entrega de novas funcionalidades para os usuários finais.
  • Ferramentas Comuns: Spinnaker, Jenkins, GitLab CI, CircleCI.

Continuous Delivery (CD)

  • Definição: Similar ao Continuous Deployment, mas com uma etapa manual de aprovação antes da implantação em produção.
  • Objetivo: Manter a capacidade de entregar o software a qualquer momento com um processo de liberação previsível e de alta qualidade.
  • Ferramentas Comuns: Ansible, Chef, Puppet, AWS CodePipeline.


Características 


Para entender melhor os conceitos e características da estrutura e capacidade do Platform Engineering, é importante fazermos uma subdivisão dos processos presentes na sua estrutura e em suas ferramentas: Platform Engineering Tooling Explanation

Estudo de caso da Humanitec Humanitec e serviços



Relatório AWS Resumo

Recursos:

158 total = 127 fora de compliance e 31 em compliance

1° ponto de alteração => recursos de rede (Network) que estão fora do compliance e que estão classificados como Alto Risco, depois médio e dps baixo.

  • Entre os de alto risco, foco nos "Security Groups", uma vez que todos estão fora do compliance. - Estão permissivos demais, não há restrições de acesso ou portas de acesso. Podem ser editados ou excluídos.
  • Processo similar com os "Security groups defaults", porém no caso eles devem ser editados e não são passiveis de serem deletados
  • os AWS Network ACLs ( colocar aqui oq é ACLs ) estão de maneira similar, todos fora do compliance e de alto risco. Alterar as portas de entradas para receberem apenas IPs confiáveis ou excluir caso n sejam utilizadas.
  • no caso do AWS VPC, todas também estão fora do compliance, porém foram classificadas apenas como "médio risco". O VCP flow logs não está habilitade, e a conta está chegando no limite regional de VCP Private Gateways.
  • Criar VPCs próprias e não usar as VPCs Default, é uma das boas praticas descritas no AWS
  • AWS Network Interface, todos estão em compliance.
  • No Storage, 21 dos 24 recursos estão fora do compliance, sendo todos esses classificados como risco médio. Eles são divididos em 7 tipos, S3, EBS Snapshot, EBS Volume, RDS Snapshot, RDS, RDS Cluster Snapshot. - No caso dos recursos a grande questão é a segurança deles, pois muitos necessitam da criação de uma criptografia e melhorar a segurança dos acessos, seja limitando acessos via HTTP e definindo para apenas HTTPS.
  • Já o recurso "Compute", todos os 12 estão fora de compliance, sendo 11 de alto risco (do tipo EC2) e 1 de médio risco (AMI). Os EC2 tem alguns problemas de segurança, como o acesso por diversas portas, a não alteração dos VCPs default por VCPs proprios (como dito anteriormente), não usam o IAM instance roles e imdsv1 precisa ser atualizado para uma versão mais atual. Já no caso do AMI é apenas um problema de falta de criptografia.
  • AWS IAM Policy, o Brain possui 2 IAM policy e ambas estão fora de compliance, pois não seguem o padrão de privilégios mínimos. É necessário adequar essas "policies" para o "least privilegie".
  • AWS Regions, tem 17 AWS reagions no Brain, todos foram de compliance, sendo 16 de baixo risco e 1 de risco médio. Foi identificado que o AWS config não está ativado nas regiões, que o access analyzer também não está ativado, e que na região ap-northeast-3 está quase chegando no limite de instâncias EC2.
  • CloudTrail, 1 recurso fora do compliance e de médio risco. O problema é que este não esta integrado com o CloudWatch, há também um alerta para a necessidade de se criptografar alguns dados, assim como a exclusão do "bucket".
  • AWS Account, 1 recurso fora do compliance e de baixo risco. O cloudfront CDN não está sendo utilizado.
  • AWS User, temos 22 users, todos fora do compliance e de risco médio. Existem diversos problemas, desde a não inclusão de um fator de autenticação múltiplo, a chaves que não são atualizada, users com acesso além do ideal e a necessidade de revisar as IAM policies. Dentre as diversas soluções, temos: Habilitar o MFA, Remover chaves não utilizadas e/ou não rotacionadas, desabilitar usuários com acesso multi-modo e remover usuários inativos, remover policies associadas a usuário e remover papel que dá acesso total ao ECR.
  • AWS IAM, 1 recurso com 12 incidentes de médio risco. Este também não está com o MFA ativo e é necessário reforçar a política de senhas, que não é forte o suficiente, e deve ser atribuído um administrador.
  • AWS KMS, 2 recursos, ambos fora de compliance e de risco médio. Foi identificado que não está habilitado a rotação para as cmks criadas por clientes. A rotação das chaves é necessária para ajudar na redução do potencial impacto de uma chave comprometida.

Conclusão

Concluindo a avaliação abrangente da conta da AWS da Algar brain VM, é evidente que existem aspectos em que a conformidade com as melhores práticas pode ser otimizada. A análise minuciosa dos diversos recursos revelou algumas áreas que requerem atenção imediata para garantir a segurança, eficiência e conformidade com as políticas estabelecidas. Recomenda-se uma revisão abrangente dos recursos apresentados nesse relatório. As sugestões delineadas ao longo deste relatório são fundamentais para fortalecer a postura de segurança, otimizar custos e alinhar as operações com as normas recomendadas. Diante disso, instamos a implementação diligente das sugestões fornecidas para garantir um ambiente AWS robusto e em total conformidade. Oportunidades para aprimoramento foram identificadas, e a execução das recomendações contribuirá significativamente para a eficiência operacional e a segurança da nossa infraestrutura na nuvem. Agradecemos pela colaboração e permanecemos à disposição para quaisquer esclarecimentos adicionais.

Solicitação de Informações sobre a Aplicação do SOM para Implementação de Platform Engineering

Curso: AWS, Kubernetes, DevOps e microsserviços - Henrique Bastos


Estudo Dirigido


Conhecendo Platform Engineering (Evento PlatformCON)

Empresas de Plataform Engineering


Fase II - Ensino


Conteúdo

Desenvolva um conteúdo que possa transmitir o conhecimento adquirido para outros
Crie um material (Wiki, PDF, PPT, ...) que possa ser armazenado e facilmente atualizável


Apresentação

Apresente ao grupo (reunião, EAD, Blog, ...)
Publique aqui


Metodologia


Descrevas as metodologias usadas. Alguns exemplos:

Estratégia de Job Rotation
Estudos básicos para conhecimento do potencial
Estudos básicos para entendimento sobre o problema
Estudos para dar base aos pesquisadores
Benchmarking com empresas estrangeiras 
Aceleradoras de empresas
Adoção de novas tecnologias
Utilização da proposta de soluções Open-source
Priorização no desenvolvimento interno
Foco na não dependência de fornecedores
Prática de formação dos talentos necessários


Hipóteses


 Que questões envolvem a pesquisa? 
O que se espera provar?
O que se espera como resultado?
Explicações e argumentos que subsidiem a investigação em curso


Fase III - Exemplo de Caso de Negócio


Product Backlog


Descreva os requisitos deste projeto


Benefícios para quem for oferecer esta solução

    Descrever em tópicos os benefícios que uma pessoa ou uma empresa podem obter: ganhos, receitas, novos negócios, novos produtos, novas parcerias



Benefícios para o usuário

    Descrever em tópicos os benefícios para os usuários desta solução.
    Pode se inspirar no Canvas.


Direcionadores chave para esta iniciativa

    Descrever em tópicos o que esta iniciativa pode proporcionar



Possíveis modelos de negócios

    Descrever em tópicos os possíveis modelos de negócios

Business Case

    Descrever um exemplo de negócio que permita avaliar a solução comercialmente


Alinhamento com Lei do Bem


  • Projeto possui algum elemento tecnologicamente novo ou inovador?
Elemento tecnologicamente novo ou inovador pode ser entendimento como o avanço tecnológico pretendido pelo projeto, ou a hipótese que está sendo testada


  • Projeto possui barreira ou desafio tecnológico superável?
Barreira ou desafio tecnológico superável pode ser entendido como aquilo que dificulta o atingimento do avanço tecnológico pretendido, ou dificulta a comprovação da hipótese


  • Projeto utiliza metodologia/método para superação da barreira ou desafio tecnológico?
Metodologia/método para superação da barreira ou desafio tecnológico pode ser entendido como aqueles atividades que foram realizadas para superação da barreira ou do desafio tecnológico existente no projeto


  • Projeto é desenvolvido em parceira com alguma instituição acadêmica, ICT ou startup?
Se sim, o desenvolvimento tecnológico é executado por associado ou por alguma empresa terceira? qual o nome da empresa? 
Anexar cópia do contrato


Fase IV - Protótipo orientado ao Negócio


Escopo


Explique o escopo deste protótipo


Limitações


Informe sobre as limitações técnicas, comerciais, operacionais, recursos, etc.


PoC


Desenvolva um PoC (Proof of Concept)


Privacidade (LGPD)


  • Avaliar condições referentes à Lei Geral de Proteção de Dados


Detalhamento Técnico


Descreva especificamente os aspectos técnicos desta pesquisa





Cronograma Macro


Histórico

Responsável: Lucas Gomes

Semana de 17 à 21/06/2024

  • Reunião de Kickoff com Lucas e Bruno da Sunny Systems, Vanius (Especialista da Algar Telecom), e Luiz Claúdio e Lucas da Brain.
    • Vanius fez uma breve apresentação de como é o funcionamento atual na Algar Telecom. O principal problema encontrado é que durante a transição para o Cloud não houve uma adaptação do método On Premise, que não é o ideal para o pós transição
    • Lucas Guimarães apresenta algumas soluções possíveis mais a principal "resposta" é referente a Humanitec, empresa que trabalha nessa área e que irá fazer uma 2° reunião para a apresentação na quinta-feira 20/06/2024. Como Vanius havia dito que a Algar já tem algumas ferramentas próprias desenvolvidas, Lucas disse que elas podem ser aproveitadas nesse novo projeto, para melhor adaptação as necessidades da Algar Telecom
    • Também foi exposto que terá uma conferencia na próxima semana em Nova Iorque que irá trazer bastante novidades e novas tecnologias para a área, como o Data Dog.


  • Reunião com a Humanetic, SunnySystem, Vanius e Convidados
    • Breve apresentação das funções realizadas na Humanetic e como funciona o Platform Engineering
    • Deixou em aberto para uma nova reunião na próxima semana para a apresentação de um caso de uso deles e ver a adequação a um caso de uso real da Algar Telecom

Semana de 22 à 29/06/2024

  • Upload de infos na Wiki e criação de um plano de estudos
  • Reunião de retorno marcada com a Humanitec no dia 09/07

Semana de 08 à 12/07/2024



Pesquisadores

  • Henrique Cabral Bastos
  • Lucas Resende Gomes
  • Vanius Silva de Oliveira


Disponível em “http://3.143.69.156/wiki/index.php?title=Platform_Engineering&oldid=92159”