Cloud IaC AWS Azure GCP

• Governança em Cloud Muitas empresas têm problemas ou dúvidas em como fazer o controle dos acessos nos ambientes e acabam gastando muito dinheiro provisionando clusters e contas para diferentes times dentro da mesma empresa. Na 4Linux temos scripts em Terraform que fazem o controle de acessos utilizando LDAP e RBAC, onde times podem utilizar o mesmo cluster de Kubernetes, porém de forma isolada onde um time um não tem acesso ao cluster do outro time.
• Kubernetes e Terraform O Kubernetes é atualmente a melhor plataforma para fazer o deploy de aplicações. Utilizando a tecnologia de Containers e possível trazer ambientes legados ‘do jeito que eles são’, para a Cloud e utilizar os recursos de escalabilidade e alta disponibilidade. Frequentemente esta ação é feita em conjunto com o Terraform que faz o provisionamento da infraestrutura, para garantir que ao rodar um workflow todo o ambiente poderá ser replicado em todas as Clouds (AWS, GCP, Azure). Este provisionamento pelo Terraform lhe dá uma grande flexibilidade de uso e também para migrações futuras.
• DevOps as a Service. A 4Linux é pioneira na implementação de pipeline DevOps e com experiência em grandes empresas. DevOps e Cloud tem uma grande sinergia. Oferecemos processos e controles para provisionar e gerenciar ambientes em Cloud (AWS, GCP e Azure), utilizando pipelines e infraestrutura como código (IaC) de maneira que possa ser replicado e reutilizados em todos os ambientes e para outras equipes dentro da mesma empresa.
• Internal Developer Platform (IDP) Devido à complexidade de se gerenciar muitos serviços na Cloud, Controle de Billing e Governança, é uma prática comum criar-se uma plataforma interna onde os desenvolvedores podem criar a infraestrutura que eles precisam para MVPs, PoCs e novos projetos, seguindo um workflow pré-definido e evitando com que se tenham serviços órfãos na Cloud, que são aqueles que são pagos e sem uso.
• DataOps Com a praticidade da Cloud, podemos fazer o provisionamento e controle de uma Data Platform, disponibilizando DataLakes, Workflow managers, Databases, Keyvaults e etc. Todos interconectados a partir do provisionamento e prontos para serem usados pela equipe de dados.

Veja abaixo três exemplos de arquiteturas para diferentes necessidades que podemos implementar em ambientes Cloud (GCP, Azure, AWS).

Pipeline de Aplicação na GCP com Cloud Run

Este é um exemplo simples de Pipeline para um time pequeno que não precisa utilizar todos os recursos do Kubernetes, mas ainda sim precisa rodar a aplicação em containers na Cloud, com escalabilidade e versionamento. O Cloud Run é uma plataforma que permite executar contêineres chamados por meio de solicitações ou eventos. O Cloud Run é serverless: ele abstrai todo o gerenciamento da infraestrutura.

Nesse workflow, as pipelines são gerenciadas pelo Github Actions, onde nele a equipe de DevOps pode definir qual será o Cloud run que será utilizado, o Cloud Storage é onde as imagens do Docker serão armazenadas assim como os objetos utilizados pela aplicação (imagens, documentos, objetos) Nenhum desenvolvedor tem acesso aos ambientes de produção ou as senhas, uma vez que todas elas estarão armazenadas dentro do serviço Secret Manager.

Provisionando uma Data Platform na Azure

Nesse exemplo temos o DataOps engineer, que provisionará todos os recursos necessários na Cloud para a criação de uma DataPlatform, inclusive o controle de acessos.

O DataEngineer terá acesso ao Azure DataFactory com acesso ao DataLake (Storage Account ADLS Gen2), que disponilizará esses dados transformados e limpos para o DataScientist.

O DataScientist utilizará serviços como o Azure MachineLearning para gerar os modelos de dados e o Azure Synapse para criar Spark notebooks que podem ser utilizados para fazer a exploração desses dados.

Kubernetes na AWS para diferentes equipes separados por namespace e controlados por RBAC

Nesse exemplo temos um servico EKS simples, onde o objetivo é mostrar que podemos ter o mesmo cluster compartilhado por vários times; onde cada time (MVP, POC, Website), tem um Namespace dentro do Cluster e eles não tem acesso aos outros namespaces, onde o controle e feito através de RBAC (Role Based Access Control)