#aula1

[lucasrfsblog]

Arquitetura Datalake: Extraindo Valor dos Dados – Aula 1

Arquitetura Datalake: Extraindo Valor dos Dados – Aula 1 – Parte 1

 Professor:  Sergio Nauffal

EP 01. De ontem para hoje

Conteudo:

 Qual é o novo nexo da força?

 É a facilidade e disponibilidade da informação, é a facilidade de criar conexão entre os indivíduos que residem em diferente geolocalização.            

 Nexo: Ligação entre uma ou varias coisas – União.

Vinculo, conexão entre circunstancias, acontecimentos, opiniões: Faltou nexo, coerência, neste seu discurso.

 “Devemos conhecer o passado para lucrar com suas lições.”

 [Referencias]

  [Resumo]

  Arquitetura Datalake: Extraindo Valor dos Dados – Aula 1 – Parte 2

 Professor:  Sergio Nauffal

EP 02. Big data

Conteudo:

 Introdução ao big data:

 O datalake é parte integrante do big data.

 “Eu considero o big data a melhor ferramenta de analise para a sua empresa.”

 Se você interpretar e colocar a sua empresa para trabalhar orientada a dados (Data Driven), você levará sua empresa a um patamar mais avançado e interconectado com os seus clientes, colaboradores e resultados.

 Resumo geral:

 Conceito: Big data é a área do conhecimento que estuda como tratar, analisar e obter informações sobre um conjunto de dados grandes de mais para serem analisados por sistemas tradicionais.

Para integrante que correlaciona com a data Science ou ciência de dados.

  Entender os problemas:

1-      Coletar e analisar dados grandes volumes de dados em alta velocidade. (A velocidade é um requisito e ela vai impactar os resultados)

2-      Precisamos ter um motor de busca eficiente. (Algum mecanismo para conseguir trazer o dado que são necessários sem desprender grande volume de tempo procurando).

3-      Inteligência de máquina.  A maquina precisa entender o que você quer.

4-      Motor de inferência? O Nucleo da inteligência artificial de um sistema especialista, onde a capacidade do motor de inferência é baseada em uma combinação de procedimentos e raciocínios de forma regressiva.

Existem duas características mais marcantes em big data:

 1-      São a interrelação entre os dois motores o de busca e o de inferência.

 Quais são as principais diferenças entre o Data warehouse e data lake:

 Data warehouse: É uma base de dados de contexto dados preparados, organizados e limpos. Neste ambiente os dados estão bem estruturados, catalogados e já trazem grande volume de informações.

 Data lake: Neste caso a disponibilização dos dados esta em seu formato bruto, sem catalogação ou qualquer tipo de organização que permita o acesso de informações de maneira simples ou sem qualquer trabalho de limpeza dos dados prévio.

 Desta forma, por que o data lake é mais interessante que o data warehouse?

 Depende do contexto, mas em geral, os data warehouse cobrem um conjunto de cenários que foram definidos em algum momento no passado, enquanto os data lakes, possuem toda estrutura necessária para quaisquer correlações de dados e trazer cenários novos de analise de dados que podem trazer maior valor para as empresas. Com os data lakes e outras ferramentas de ciência de dados ou analise de dados, conseguimos criar novos produtos de dados e até mesmo orientar tomada de decisões executivas.

Um esquema básico para funcionamento de um big data seria o seguinte:

 1-      Entrada de dados, de todas as formas possíveis.

2-      Organização dos dados. (Limpeza e preparação)

3-      Analise. (Uso de ML para fazer a analise de padrão de dados e trazer informação)

4-      Consumo dos dados por aplicações na ponta. (Dashboards, aplicações e até mesmo automações) que serão alimentados por estes dados.

 Escada da inteligência artificial.

 Fluxo de camadas.

 Objetivo de estudo:

 Um dos objetivos é criar produtos de dados que possam ser utilizados para tomada de decisão, em mecanismos de automação e até mesmo como produtos como os mecanismos de sugestão de conteúdo ou produtos.

Qual o publico alvo envolvido com big data?

 Ferramentas:

 Para o uso de big data, existem 4 grandes grupos de ferramentas que devem ser considerados:

1-      Armazenamento e Streaming.

2-      Pipeline dos dados. (Criação do fluxo que os dados irão percorrer até se tornarem produtos)

3-      Visualização dos dados. (Camada de apresentação os resultados obtidos

Kibana: Otima ferramenta para visualização dos dados em forma de dashboards.

Grafana:

 4-      Camada de Machine learning e criação de modelos.

  Quais são as tendencias de mercado?

 Uma das tendencia de mercado que o data lake controla são custos.

 Uso de cloud.

 Diagrama de processos e como implementar big data na empresa?

  [Resumo]

[lucasrfsblog]

Arquitetura de Microsserviços e Microcontainer: O Negócio como Serviço (e Saiba Como Evitar as Armadilhas) – Aula 1

Arquitetura de Microsserviços e Microcontainer: O Negócio como Serviço (e Saiba Como Evitar as Armadilhas) – Aula 1 – Parte 1

 Professor:  Giovane Moura

EP 01. Conceitos

Conteudo:

 Conceitos:

 Monilito: É uma aplicação onde toda a codificação esta em apenas um lugar, concentrada.

 Aplicação de 3 camadas: Dividida em 3 camadas, apresentação, aplicação (APIs) e data tier (camada de dados).

 Acoplamento com a base de dados: Aplicações monilitas geralmente estão fortemente acopladas a uma base de dados.

 “Não basta apenas criar uma aplicação. Precisamos conquistar os usuários e mante-los ativos na plataforma.”

 [O que é confiabilidade para você?]

 Confiabilidade é um termo relacionado a confiança. Confiar que algo vai acontecer de acordo com o esperado ou combinado.

 Professor: Segurança, disponibilidade, performance. “ Dependendo da pessoa que você perguntar do foco, do objetivo, ela vai ter, uma dor diferente, uma necessidade diferente.”

 RTO: Recovery time objective. Tempo de recuperação de um serviço.

RPO: Recovery point objective. Quanto eu aceito de perda para recuperação.

 Time to Market: Quanto tempo minha empresa leva para entregar uma feature ou aplicativo no mercado. (Desde a ideia até o go-live)

 [Resumo]

  Arquitetura de Microsserviços e Microcontainer: O Negócio como Serviço (e Saiba Como Evitar as Armadilhas) – Aula 1 – Parte 2

 Professor:  Giovane Moura

EP 02. Outras necessidades

Conteudo:

 Escalabilidade: Fazer crescer ou aumentar os recursos de forma horizontal ou vertical. (Scale out e scale up)

Resiliencia: Menos vulnerabilidades, neste cenário, não só segurança deve ser levado em pauta, mas tbm a continuidade do serviço ou aplicação.

Otimização: Pensar de forma a otimizar o uso dos recursos para que a menor fatia possível fique ociosa.

Alta Disponibilidade: Estar sempre ativo, com uma boa performance e sem taxas de erro.

Consistencia: Mesmo que toda a aplicação esteja distribuída para obter o melhor possível da escalabilidade, a aplicação precisa permanecer consistente.

 [Modernização de aplicação]

 É um conjunto de técnicas que vão ser utilizadas para orientar a conversão de um serviço legado em um modelo de serviços distribuídos e de microserviços. (Cloud Native)

 “Falando de nuvem acho que é mais fácil, né?. É só migrar e esta tudo certo. Não, não é bem assim...”

 Mensagem: Não adianta pensar só na parte computacional, só a parte técnica para trazer modernização para o legado e aplicações. É uma combinação de tudo, vale muito a questão de talentos, pessoas e cultura.

 [Tecnicas]

 1-      Desacoplamento de aplicação: Quebrar a aplicação em pedaços menor, de maneira que estas possam trabalhar de forma independentes e possam principalmente ser administradas e escalar de forma separada.

2-      Serviços gerenciados: Utilizar serviços gerenciados nos provedores de Cloud.

3-      Serverless: Empregar serverless que de fato vai tirar boa parte da complexidade de gerenciamento de infraestrutura e de certa forma, deixa o desenvolvedor mais focado no desenvolvimento de features.

4-      Portabilidade: É a habilidade de tornar sua aplicação executável em qualquer ambiente, de forma simples e consistente. (Containers?)

5-      DevOps: Que tem como objetivo automatizar a esteira de desenvolvimento, reduzir erros humanos, fazer releases mais leves e mais rápidos.

  [Desacoplar as aplicações]

 - Vantagens:

 1-      Simplifica a manutenção do código.

2-      Diminui a barreira da alteração.

3-      Fazer releases mais rápidos e mais leves.

4-      Suportar diferentes plataformas.

5-      Suportar diferentes linguagens.

  [Microserviço]

 Quando devo  a aplicação deve ser quebrada e virar um microserviço?

 1-      Reuso do serviço? Este serviço ou posso reutilizar em algum outro serviço?

Ex: Autenticação.

2-      Escalabilidade.

3-      Qual time vai gerenciar este microserviço futuramente.

 Exemplo:

 - GMAIL:  Atualmente o gmail é composto de vários microserviços.

 Com o uso de microserviços é possível atualizar pequenas partes do código que compõe a solução como um todo e mesmo se esta atualização falhar, o serviço continua disponível sem afetar os outros componentes (microserviços).

 - Base de dados: Com as técnicas de quebrar aplicações em microserviços, não é mais necessário ter uma base de dados gigante ou extremamente performática para todas as minhas aplicações. Neste cenário, cada microserviço tem a sua base de dados própria e os  serviços não conectam mais na base de dados central, elas se conectam na API dos microserviços.

 [SRE]

 SRE is what you get when you treat operations as if it’s a software problem. Our mission is to protect, provide for, and progress the software and systems behind all of Google’s public services — Google Search, Ads, Gmail, Android, YouTube, and App Engine, to name just a few — with an ever-watchful eye on their availability, latency, performance, and capacity.

 [Niveis de serviço]

 SLI: Indicador de nível de serviço.

 Qual é a métrica de nível de serviço?

 Error rating.

 SLO: Indicador de objetivo de nível de serviço.

 Com base nos indicadores de serviço que devem ser considerados, quais serão os níveis adequados?

  SLA: Acordo de nível de serviço.

 É o KPI de acordo para atender tanto SLI e SLO. Neste caso, apura-se se os indicadores de SLI foram atendidos de acordo como foi definido no SLO.

 Como um SRE implementa o DevOps:

 1-      Reduzir silos organizacionais:

Share ownership: Promover a cultura de compartilhamento de responsabilidade. Não existe apenas uma área responsável por um assunto, todos devem compartilhar as responsabilidades e colaborar com a resolução dos problemas.

A mensagem geral é: Compartilhar responsabilidades e senso de dono do negócio.

2-      Aceitar falhar como normal:

Não existe falha humana. Se um humano errou e causou uma falha é por que o sistema não estava preparado para aquele evento ou por que os acessos não estavam adequados e foi possível realizar aquela ação catastrófica.

Como implentar esta cultura:

               Blame-less posmorten: Investigar a causa raiz do erro sem apontar o dedo para possíveis culpados.

               Error budget: Com base nas definições do SLI/SLO, saber exatamente quanto tempo eu posso ter de indisponibilidade sem ferir o acordo do SLA.

               Changes gradual: Lançar versões novas de uma aplicação ou microserviço e não disponibilizar para todos os usuários antes de validar se esta totalmente funcional. Segregar uma pequena parte do trafego de acesso para esta validação. Desta forma, mesmo que ocorra uma quebra do serviço, apenas uma pequena parte dos usuários sera afetada e desta forma você consegue “esticar” o SLO para investigar e corrigir o que for pertinente para a nova release.

               Tooling e automation: Ferramentas e automação são essenciais para uma evolução do T.I e para trazer agilidade tanto no deploy quanto no rollback. O mundo perfeito é que ninguém coloque a mão no ambiente de produção.

               Medir tudo: Sair do monitoramento tradicional e ir para telemetria (Observability).

 [Resumo]

[lucasrfsblog]

Arquitetura de Microsserviços e Microcontainer: O Negócio como Serviço (e Saiba Como Evitar as Armadilhas)

Arquitetura de Microsserviços e Microcontainer: O Negócio como Serviço (e Saiba Como Evitar as Armadilhas) – Aula 1 – Parte 1

 Professor:  Giovane Moura

EP 01. Conceitos

Conteudo:

 Conceitos:

 Monilito: É uma aplicação onde toda a codificação esta em apenas um lugar, concentrada.

 Aplicação de 3 camadas: Dividida em 3 camadas, apresentação, aplicação (APIs) e data tier (camada de dados).

 Acoplamento com a base de dados: Aplicações monilitas geralmente estão fortemente acopladas a uma base de dados.

 “Não basta apenas criar uma aplicação. Precisamos conquistar os usuários e mante-los ativos na plataforma.”

 [O que é confiabilidade para você?]

 Confiabilidade é um termo relacionado a confiança. Confiar que algo vai acontecer de acordo com o esperado ou combinado.

 Professor: Segurança, disponibilidade, performance. “ Dependendo da pessoa que você perguntar do foco, do objetivo, ela vai ter, uma dor diferente, uma necessidade diferente.”

 RTO: Recovery time objective. Tempo de recuperação de um serviço.

RPO: Recovery point objective. Quanto eu aceito de perda para recuperação.

 Time to Market: Quanto tempo minha empresa leva para entregar uma feature ou aplicativo no mercado. (Desde a ideia até o go-live)

 [Resumo]

  Arquitetura de Microsserviços e Microcontainer: O Negócio como Serviço (e Saiba Como Evitar as Armadilhas) – Aula 1 – Parte 2

 Professor:  Giovane Moura

EP 02. Outras necessidades

Conteudo:

 Escalabilidade: Fazer crescer ou aumentar os recursos de forma horizontal ou vertical. (Scale out e scale up)

Resiliencia: Menos vulnerabilidades, neste cenário, não só segurança deve ser levado em pauta, mas tbm a continuidade do serviço ou aplicação.

Otimização: Pensar de forma a otimizar o uso dos recursos para que a menor fatia possível fique ociosa.

Alta Disponibilidade: Estar sempre ativo, com uma boa performance e sem taxas de erro.

Consistencia: Mesmo que toda a aplicação esteja distribuída para obter o melhor possível da escalabilidade, a aplicação precisa permanecer consistente.

 [Modernização de aplicação]

 É um conjunto de técnicas que vão ser utilizadas para orientar a conversão de um serviço legado em um modelo de serviços distribuídos e de microserviços. (Cloud Native)

 “Falando de nuvem acho que é mais fácil, né?. É só migrar e esta tudo certo. Não, não é bem assim...”

 Mensagem: Não adianta pensar só na parte computacional, só a parte técnica para trazer modernização para o legado e aplicações. É uma combinação de tudo, vale muito a questão de talentos, pessoas e cultura.

 [Tecnicas]

 1-      Desacoplamento de aplicação: Quebrar a aplicação em pedaços menor, de maneira que estas possam trabalhar de forma independentes e possam principalmente ser administradas e escalar de forma separada.

2-      Serviços gerenciados: Utilizar serviços gerenciados nos provedores de Cloud.

3-      Serverless: Empregar serverless que de fato vai tirar boa parte da complexidade de gerenciamento de infraestrutura e de certa forma, deixa o desenvolvedor mais focado no desenvolvimento de features.

4-      Portabilidade: É a habilidade de tornar sua aplicação executável em qualquer ambiente, de forma simples e consistente. (Containers?)

5-      DevOps: Que tem como objetivo automatizar a esteira de desenvolvimento, reduzir erros humanos, fazer releases mais leves e mais rápidos.

  [Desacoplar as aplicações]

 - Vantagens:

 1-      Simplifica a manutenção do código.

2-      Diminui a barreira da alteração.

3-      Fazer releases mais rápidos e mais leves.

4-      Suportar diferentes plataformas.

5-      Suportar diferentes linguagens.

  [Microserviço]

 Quando devo  a aplicação deve ser quebrada e virar um microserviço?

 1-      Reuso do serviço? Este serviço ou posso reutilizar em algum outro serviço?

Ex: Autenticação.

2-      Escalabilidade.

3-      Qual time vai gerenciar este microserviço futuramente.

 Exemplo:

 - GMAIL:  Atualmente o gmail é composto de vários microserviços.

 Com o uso de microserviços é possível atualizar pequenas partes do código que compõe a solução como um todo e mesmo se esta atualização falhar, o serviço continua disponível sem afetar os outros componentes (microserviços).

 - Base de dados: Com as técnicas de quebrar aplicações em microserviços, não é mais necessário ter uma base de dados gigante ou extremamente performática para todas as minhas aplicações. Neste cenário, cada microserviço tem a sua base de dados própria e os  serviços não conectam mais na base de dados central, elas se conectam na API dos microserviços.

 [SRE]

 SRE is what you get when you treat operations as if it’s a software problem. Our mission is to protect, provide for, and progress the software and systems behind all of Google’s public services — Google Search, Ads, Gmail, Android, YouTube, and App Engine, to name just a few — with an ever-watchful eye on their availability, latency, performance, and capacity.

 [Niveis de serviço]

 SLI: Indicador de nível de serviço.

 Qual é a métrica de nível de serviço?

 Error rating.

 SLO: Indicador de objetivo de nível de serviço.

 Com base nos indicadores de serviço que devem ser considerados, quais serão os níveis adequados?

  SLA: Acordo de nível de serviço.

 É o KPI de acordo para atender tanto SLI e SLO. Neste caso, apura-se se os indicadores de SLI foram atendidos de acordo como foi definido no SLO.

 Como um SRE implementa o DevOps:

 1-      Reduzir silos organizacionais:

Share ownership: Promover a cultura de compartilhamento de responsabilidade. Não existe apenas uma área responsável por um assunto, todos devem compartilhar as responsabilidades e colaborar com a resolução dos problemas.

A mensagem geral é: Compartilhar responsabilidades e senso de dono do negócio.

2-      Aceitar falhar como normal:

Não existe falha humana. Se um humano errou e causou uma falha é por que o sistema não estava preparado para aquele evento ou por que os acessos não estavam adequados e foi possível realizar aquela ação catastrófica.

Como implentar esta cultura:

               Blame-less posmorten: Investigar a causa raiz do erro sem apontar o dedo para possíveis culpados.

               Error budget: Com base nas definições do SLI/SLO, saber exatamente quanto tempo eu posso ter de indisponibilidade sem ferir o acordo do SLA.

               Changes gradual: Lançar versões novas de uma aplicação ou microserviço e não disponibilizar para todos os usuários antes de validar se esta totalmente funcional. Segregar uma pequena parte do trafego de acesso para esta validação. Desta forma, mesmo que ocorra uma quebra do serviço, apenas uma pequena parte dos usuários sera afetada e desta forma você consegue “esticar” o SLO para investigar e corrigir o que for pertinente para a nova release.

               Tooling e automation: Ferramentas e automação são essenciais para uma evolução do T.I e para trazer agilidade tanto no deploy quanto no rollback. O mundo perfeito é que ninguém coloque a mão no ambiente de produção.

               Medir tudo: Sair do monitoramento tradicional e ir para telemetria (Observability).

 [Resumo]

[lucasrfsblog]

Ciência de Dados: Agile Data Science Escalável

Ciência de Dados: Agile Data Science Escalável – Aula 1 – Parte 1

 Professor:  Renato Barbosa

EP 01. História da Inteligência Artificial

Conteudo:

 Regressão Linear foi desenvolvida por um francês chamado Adrian legendry. (1805) – (Metodo dos minumos quadrados)

 [Tecnicas de IA]

 KNN – O vizinho mais próximo

Diferenciação automática

Perceptron – Redes neurais

RNN –

Reinforcement learning

Random forest

SVM

Redes LSTM

 “Parece que inteligência artificial é algo novo, mas como vimos, a inteligência artificial existe desde 1950.”

 [Nova era de inteligência artificial]

 - Algoritimos de inteligência artificial

 Aprendizado supervisionado.

Labeling (Tag de dados)

Aprendizado não supervisionado

Aprendizado por reforço. (Jogos, carros, e etc)

Deep Learning.

Visão computacional. (OCR)

Speech to text e Text to Speech: São redes neurais aplicadas em áudios ou textos.

Clusterização – Agrupamento de elementos similares.

 [Resumo]

   Ciência de Dados: Agile Data Science Escalável – Aula 1 – Parte 2

 Professor:  Renato Barbosa

EP 02. IA e os dias atuais

Conteudo:

 “Claramente, o que esta transformando não é a tecnologia. A tecnologia esta transformando você.”

 [O que é inteligência artificial?]

 Inteligencia artificial é qualquer técnica que permita a maquina imitar uma logica humana.

 [Machine learning?]

 É um sub-grupo de inteligência artificial que consiste de uma técnica que busca encontrar padrões em um ou mais conjuntos de dados e a partir destes padrões gerar inteligência artificial.

 [Deep Learning]

 É uma sub-area de machine learning que utiliza redes neurais para realizar o aprendizado de maquina.

  Basicamente o slide acima explica como funciona inteligência artificial.

 Primeiro você aplica uma massa de dados utilizando um algoritico de aprendizado de maquina. A saída deste processamento vai gerar padrões de dados, que é chamado de modelo.

A partir de um modelo treinado, é possível ter inferências (resultados baseados em estatísticas e probabilidades do modelo utilizado) ao aplicar novos dados neste modelo.

   O maior objetivo de inteligência artificial é resolver um problema;

 [Resumo]

  Ciência de Dados: Agile Data Science Escalável – Aula 1 – Parte 2

 Professor:  Renato Barbosa

EP 03. IA e as organizações

Conteudo:

 As organizações ML Centric.

  Como uma empresa se torna ML Centric:

  No caso das empresas ML Centric, “Na verdade, todas as decisões são totalmente automatizadas.” Eu não preciso mais de pessoas para que eu possa tomar uma decisão.”

  “As organizações que adotarem inteligência artificial impulsionarão maior engajamento com os clientes, terão taxas aceleradas de inovação, maior competitividade, margens mais altas e funcionários mais produtivos.”

  [Jornada de adoção de IA]

  Um dos maiores erros das organizações ao tentar adotar inteligência artificial é estruturar um time de tecnologia e mante-lo afastado da estratégia de negócios da empresa. Precisa existir um alinhamento da empresa com o time de inteligência artificial para alinhar a estratégia da empresa com as tomadas de decisões baseadas em IA.

 [Fase – 1] - Exploratorio

 Maturidade:

 Explorar IA. Testar e explorar dados e problemas de negocio. Nesta fase a empresa ainda esta aprendendo inteligência artificial.

 [Fase-2] - Iniciante

 Nesta fase as empresas já começam a resolver problemas de negocio com o emprego de inteligência artificial.

Já existe um data lake em formação e uma equipe de analistas e cientistas estudando os problemas de negocio com o emprego de IA.

A liderança já destina um budget para empregar inteligência artificial para solucionar problemas de negocio.

 [Fase-3] - Intermediario

 A inteligência artificial já se provou dentro da organização e o próximo passo é escalar. Nesta etapa já existe um data lake formado.

O passo agora é descobrir como usar inteligência artificial e ciência de dados e aplicar por toda a organização para resolver problemas de negocio.

Já há um data lake formado, estrutura-se a governança do data lake (Controle de acessos), já há modelos de IA em produção e o valor começa a ser gerado.

O time de inteligência artificial começa a crescer.

 [Fase-4] – Avançado.

Nesta fase as empresas já tomam decisões de negocio baseadas em IA de forma automatizada.

 “Decisões de negocio são feitas através de IA e ai então eu tenho, de fato uma empresa Bastante automatizada.”

 [Papeis] – São 4 principais papeis:

  [Principais erros das organizações]

 Abaixo a listagem dos principais erros das organizações na adoção de inteligência artificial:

 - Erros de estratégia. (Não considerar a estratégia da empresa alinhada com os produtos e soluções de IA)

- Falta de buy-in executiva. Sem apoio financeiro para alavancar o desenvolvimento de IA.

- Falta de planejamento e orçamento.

- Times: Falha em desenvolver profissionais, as empresas querem profissionais mas não há tanta disponibilidade destes no mercado.

- Tecnologia: Focar apenas em tecnologia não resolve o problema. IA se da com a aplicação de conhecimento de IA nos seus dados e dai saem os modelos que você deve considerar. (não da pra sair comprando produtos de prateleiras)

 [Agilidade e flexibilidade]

  [Resumo]

[lucasrfsblog]

Projetando Arquitetura com Segurança

Projetando Arquitetura com Segurança: Um Framework para Proteger o Ciclo de Vida do Software – Aula 1 – Parte 1

 Professor: Yuri Diogenes

EP 01. Necessidades

Conteudo:

 Uso de SDL – Security development lifecycle.

 Objetivo: Mitigar as vulnerabilidades no código, no momento em que você está desenvolvendo o código, pensar em segurança desde o princípio.

Likelihood = propabilidade.

 Terminologias:

 Fase Security by design: Inserção de métodos de segurança desde a concepção do projeto, do desenho, da estrutura e da arquitetura como parte do ciclo de vida do projeto de software.

Utiliza modelagem de ameaça (threat modeling) e mitigações(mitigations).

Modelagem de ameaça faz considerações mais abrangentes sobre as entradas de dados e as comunicações que serão disparadas após este input.

 Fase Security by default: Neste modelo, o software já esta seguro por padrão, pois já conta com os recursos de segurança necessários já configurados seguindo as melhores praticas de segurança atuais.

 Atributos:

 Menor privilegio: Os privilégios de usuários são os mínimos necessários para o funcionamento da aplicação.

Defensa em profundidade: Criar mecanismos para fornecer segurança em profundidade (em camadas).

Ex: Implementar múltiplas camadas de segurança, de forma a garantir que se algo der errado e se os dados forem interceptados por um threat actor, a leitura destes dados não se tornem clara o suficiente. Este atributo pode empregar criptografia no armazenamento e em transito para assegurar a comunicação de forma que somente os envolvidos nela tenham o acesso integral ao conteúdo enviado ou armazenado.

Fase Secure in Deployment:

- Documentar o código de modo a entender qual é a função de cada bloco do código para garantir maior controle no momento de alguma alteração.

- Ter ferramentas de análise e controle de release e garantir que a nova release chegou em todos os endpoints que utilizam este software.

Gerenciamento de patches para assegurar que você esta controlando os patches do seu software e que isso esteja sendo feito de forma segura.

A maior parte dos ataques exploram vulnerabilidades que possuem patches disponíveis e que ainda não foram implementados no ambiente.

 [Resumo]

Projetando Arquitetura com Segurança: Um Framework para Proteger o Ciclo de Vida do Software – Aula 1 – Parte 2

 Professor: Yuri Diogenes

EP 02. Conceitos

Conteudo:

 3 conceitos de segurança(CIA):

 1-      Confidencialidade (Manter o segredo secreto)

A forma de manter a confidencialidade do dado vai variar de acordo com o estado do dado, como ele esta armazenado ou como ele esta sendo transmitido ou acessado.

 Aplicar criptografia para dados armazenados no disco (at rest) e em trânsito entre cliente e servidor.

Aplicar controle de acesso aos dados em memória, permitir o acesso apenas se houver validação de privilegio para.

 2-      Integridate

Integridade esta ligada a manter as condições integrais de um dado, ou seja, garantir que ele não seja alterado de forma indevida ou não autorizada.

 3-      Disponibilidade

O dado precisa estar disponível.

 Autenticação:

Autenticação é critica em ambiente de desenvolvimento. O método de autenticação mais comum é o de múltiplos fatores.

Exemplos de múltiplos fatores de autenticação:

Token

PIN

Biometria

 Sempre pensem em métodos que vão elevar o nível de segurança.

  Autorização:

Após autenticar o usuário é necessário validar a autorização do usuário sempre que ele for acessar os métodos.

 Existem 3 elementos que devem ser considerados ao controlar a autorização de acesso:

 1-      Requisitor: Quem esta pedindo o acesso, o usuário ou algum atacante que estiver tentado acessar algo na aplicação.

2-      Objeto: O que esta tentando ser acessado, pode ser um dado no banco de dados, um arquivo ou alguma função especifica do sistema.

3-      Tipo de acesso: Qual o tipo de acesso foi solicitado, leitura ou escrita.

 Auditoria:

 Perguntas que precisam ser respondidas:

Os logs foram habilitados?

Tem gente revisando os logs?

 “Pior que não habilitar logs é nunca revisar eles.”

 Para trabalhar com logs é necessário realizar duas atividades triviais:

 Revisão dos logs: Consiste em procurar por erros ou desvios de padrão.

Investigar os logs: Investigar alterações indevidas ou que de alguma forma não foram autorizadas e identificar o causador desta alteração e quando ela foi efetuada.

 Ao desenhar o seu projeto incluir este nível de detalhe nos logs para ser uma ferramenta de apoio para a segurança do seu software.

 Elementos de desenvolvimento seguro:

 Gerenciador de sessão: Quando dois processos precisam se comunicar um com o outro, neste momento se estabelece uma sessão entre eles, e esta pode ser local ou remota. (Inter ou intra processos)

 Gerenciador de exceção: Todo software em algum momento vai gerar algum erro, que nada mais é que uma condição não conhecida.

Quando uma exceção não é tratada de forma correta, existe uma grande possibilidade de exposição de informações que não deveriam ser de conhecimento do usuário. (dumps de memória, informações do servidor de aplicação, métodos que foram chamados e etc)

Implementar fail-safe, para tratar exceções quando o cliente não possui os requisitos necessários para comunicação com a aplicação e nunca reduzir o padrão de segurança em troca de compatibilidade.

 Gerenciador de configuração: Assegurar que as alterações necessárias de configuração no ambiente do usuário não tragam problemas de segurança. (Alterações de variáveis de ambiente, chaves de registro e etc)

 Secure Gateway(secure checkpoints): Consiste em ter uma equipe que vai revisar, criticar e identificar se aquela fase do projeto adequa-se com os pre-requisitos.

Estes constantes secure gateways são importantes para validar se tudo que foi estabelecido no começo do projeto esta seguindo conforme o planejado no início.

Não passa para a próxima fase senão atingir os requisitos de segurança.

 Bug check: Necessario, identificar, documentar e trilhar estes bugs e alterar o status deles de acordo com as alterações que são realizadas em cada um destes softwares.

Bugs de software nem sempre possuem grandes benefícios, mas as vezes demandam grande esforço e tempo para serem corrigir, é necessário mensurar o risco que ele oferece para tomar a decisão de quais bugs serão priorizados a serem corrigidos.

  Risco = Impacto x probalidade. (utilizar o conceito DREAD)

 DREAD: damage potential, reproducibility, exploitability, affected users e discoverability

 Impacto: Damage e usuários afetados. (D e A do DREAD)

Damage: Qual é o dano que esta vulnerabilidade pode causar?

Quantos usarios serão afetados por este bug?

 Probabilidade: Reproducibility, exploitability e discoverability.

Reproducibility: Qual a complexidade de reproduzir este bug?

Exploitability: Qual a complexidade ou dificuldade de explorar este bug?

Discoverability: Quão difícil ou complexo é para descobrir este bug ?

 A probabilidade vem trazer a tona quão oculto este bug pode ser e as chances dele ser explorado. Ser raro ou complexo de ser explorado não significa que ele é oculto e que não deve ser tratado, mas isso vai ajudar a mensurar a prioridade e esforço em atuar para sua correção.

Vale a pena considerar estratégias de mitigações, mesmo que não sejam definitivas enquanto a solução do bug está sob desenvolvimento.

[Resumo]

[lucasrfsblog]

Arquitetando a Nuvem: Componentes e Recursos Necessários para Implementação

Arquitetando a Nuvem: Componentes e Recursos Necessários para Implementação – Aula 1 – Parte 1

Professor: Evandro Melo

Começa agora a sua série de oito episódios com o professor referência Evandro Melo para a disciplina Arquitetando a Nuvem: Componentes e Recursos Necessários para Implementação. É só dar o play. Bons estudos.

EP 01. Tradicional x Cloud

Assunto:

 “A necessidade é a mãe das invenções.”

 A falta de previsibilidade de demanda gerou duvida sobre o real dimensionamento dos sistemas e ambientes de infraestrutura, que para evitar gargalos sempre dimensionada pra cima fazendo com que por muitas vezes a conta não fechasse deixando muito recurso ocioso.

 [ O que existia antes da Cloud ]

 1-      Datacenter on-premisse (Responsabilidade total da infraestrutura)

2-      Collocation (A responsabilidade de facilities é toda da empresa de collocation)

3-      Hosting (Neste cenário toda a infraestrutura é terceirizada e a gestão da aplicação é a sua única responsabilidade)

4-      Outsourcing (Terceirização total do ambiente de T.I incluindo as áreas de negocio)

 [Principais desafios]

 - Não são sob demanda.

- Não são no modelo pague-pelo-uso. (Pay-as-you-go)

- Necessario link dedicado como conectividade. (Maior custo)

 “Nenhum desses modelos atendiam integralmente os novos modelos de negócios que surgiam.”

 [Caracteristicas]

 Contratos com tempo mínimos de tempo.

Investimento inicial alto.

Custo base mensal mais alto.

Tempo de implementação mais alto (semanas/meses).

Necessário adquisição pelo consumo futuro.

Independente do negócio da empresa, é necessário time

técnico para gerenciar infraestrutura.

 [Comportamento com consumo por demanda]

 Em resumo, era muito difícil prever a demanda e se preparar para ela, muitas vezes o se preparar para uma demanda significava desembolsar muito dinheiro em investimento em infraestrutura.

  “A compra deste ambiente tradicional não é rápida. Pode levar meses até ter os recursos no site e ainda será necessário configurar todo o ambiente.”

 [Cloud Computing]

- O que a Cloud computing trouxe para o mercado?

Cloud Computing é uma opção popular para pessoas e empresas por uma série de razões, incluindo economia de custos, aumento da produtividade, velocidade e eficiência, desempenho e segurança.

“Para quem inova é importante ter segurança de que posso errar. Errou, joga fora. Não precisa se apegar aquele recurso computacional.”

 [Resumo]

 Arquitetando a Nuvem: Componentes e Recursos Necessários para Implementação – Aula 1 – Parte 2

Professor: Evandro Melo

EP 02. Definições

 Conteudo:

 [Definição]

 O que é Cloud Computing:

 - Wikipedia:

 Cloud computing é um termo coloquial para a disponibilidade sob demanda de recursos do sistema de computador, especialmente armazenamento de dados e capacidade de computação, sem o gerenciamento ativo direto do utilizador.

O termo geralmente é usado para descrever centros de dados disponíveis para muitos utilizadores pela Internet.

- Gartner:

 Cloud Computing é um estilo de computação em que recursos escalonáveis

e elásticos de TI são fornecidos como um serviço usando tecnologias de Internet.

 - IDC:

 Um modelo emergente de desenvolvimento, implantação e entrega de TI, permitindo a entrega em tempo real de produtos, serviços e soluções pela Internet.

 - AWS:

 Cloud computing é a entrega de recursos de TI sob demanda por meio da Internet com definição de preço de pagamento conforme o uso.

Em vez de comprar, ter e manter datacenters e servidores físicos, você pode acessar serviços de tecnologia, como capacidade computacional, armazenamento e bancos de dados, conforme a necessidade, usando um provedor de cloud.

“O conceito de Cloud que temos hoje começou com a Amazon e com a criação da AWS.”

 - NIST:

Cloud Computing é um modelo para permitir acesso a qualquer hora e em qualquer lugar, conveniente e sob demanda a um grupo de recursos de computação compartilhado, configuráveis (por exemplo, redes, servidores, armazenamento, aplicativos e serviços) que

podem ser rapidamente provisionados e liberados com mínimo esforço de gerenciamento e interação com o provedor de serviços.

[Atributos da Cloud computing]

[História]

40’

Durante a década de 1940, foi desenvolvido o primeiro Data Center, nos EUA, chamado ENIAC (Electronic Numerical Integrator and Computer),

para fins militares.

O Data Center, ainda com tecnologia de tubos, cristais de diodos e capacitores, media cerca de 167 m2.

 60’

Na década de 1960, chegaram os transistores e com esta tecnologia surgiram os primeiros Mainframes da IBM, dando início também a virtualização, possibilitando o processamento multitarefas.

 70’

Nos anos 70 surge o processador INTEL, o primeiro processador programável para propósitos gerais.

Surge também os primeiros computadores gráficos e as primeiras redes locais (LAN).

 80’

Inicia-se a era dos computadores pessoais (PC), que chega para democratizar o acesso à tecnologia da informação.

Junto à chegada em massa dos PCs, expandem-se também as redes locais, tornando possível, por exemplo, o compartilhamento de arquivos.

 90’

Os anos 90 ficaram marcado pela chegada da Internet às casas das pessoas.

O uso da Internet se torna massivo, criando novas demandas e oportunidades.

O modelo de Data Center como serviço, ou Outsourcing, passa a ser um grande

negócio.

 2000’

Com a Internet já democratizada e consolidada, começam a surgir novos modelos de negócios, como o comércio eletrônico (e-commerce), porém, que esbarram no modelo de consumo de TI.

Em 2006, a Amazon.com, maior ecommerce do mundo, inicia a Amazon Web Service (AWS) empresa de tecnologia em Cloud, que nasce de uma demanda interna

e passa a ofertar serviços de computação, armazenamento e outros, a todo mercado

através da internet, sob demanda e no modelo pague-pelo-uso.

 [Casos de uso]

 ·         E-Commerce:

 Empresa com picos de consumo inesperados, como promoções ad-hoc, ou mesmo

picos previstos como Dia das mães, Black Friday e Natal.

No modelo tradicional teriam que adquirir recursos de TI pensando no pico, ainda

assim correndo riscos por demandas não previstas.

No restante do ano, arcariam com a ociosidade do ambiente.

Em Cloud, a arquitetura elástica permite o rápido escalonamento do ambiente, seja

manual ou automaticamente. Em períodos de baixam o consumo acompanha a

demanda e não há ociosidade.

 ·         ERP:

 Implantações de ERP possuem fases específicas em que inicialmente o time de consultores atuam implementando as regras de negócios no ambiente de DEV, que não precisam rodar 24x7.

Nesta fase é importante ter um ambiente provisionado rapidamente, evitando atrasos e ociosidade dos consultores, porém não é necessário provisionar todo ambiente de uma vez.

No modelo tradicional, a empresa teria que estimar o consumo futuro para aquisição da infraestrutura, fazer a compra com investimento inicial alto, aguardar semanas/meses até que o ambiente esteja provisionado.

Em Cloud, é possível provisionar o ambiente em minutos, acompanhando as fases do projeto até o Go-Live. Além disso, é possível desligar o ambiente durante a noite e finais de semana, reduzindo custos.

  ·         Startups:

O segmento financeiro no Brasil é bastante conhecido pelo alto uso de tecnologia.

Sendo o processamento de boa parte dos processos em Mainframes.

Este modelo acaba sendo uma barreira de entrada para novos entrantes, devido o alto

custo inicial e alto risco.

A Cloud possibilitou empresas como NuBank, Ebanx, entre outras, a entrar neste mercado, com um novo modelo de serviço e muita inovação, sem a necessidade de altos investimentos iniciais.

Hoje as plataformas de cloud entregam um vasto portfolio de serviços que vão desde

os tradicionais computação e armazenamento, até machine-learning e inteligência

artificial, blockchain, IoT, entre outros.

 ·         Delivery Global:

 Empresas globais e multinacionais, perdem sinergia ao ter que optar por ou

centralizar o Data Center em uma única localidade e baratear a operação, porém

aumentando latência e colocando em risco a experiência do usuário, ou então

aumentando os custos e entregando serviços em Data Centers locais próximos aos

clientes finais.

A Cloud permite que as empresas, incluindo os ISVs (Independente Software

Developers), consigam entregar suas cargas de trabalho próximas dos usuários finais,

sem perder a governança e o ganho em escala.

 ·         Segurança:

 Ao contrário do que muitos ainda pensam, a cloud é bastante segura.

É importante entender que cloud é um negócio de escala, logo, os grandes provedores de serviços em cloud são capazes de investir pesadamente em tecnologia, pessoas, processos, para garantir os mais altos níveis de segurança e conformidade com as principais normas de

mercado, como a ISO, PCI, HIPAA, GDPR, LGPD, entre outros.

Importante, porém, salientar o modelo de responsabilidade compartilhada, que irei detalhar adiante.

 [Resumo]

[lucasrfsblog]

Mitigando atritos entre times com DevSecOps – Aula 1 – Parte 1

Mitigando atritos entre times com DevSecOps – Aula 1 – Parte 1

Professor: Caio Pereira

EP 01. Visão geral

Conteudo:

“É interessante a gente pesar sobre o paradigma, sobre o panorama de como isso aproxima os times, como isso cria uma cultura de maior colaboração entre os times. (Dev + Sec + Ops)

Bibliografia para aprofundamento de estudos:

[Resumo]

Mitigando atritos entre times com DevSecOps – Aula 1 – Parte 2

Professor: Caio Pereira

EP 02. Conceito

Conteudo:

 O que é DevSecOps?

 Qual o problema que o DevSecOps propõe resolver?

 - Modelos tradicionais de desenvolvimento de software eram pouco flexíveis, caros e não traziam agilidade que os negócios demandavam.

 Com as metodologias ágeis criou-se uma estrutura de ciclos curtos de desenvolvimento com entregas de produtos iterativo e incremental.

As startups e empresas modernas já começam assim, já nasceram ágeis, com entregas continuas e com feedback curto do cliente.

 Como entregar agilidade na pratica?

 Implantar modelos ágeis no desenvolvimento não garante entrega de agilidade para o ciclo todo, pois operações também precisam entregar a mesma agilidade no deploy das novas funcionalidades. Neste ponto, começa o DevOps, integrando operações no desenvolvimento, para que o ciclo todo tenha agilidade e não haja conflito entre estes dois times.

 A ideia do DevOps é ter um time único que cuida tanto do desenvolvimento quanto da operação, ou seja, um time multidisciplicar com competência para codificar e subir o código no ambiente de produção se necessário.

 Conceito do Jeff Bezzus. “Two Pizza team”

 Para conseguir este nível de agilidade e maturidade, não basta ter os skills necessários nos times, precisamos incluir automação no processo para não desperdiçar tempo com configurações manuais, e entregar infraestrutura as code (IaC), testes automatizados, entrega continua e deploy continuo. (CI/CD)

 E como fica a segurança das aplicações? E o conceito de security by design?

 “Desenvolver um aplicativo para um banco e não garantir que aquilo é seguro é inviável, é um tiro no pé.”

 Neste momento nos deparamos com o mesmo problema do DevOps. Dev e Ops conseguem entregar agilidade, mas segurança se torna o gargalo do processo pois segura os os processos de release até que todos os critérios de segurança tenham sido atingidos.

 E como resolver isso? Utilizando o conceito de DevSecOps.

 [Resumo]

 Mitigando atritos entre times com DevSecOps – Aula 1 – Parte 2

Professor: Caio Pereira

EP 03. Conflitos

Conteudo:

 “Não existe o nós e eles, como um único time e uma única empresa e temos que trabalhar desta maneira.”

“O time de SI (Segurança da informação) torna-se o cara chato.

 - Conflitos de Dev/POs e analistas de segurança;

- Times pedem que um analista de segurança em especifico analise seus projetos. (Ideia de menor resistência ou maior agilidade na entrega das analises)

 Cultura de escalar as solicitações: Por conta dos prazos de entregas dos programas, quando os times não são únicos, há conflitos de interesses. DevOps querem entregar produtos e Sec querem que ele seja seguro. Quando não há consenso entre os times algum executivo é acionado para mediar a situação e decidir o que deve ser feito.

- Executivos precisam decidir sobre o risco de implantações de sistemas com vulnerabilidades.

- Além do risco desta decisão, este tipo de comportamento desgasta os times e seus relacionamentos.

“Você quer correr o risco de um hacker invadir e roubar a senha do usuário do seu cliente?” Este é o risco que esta sendo exposto quando colocamos um executivo para decidir sobre um problema técnico e não executivo.

Quando você ocupa os executivos com decisões operacionais, você deixa de usar a capacidade analítica e estratégica deles para questões realmente relevantes e estratégicas do negócio.

 Qual a causa raiz de tantos conflitos?

 A grande maioria dos conflitos são gerados por incentivos desalinhados, ou seja, os times tem KPIs e objetivos diferentes, mas não deveriam, pois a empresa é uma só e a colaboração entre as equipes deveria ocorrer de forma natural e com foco no objetivo da empresa como um todo.

 Este tipo de decisão não deveria ser tomado pelo executivo e sim pelos times que são competentes para isso.

 Hoje em dia uma empresa que não tem capacidade de entregar novas funcionalidades com frequencia reduzida esta fora do mercado.

 “Os cliente não tem mais paciência para ficar esperando um ano para lançar um novo produto. Eles querem novidade toda semana.”

 O DevSecOps veio para resolver um dos maiores conflitos entre diferentes áreas, que é a falta de coloraboração que foi levantada anteriormento.

 [Clima de não Colaboração]

 - Impacto no clima do time.

- Pessoas menos engajadas e menos produtivas.

- Impacto nos negócios.

 [Resumo]

[lucasrfsblog]

Muti-Cloud - Aula 1

Multi-Cloud – Aula 1

 Professor: Rodrigo Vale (Google employee)

 Agenda:

 - Definindo multi-cloud e seus padrões.

- Networking em Multi-Cloud

- Microserviços em Multi-Cloud

- Banco de dados em Multi-Cloud.

- Data Analytics em Multi-Cloud.

- CI/CD em Multi-Cloud

- Estudos de dados.

 O que é multi-Cloud:

 É o uso de vários serviços de computação em nuvem e armazenamento em uma única arquitetura heterogênea. Isso também se refere a distribuição de ativos em de nuvem, software, aplicativos, etc. em vários ambientes de hospedagem em nuvem.

 - Provedores de serviços de Multi-cloud podem hospedar 4 tipos de serviços:

 1-      Infraestrutura as a servisse. (IaaS)

2-      Plataforma como serviço. (PaaS)

3-      Function as a servisse. (FaaS)

4-      Software as a Service. (SaaS)

 Multi-cloud não é paralelistmo.

  - Multi-Cloud em um entendimento mais amplo:

- Cloud bursting: Uso eventual de recursos de nuvem para escalar processamento on-premisse para lidar com momentos de picos.

 [Pergunta]

 Por que as empresas estão indo para multi-cloud?

Vms, banco de dados, armazenamento se tornaram commodities.

Padrões multi-cloud:

 Arquitetura comum Multi-cloud:

  Razões para adotar multi-cloud:

 O calculo de ROI deve considerar custo de operações.

 Autonomia esta ligado a questão de lock-in.

 Razões para não adotar multi-cloud:

Custo de egress é o valor que se paga para retirar dados do provedor de cloud. Este custo pode ser um fator proibitivo para deixar um provedor. (Atenção para lock-in)

 Falta de gerenciamento de aplicativos: Quando a equipe não sabe o que ou como gerir um tipo de aplicativo, as famosas caixas pretas. Levar este tipo de ambiente para multi-cloud só vai multiplicar o problema.

 [Resumo]

Multi-Cloud – Aula 1 – Parte 2:

 - Redes de computadores no ambiente multi-cloud:

 “O principal desafio em um ambiente multi-cloud é. De fato a conectividade.”

  Azure: Express route

AWS: Direct connect.

Google: Dedicated Interconnect

 [VPN]

Utiliza a internet como meio de acesso ao DC do serviço de Cloud.

Recomenda-se utilizar uma camada de criptografia para proteção dos dados trafegados.

Por conta do uso da internet como meio, não há uma garantia de constância na performance do serviço.

Na pratica não há um SLA a ser definido entre cliente e cloud provider, já que isso não é um serviço oferecido pelo provedor de cloud.

Em geral o uso de VPN entre cloud e clientes é feito para prova de conceitos e não para soluções definitivas.

 [Solução de cloud – Uso de parceiros]

 Uso de partner edge como meio de conexão com o provedor de cloud.

Neste caso o SLA é limitado ao parceiro que é contratado para entregar esta conectividade.

 É recomendável ter mais de um caminho ou conexões entre os seu parceiro e o seu DC, considerando sempre dois caminhos distintos.

 [Vantagens]

- Velocidade constante.

- Possibilidade de ter redundância.

- Varias opções de parceiros

[Desvantagens]

- O SLA pode ainda não atender a sua necessidade de negócio.

 [ Soluções de Cloud – Produtos de Cloud]

 - Google:

 Conexão física dedicada entre seu DC -> Provedor de cloud onde há a eliminação do terceiro;

 [Vantagem]

 - Aumento do SLA.

- Redução de pontos de falha por não haver um parceiro terceiro no meio do caminho.

 Com relação a velocidade, pode não haver diferença de velocidades

 [Desvantagem]

 - Opções de conexão com o seu provedor de Cloud pode ser inviável ou não estar disponível.

 O principal motivo para o aumento do SLA é a questão da manutenção de rede, ou seja em um momento de manutenção, a redundância aumenta a sua chance de fazer a troca dos caminhos e manter o serviço ativo.

 [AWS]

  [Topologias de rede em ambientes multi-cloud]

  Mirrored:

  A ideia desta topologia é fazer com que tanto o ambiente privado e em nuvem se espelhem.

Esta topologia se aplica em ambientes híbridos de cloud, onde o ambiente de testes e produção são executados em clouds diferentes, e como no exemplo acima, todo o CI/CD é feito em cloud publica e após a validação, o deploy em produção é feito no ambiente on-premisse ou cloud privada.

Meshed:

É esta estabelecer uma rede plana, em que todos os sistemas podem se comunicar um com os outros.

Ela é aplicada em configuração em camadas, particionadas ou bursting.

- Versão mais comum:

O uso do provedor de cloud como edge e porta de entrada para uma DMZ. Ou seja, usa-se o recurso de conectividade do cloud para ser porta de entrada para chamadas de aplicativos no DC on-premisse.

Gated egress:

Basicamente este modelo permite que workloads executados no cloud acessem o seu ambiente para consumir recursos, sejam eles APIs ou qualquer outro que esteja disponível no seu ambiente de cloud privado.

 Gated ingress:

Este modelo segue o caminho inverso do anterior (egress), onde o modelo de DC já concentra a maior parte dos workloads no ambiente cloud publico e a sua cloud privada precisa consumir dados ou APIs que estão disponíveis no ambiente de cloud publica.

Gated ingress and egress:

 Este é um misto de ambas as abordagens lisadas acima;

[Conectando múltiplos cloud providers]

 - Uso de parceiros:

O uso de um parceiro comum para atender a esta demanda é uma das opções.

- Uso de conexão direta:

Ganho de SLA.

Desvantagem, complexo de conseguir criar este cenário por limitações geográficas.

 - Quando não há mais uma cloud privada, o ambiente é todo em cloud publica:

Neste caso usa-se um parceiro para criar este túnel de conectividade.

[Resumo]