#aula2

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

 Professor:  Sergio Nauffal

EP 03. Arquitetura

Conteudo:

 Data Lake & Big Data process:

  Data Ingest: (Dados ou fontes de dados que devem ser consideradas para alimentar o data lake)

 1-      Bancos de dados, relacionais ou não relacionais.São carregados geralmente com ferramentas de ETL ou replicação destes dados.

2-      Devices (IOTs) – Produzem stream de dados e podem conter dados binários ou não.

3-      Aplicações: Aplicações produzem logs que podem ser enviados para os data lakes e geralmente o método utilizado é o stream de dados.

4-      Arquivos de usuários, NFS, outros data lakes devem ser considerados no modelo de ingestão de dados e o método mais comum de carregamento é o upload de dados para o data lake no cloud.

 Data Process: Etapa de processamento dos dados, onde os dados são filtrados e limpos para entregar para as ferramentas que vão gerar relatórios e insights para o negócio.

 Nesta etapa são utilizadas duas ferramentas principais:

 FaaS – Lambda da AWS(automação) é um exemplo, executando códigos que irão transformar os dados Raw em algo já trabalhado pronto para ser lido.

SQL As Service: Modelo de consumo de bases de dados SQL como serviço que são consumidas para gerar, indexação dos dados trabalhos e catalogo destes dados, afim de facilitar a busca das informações pelas ferramentas que irão consumi-los.

 Catalogo: Possui dados organizados por assunto ou área. (Ex: Financeiro, RH)

Indexes: Possui dado indexado para dar maior agilidade nas buscas e entregar maior performance.

 Data Insight: Nesta etapa é onde os dados começam a mostrar o seu valor, gerando insights para o negocio e entregando a visão que se espera tanto para analisar dados do passado (BI) quanto para fazer predições futuras com o emprego de Inteligência artificial e data Science.

 O produto final destes dados podem ser:

 Dashboards: Geralmente requerem acesso constante aos dados para realizar ou mostrar atualizações e variações de comportamento ao longo do dia. Neste caso, conforme orientado, recomenda-se que estes dashboards conecte-se em data warehouse que possuem grande otimização para disponibilizar estes dados.

 Reports – Relatorios gerenciais ou executivos que podem tanto acessar o dado catalogado no data lake ou consumir eles de algum data warehouse (Recomendado) que deve entregar menor latência e maior otimização no acesso a estes dados. No caso de reports por serem dados que não precisam de grande atualização o tempo todo, estes normalmente são gerados em processos batchs.

 Data warehouse: São bases de dados SQL de proposito comum no entanto com grande otimização de acesso aos dados, com catálogos bem definidos e grande poder de indexação.

Recomenda-se o uso do data warehouse para entregar maior agilidade na leitura dos dados já trabalhados e catalogados, principalmente quando há necessidade de leitura constante pelo uso de dashboards constantemente atualizados.

 Machine Learning e Data Science: Com o uso destes mecanismos e técnicas, precisamos plugar o nosso ambiente em modelos treinados de AI. O grande desafio desta área é conseguir reproduzir insights e entender como chegamos nos resultados obtidos.

 Governança dos dados: Não menos importante que as outras etapas, a governança dos dados devem entregar trivialmente as seguintes condições:

 Data tracking – Quem acessou e quando acessou cada dado.

Enforce Policy – A política de acesso precisa ser respeitada e deve ser garantida.

 [Data lake em Cloud]

  [Azure]

  [AWS]

   [Tipos de dados]

 [ETL]

  1-      Extração:

 2-      Transformação:

A transformação dos dados consistente em limpar os dados e transforma-los de forma organizada para carregar.

3-      Carregamento dos dados de forma persistente.

 [Na pratica]

 Exemplo:

- Vaga de emprego:

  [Importante]

  [Automatizar ETL: IA, ML e rede Neural]

  [Redes Neurais + Base de inferencia]

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

 Professor:  Giovane Moura

EP 03. Trade OFF

Conteudo:

 “Não é só ir para a nuvem. Não é só ir para microserviços. É a gente conseguir ter sucesso nessa arquitetura.”

 Event Driven: É a forma de controlar o envio de mensagens de um microserviço para o outro.

 Existem basicamente dois tipos de serviços para controlar os eventos:

 - Fila: First in first out – (FIFO)

- Topico: Quem grava mensagens no tópico é o Publisher e quem lê estas mensagens são os subscribers. (Muitos para muitos N:N)

 CI/CD: O conceito de CI/CD deve estar sempre atrelado ao emprego de microserviços e de certa forma, com o uso de containers o emprego do CI/CD fica mais simples de ser feito.

Criar a esteira do CI com build e teste do código e posteriormente e não menos importante mas de acordo com a maturidade da empresa, o CD, este então pode ponderar de fazer ou não o deploy de forma automática, mas a entrega do artefato deve ser feita.

 Base de dados: Isolamento da base de negocio para aquele microserviço em especifico.

 Reuso: Sera que este microserviço será reutilizado por outro time? Outras aplicações também vão utilizar?

 Tamanho: Não é por que é microserviço que consome microrecursos. Microserviço refere-se a pequena parcela de um sistema ou serviço como todo, mas nem sempre isso vai demandar poucos recursos.

 [Resumo]

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

 Professor:  Giovane Moura

EP 04. Ferramentas

Conteudo:

  Ler os conceitos de Cloud moderno:

 IaaS:

 PaaS:

 SaaS:

 FaaS:

 Portabildade: O uso de containers padroniza a infraestrutura e suas características e tras o beneficio da portabilidade e reduz os riscos de lock-in.

 O que é um container?

 Container é uma forma que eu consigo empacotar o meu sistema operacional e todas as minhas libs e runtime necessários para que meu código seja executado de forma consistente.

 “O objetivo do container é possibilitar que você execute o seu código de forma isolada e contida em um mesmo servidor.”

 Pesquisar:

 Namespace:

Introduzido em 2002, na versão 2.4.19 do kernel Linux, Namespace é uma feature que permite criar e lidar com diversos contextos em um mesmo sistema, vendo propriedades globais diferentes e isoladas em cada contexto. Para facilitar o entendimento, com namespace é possível criar um contexto (ou ambiente) de rede isolado do ambiente físico. Nesse novo contexto, existirão interfaces de rede física que não são visíveis no contexto do sistema; essas interfaces terão endereços físicos e lógicos diferentes do contexto do sistema e todo tráfego, regras de firewall, existentes nesse novo contexto, não são vistos por nenhum outro contexto, incluindo o contexto do sistema.

Essa é a feature que é utilizada para garantir isolamento. Embora exemplifiquei utilizando recursos de rede, existem diversos recursos que podem ser isolados utilizando namespaces. Os principais são:

·         Mount (mnt) namespace

·         Process identify (pid) namespace

·         Unix timesharing system (UTS) namespace

·         Network (net)namespace

·         inter-process comunication (IPC) namespace

·         user namespace

O Mount namespaces é responsável por criar um contexto isolado do sistemas para dispositivos que podem ser montados pelo sistema. Aqui, você pode observar que nem todo dispositivo montado no contexto físico deve ser disponibilizado para containers, ou algo que é montado em um container não deve ser também montado em outro. Precisa existir um isolamento e o mount namespaces garante isso para o recurso de dispositivos montados.

Além desses, existem também artigos que complementam a necessidade de isolar outros recursos encontrados nos sistemas Linux através de namespaces. Eles foram propostos e que ainda não foram implementados, como por exemplo:

·         time namespace

·         system log (syslog) namespace

Arquitetura de namespaces

A maneira que o sistema operacional irá criar e gerenciar namespaces depende principalmente da arquitetura de namespace que é implementado no kernel do sistema operacional. Existem duas arquiteturas básicas que os namespaces podem ser implementados: a arquitetura hierárquica e a não-hierárquica.

A arquitetura hierárquica relaciona os recursos em diferentes contextos. Geralmente os recursos dos novos contextos são relacionados com o contexto do sistema já criado. Embora os namespaces sejam isolados entre si, eles podem ser mapeados para que o contexto principal possa, de alguma maneira saber que existem outros contextos em execução. A Figura 1 demonstra como podem diferentes namespaces podem ser relacionados hierarquicamente.

Figura 1- Arquitetura hierárquica de namespaces

Para fins de exemplo, suponhamos que os círculos enumerados sejam processos. Na arquitetura hierárquica, os namespaces filhos (Child namespaces) foram originados do namespace pai (Parent namespace), e, com isso, estabeleceu-se uma hierarquia onde, os processos executados pelos filhos são mapeados através de processos no pai. Vale salientar que o identificar nos namespaces filhos são diferentes dos nomeados pelo namespace pai.

A arquitetura não-hierárquica não relaciona os recursos em diferentes contextos. Quanto mais simples for o recurso, mais candidato ele será a utilizar essa arquitetura (UTS, por exemplo). Nessa arquitetura os recursos do namespace filhos não são mapeados para o namespace que o criou (contexto de sistema, por exemplo).

Mas, qual das duas arquiteturas é utilizada atualmente?

Ambas. Dependendo do recurso que está se isolando atráves do namespace, uma ou outra arquitetura é utilizada. E isso pode ser visto em containers LXC e Docker: quando rodamos um processo dentro de um container LXC (um contexto LXC), ele pode ser visto fora do container (no contexto do sistema) pois foi mapeado.

O PID do processo no contexto do lxc será diferente do PID no contexto do sistema. Logo, o PID é um tipo de recurso que utiliza a arquitetura hierárquica em seus namespaces e nos recursos que ele isola.

Conclusão

Namespace é algo incrível, uma feature que alavancou o uso de containers. Existe outra técnina que permite um “isolamento do sistema”, como é o caso do chroot, mas a maneira que ele trabalha é primitiva e não permite integrar com outros elementos de controlo (como o caso do cgroups).

Somente essa pequena explanação já foi capaz de abrir os horizontes e entender como um container funciona e como seus recursos são isolados. Isso responde muitas das dúvidas mais frequentes como: Porque meu pendrive não aparece no meu container? porque minhas regras de firewall não são aplicadas no meu container?

Futuramente, pretendo explanar mais sobre o assunto, mostrando algo mão na massa (Show me code, show me commands!). Qualquer dúvida, ou comentário contrutivo, deixem logo abaixo.

 Cgroup:

 Os cgroups permitem alocar recursos — tais como tempo da CPU, memória do sistema, largura de banda de rede ou combinações destes recursos — entre grupos de usuários definidos de tarefas (processos) rodando em um sistema. Você pode monitorar os cgroups que configurar, negar acesso dos cgroups a certos recursos e mesmo reconfigurar seus cgroups dinamicamente em um sistema em execução. O serviço cgconfig (“control group config ”) pode ser configurado para iniciar no momento do boot e restabelecer seus cgroups pré definidos, fazendo-os persistentes através de reboots.

Usando cgroups, os administradores de sistema ganham controle refinado sobre a alocação, prioridades, negação, gerenciamento e recursos de monitoramento do sistema. Recursos de hardware podem ser divididos inteligentemente entre tarefas e usuários, aumentando a eficiência geral.

1.1. Como os Grupos de Controle são Organizados

Os cgroups são organizados hierarquicamente, como processos, e cgroups filhos herdam alguns atributos de seus pais. Entretanto, existem diferenças entre os dois modelos.

O Modelo de Processo do Linux

Todos os processos em um sistema Linux são processos filhos de um pai comum: o processo init, que é executado pelo kernel no momento de boot e inicia todos os outros processos (que por sua vez iniciam seus próprios processos filhos). Por causa que todos os processos descendem de um pai único, o modelo de processamento do Linux é uma hierarquia única, ou árvore.

Adicionalmente, todos os processos do Linux exceto o init herdam o ambiente (tal como a variável PATH) [1] e outros certos atributos (tal como abrir arquivos descritores) de seu processo pai.

O Modelo Cgroup

Os cgroups são similares aos processos em:

·         eles seguem uma hierarquia, e

·         Os cgroups filhos herdam certos atributos de seus cgroups pais.

A diferença fundamental é que muitas hierarquias diferentes de cgroups podem existir simultaneamente em um sistema. Se o modelo de processo Linux é uma árvore única de processos, então o modelo cgroup é uma ou mais árvores desconectadas e separadas de tarefas (exemplo: processos).

Múltiplas hierarquias separadas de cgroups são necessárias porque cada hierarquia é anexada a um ou mais subsistemas. Um subsistema [2] representa um recurso único, tal como tempo de CPU ou memória, O Red Hat Enterprise Linux 6 fornece nove subsistemas cgroups, listados abaixo por nome e função.

Subsistemas Disponíveis no Red Hat Enterprise Linux

·         blkio — este subsistema define limites de acesso de entrada/saída para e a partir de dispositivos de bloco tais como drives físicos (disco, estado sólido, USB, etc).

·         cpu — este subsistema usa o agendador para fornecer acesso às tarefas de cgroups para o CPU.

·         cpuacct — este subsistema gera relatórios automáticos nos recursos de CPU usados pelas tarefas em um cgroup.

·         cpuset — este subsistema atribui CPUs individuais (em sistema multicore) e nós de memória para atribuir em um cgroup.

·         devices — este subsistema permite ou nega acesso aos dispositivos por tarefas em um cgroup.

·         freezer — este subsistema suspende ou retoma tarefas em um cgroup.

·         memory — este subsistema define limites no uso de memória pelas tarefas em um cgroup e gera relatórios automáticos nos recursos de memória usados por essas tarefas.ol

·         net_cls — este subsistema marca os pacotes de rede com um identificador de classe (classid) que permite que o controlador de tráfego do Linux (tc) identifique os pacotes que originam de um cgroup em particular.

·         ns — o subsistema do namespace.

Nota

Você pode encontrar o termo controlador de recursos (resource controller) ou simplesmente controlador (controller) nas literaturas do cgroup tais como as páginas man ou documentação do kernel. Ambos destes termos são sinônimos com “subsistemas”, e partem do fato que um subsistema tipicamente agenda um recurso ou aplica um limite aos cgroups na hierarquia que está anexada.

A definição de um subsistema (controlador de recurso) é bem geral: é algo que age sobre um grupo de tarefas, como exemplo os processos.

 Chroot:

chroot é uma operação que altera o diretório raiz aparente para o processo atual de execução e seus filhos. Um programa que é executado em tal ambiente modificado não consegue acessar os arquivos e comandos fora dessa árvore de diretórios ambiental. Esse ambiente modificado é chamado de um prisão chroot (ou chroot jail).

Lançamento do Docker em 2013.

 Outros benefícios do uso de containers:

 - Infraestrutura imutável. (Stateless)

- Deployment muito mais rápido.

- Reuso da imagem do container por outras pessoas ou serviços.

- Versionamento do container.

- Portabilidade

- Visibilidade

- Share (compartilhável)

 “Coloca a imagem do container em um lugar único, compartilha, né? Essa é a ideia da colaboração ela é muito importante e ela também vai ser fator crucial para alavancar o seu negocio , seu aplicativo e etc.”

 Já existem Windows containers com IIS, DOTNET framework e etc.

 Para tratar das limitações de escala e proxy de acesso a aplicações em containers foi criado os orquestradores de containers:

 - SWAN

- MESUS

- KUBERNETES

 2013 o google começou a trabalhar com o desenvolvimento do Kubernetes com base no BORG.

 Kubernetes é um orquestrador de containers.

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

 Professor:  Giovane Moura

EP 03. Trade OFF

Conteudo:

 “Não é só ir para a nuvem. Não é só ir para microserviços. É a gente conseguir ter sucesso nessa arquitetura.”

 Event Driven: É a forma de controlar o envio de mensagens de um microserviço para o outro.

 Existem basicamente dois tipos de serviços para controlar os eventos:

 - Fila: First in first out – (FIFO)

- Topico: Quem grava mensagens no tópico é o Publisher e quem lê estas mensagens são os subscribers. (Muitos para muitos N:N)

 CI/CD: O conceito de CI/CD deve estar sempre atrelado ao emprego de microserviços e de certa forma, com o uso de containers o emprego do CI/CD fica mais simples de ser feito.

Criar a esteira do CI com build e teste do código e posteriormente e não menos importante mas de acordo com a maturidade da empresa, o CD, este então pode ponderar de fazer ou não o deploy de forma automática, mas a entrega do artefato deve ser feita.

 Base de dados: Isolamento da base de negocio para aquele microserviço em especifico.

 Reuso: Sera que este microserviço será reutilizado por outro time? Outras aplicações também vão utilizar?

 Tamanho: Não é por que é microserviço que consome microrecursos. Microserviço refere-se a pequena parcela de um sistema ou serviço como todo, mas nem sempre isso vai demandar poucos recursos.

 [Resumo]

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

 Professor:  Giovane Moura

EP 04. Ferramentas

Conteudo:

  Ler os conceitos de Cloud moderno:

 IaaS:

 PaaS:

 SaaS:

 FaaS:

 Portabildade: O uso de containers padroniza a infraestrutura e suas características e tras o beneficio da portabilidade e reduz os riscos de lock-in.

 O que é um container?

 Container é uma forma que eu consigo empacotar o meu sistema operacional e todas as minhas libs e runtime necessários para que meu código seja executado de forma consistente.

 “O objetivo do container é possibilitar que você execute o seu código de forma isolada e contida em um mesmo servidor.”

 Pesquisar:

 Namespace:

Introduzido em 2002, na versão 2.4.19 do kernel Linux, Namespace é uma feature que permite criar e lidar com diversos contextos em um mesmo sistema, vendo propriedades globais diferentes e isoladas em cada contexto. Para facilitar o entendimento, com namespace é possível criar um contexto (ou ambiente) de rede isolado do ambiente físico. Nesse novo contexto, existirão interfaces de rede física que não são visíveis no contexto do sistema; essas interfaces terão endereços físicos e lógicos diferentes do contexto do sistema e todo tráfego, regras de firewall, existentes nesse novo contexto, não são vistos por nenhum outro contexto, incluindo o contexto do sistema.

Essa é a feature que é utilizada para garantir isolamento. Embora exemplifiquei utilizando recursos de rede, existem diversos recursos que podem ser isolados utilizando namespaces. Os principais são:

·         Mount (mnt) namespace

·         Process identify (pid) namespace

·         Unix timesharing system (UTS) namespace

·         Network (net)namespace

·         inter-process comunication (IPC) namespace

·         user namespace

O Mount namespaces é responsável por criar um contexto isolado do sistemas para dispositivos que podem ser montados pelo sistema. Aqui, você pode observar que nem todo dispositivo montado no contexto físico deve ser disponibilizado para containers, ou algo que é montado em um container não deve ser também montado em outro. Precisa existir um isolamento e o mount namespaces garante isso para o recurso de dispositivos montados.

Além desses, existem também artigos que complementam a necessidade de isolar outros recursos encontrados nos sistemas Linux através de namespaces. Eles foram propostos e que ainda não foram implementados, como por exemplo:

·         time namespace

·         system log (syslog) namespace

Arquitetura de namespaces

A maneira que o sistema operacional irá criar e gerenciar namespaces depende principalmente da arquitetura de namespace que é implementado no kernel do sistema operacional. Existem duas arquiteturas básicas que os namespaces podem ser implementados: a arquitetura hierárquica e a não-hierárquica.

A arquitetura hierárquica relaciona os recursos em diferentes contextos. Geralmente os recursos dos novos contextos são relacionados com o contexto do sistema já criado. Embora os namespaces sejam isolados entre si, eles podem ser mapeados para que o contexto principal possa, de alguma maneira saber que existem outros contextos em execução. A Figura 1 demonstra como podem diferentes namespaces podem ser relacionados hierarquicamente.

Figura 1- Arquitetura hierárquica de namespaces

Para fins de exemplo, suponhamos que os círculos enumerados sejam processos. Na arquitetura hierárquica, os namespaces filhos (Child namespaces) foram originados do namespace pai (Parent namespace), e, com isso, estabeleceu-se uma hierarquia onde, os processos executados pelos filhos são mapeados através de processos no pai. Vale salientar que o identificar nos namespaces filhos são diferentes dos nomeados pelo namespace pai.

A arquitetura não-hierárquica não relaciona os recursos em diferentes contextos. Quanto mais simples for o recurso, mais candidato ele será a utilizar essa arquitetura (UTS, por exemplo). Nessa arquitetura os recursos do namespace filhos não são mapeados para o namespace que o criou (contexto de sistema, por exemplo).

Mas, qual das duas arquiteturas é utilizada atualmente?

Ambas. Dependendo do recurso que está se isolando atráves do namespace, uma ou outra arquitetura é utilizada. E isso pode ser visto em containers LXC e Docker: quando rodamos um processo dentro de um container LXC (um contexto LXC), ele pode ser visto fora do container (no contexto do sistema) pois foi mapeado.

O PID do processo no contexto do lxc será diferente do PID no contexto do sistema. Logo, o PID é um tipo de recurso que utiliza a arquitetura hierárquica em seus namespaces e nos recursos que ele isola.

Conclusão

Namespace é algo incrível, uma feature que alavancou o uso de containers. Existe outra técnina que permite um “isolamento do sistema”, como é o caso do chroot, mas a maneira que ele trabalha é primitiva e não permite integrar com outros elementos de controlo (como o caso do cgroups).

Somente essa pequena explanação já foi capaz de abrir os horizontes e entender como um container funciona e como seus recursos são isolados. Isso responde muitas das dúvidas mais frequentes como: Porque meu pendrive não aparece no meu container? porque minhas regras de firewall não são aplicadas no meu container?

Futuramente, pretendo explanar mais sobre o assunto, mostrando algo mão na massa (Show me code, show me commands!). Qualquer dúvida, ou comentário contrutivo, deixem logo abaixo.

 Cgroup:

 Os cgroups permitem alocar recursos — tais como tempo da CPU, memória do sistema, largura de banda de rede ou combinações destes recursos — entre grupos de usuários definidos de tarefas (processos) rodando em um sistema. Você pode monitorar os cgroups que configurar, negar acesso dos cgroups a certos recursos e mesmo reconfigurar seus cgroups dinamicamente em um sistema em execução. O serviço cgconfig (“control group config ”) pode ser configurado para iniciar no momento do boot e restabelecer seus cgroups pré definidos, fazendo-os persistentes através de reboots.

Usando cgroups, os administradores de sistema ganham controle refinado sobre a alocação, prioridades, negação, gerenciamento e recursos de monitoramento do sistema. Recursos de hardware podem ser divididos inteligentemente entre tarefas e usuários, aumentando a eficiência geral.

1.1. Como os Grupos de Controle são Organizados

Os cgroups são organizados hierarquicamente, como processos, e cgroups filhos herdam alguns atributos de seus pais. Entretanto, existem diferenças entre os dois modelos.

O Modelo de Processo do Linux

Todos os processos em um sistema Linux são processos filhos de um pai comum: o processo init, que é executado pelo kernel no momento de boot e inicia todos os outros processos (que por sua vez iniciam seus próprios processos filhos). Por causa que todos os processos descendem de um pai único, o modelo de processamento do Linux é uma hierarquia única, ou árvore.

Adicionalmente, todos os processos do Linux exceto o init herdam o ambiente (tal como a variável PATH) [1] e outros certos atributos (tal como abrir arquivos descritores) de seu processo pai.

O Modelo Cgroup

Os cgroups são similares aos processos em:

·         eles seguem uma hierarquia, e

·         Os cgroups filhos herdam certos atributos de seus cgroups pais.

A diferença fundamental é que muitas hierarquias diferentes de cgroups podem existir simultaneamente em um sistema. Se o modelo de processo Linux é uma árvore única de processos, então o modelo cgroup é uma ou mais árvores desconectadas e separadas de tarefas (exemplo: processos).

Múltiplas hierarquias separadas de cgroups são necessárias porque cada hierarquia é anexada a um ou mais subsistemas. Um subsistema [2] representa um recurso único, tal como tempo de CPU ou memória, O Red Hat Enterprise Linux 6 fornece nove subsistemas cgroups, listados abaixo por nome e função.

Subsistemas Disponíveis no Red Hat Enterprise Linux

·         blkio — este subsistema define limites de acesso de entrada/saída para e a partir de dispositivos de bloco tais como drives físicos (disco, estado sólido, USB, etc).

·         cpu — este subsistema usa o agendador para fornecer acesso às tarefas de cgroups para o CPU.

·         cpuacct — este subsistema gera relatórios automáticos nos recursos de CPU usados pelas tarefas em um cgroup.

·         cpuset — este subsistema atribui CPUs individuais (em sistema multicore) e nós de memória para atribuir em um cgroup.

·         devices — este subsistema permite ou nega acesso aos dispositivos por tarefas em um cgroup.

·         freezer — este subsistema suspende ou retoma tarefas em um cgroup.

·         memory — este subsistema define limites no uso de memória pelas tarefas em um cgroup e gera relatórios automáticos nos recursos de memória usados por essas tarefas.ol

·         net_cls — este subsistema marca os pacotes de rede com um identificador de classe (classid) que permite que o controlador de tráfego do Linux (tc) identifique os pacotes que originam de um cgroup em particular.

·         ns — o subsistema do namespace.

Nota

Você pode encontrar o termo controlador de recursos (resource controller) ou simplesmente controlador (controller) nas literaturas do cgroup tais como as páginas man ou documentação do kernel. Ambos destes termos são sinônimos com “subsistemas”, e partem do fato que um subsistema tipicamente agenda um recurso ou aplica um limite aos cgroups na hierarquia que está anexada.

A definição de um subsistema (controlador de recurso) é bem geral: é algo que age sobre um grupo de tarefas, como exemplo os processos.

 Chroot:

chroot é uma operação que altera o diretório raiz aparente para o processo atual de execução e seus filhos. Um programa que é executado em tal ambiente modificado não consegue acessar os arquivos e comandos fora dessa árvore de diretórios ambiental. Esse ambiente modificado é chamado de um prisão chroot (ou chroot jail).

Lançamento do Docker em 2013.

 Outros benefícios do uso de containers:

 - Infraestrutura imutável. (Stateless)

- Deployment muito mais rápido.

- Reuso da imagem do container por outras pessoas ou serviços.

- Versionamento do container.

- Portabilidade

- Visibilidade

- Share (compartilhável)

 “Coloca a imagem do container em um lugar único, compartilha, né? Essa é a ideia da colaboração ela é muito importante e ela também vai ser fator crucial para alavancar o seu negocio , seu aplicativo e etc.”

 Já existem Windows containers com IIS, DOTNET framework e etc.

 Para tratar das limitações de escala e proxy de acesso a aplicações em containers foi criado os orquestradores de containers:

 - SWAN

- MESUS

- KUBERNETES

 2013 o google começou a trabalhar com o desenvolvimento do Kubernetes com base no BORG.

 Kubernetes é um orquestrador de containers.

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

 Professor:  Renato Barbosa

EP 04. Construindo um modelo de machine learning

Conteudo:

 [Dados e Lake]

 1-      O objetivo do data lake é armazenar dados de qualquer natureza. (O volume deve ser considerado pois o data lake sempre vai crescer)

2-      Catalogar os dados armazenados. (Indexação dos dados armazenados no data lake)

3-      Governança dos dados. (Criar mecanismos de controle de acesso e proteção dos dados)

 [Construção do modelo] – Crisp DM

 1-      Identificar o problema que deve ser resolvido. Ir até a área de negócios e entender a fundo as caracteriscas do problema e identificar quais dados devem ser usados para resolve-lo.(Business Understanding)

2-      Levantar e entender quais dados serão necessários para resolver o problema de negocio. (Data Understanding)

3-      Preparar os dados. (Data Preparation) – Etapa de seleção dos dados necessários para auxiliar na resolução do problema de negocio. (Data preparation)

4-      Preparar o modelo de dados usando os dados coletados. (Modeling)

5-      Avaliar o modelo preparado na etapa 2. (Evaluation) – Se a avaliação não tiver a acurácia esperada, voltar para a etapa 1 para entender melhor o problema que deve ser resolvido.

6-      Com o modelo avaliado e acurácia aceita, realizar o deployment.

7-      Iterar. (Realizar o ciclo crisp de forma continua e sempre melhorando de alguma forma)

 [Feature engineering]

 Preparação dos dados de acordo com o modelo selecionado.

  [Principais fases]

 - Exploração dos dados.

- Treinar o modelo.

- Consumir o modelo de IA. (Batch, realtime e na borda)

 - Importante: Sempre monitorar.

 “Esse meu modelo esta performando como esperado? Ele esta respondendo de forma rápida? Ele esta tendo acurácia?”

 [Resumo]

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

 Professor:  Renato Barbosa

EP 05. Infraestrutura, frameworks e containers

Conteudo:

 Infraestrutura:

  Apesar das dependências de armazenamento em larga escala, conectividade e memoria em grandes quantidades, o principal compomente de Machine Learning continua sendo a capacidade computacional (CPU/GPU/TPU).

 Camadas de processamento:

 - Para algoritimos mais clássicos como os com base em estatística não é necessário o uso de GPUs ou TPU, basta um CPU comum para entregar o resultado esperado.

- Para algoritimos de redes neurais que demandam maior processamento de dados, recomenda-se o uso de GPUs. (Deep learning, visão computacional, NLT com bert, CNN, RNN ou LSTM)

- Para algoritimos de redes neurais que demandam maior processamento de dados, recomenda-se o uso de TPUs. (Deep learning, visão computacional, NLT com bert, CNN, RNN ou LSTM), a diferença neste cenário é que a TPU tem a capacidade de processar tensores.

- Para processamento de IA na borda (Celulares, câmeras, smart watches e etc) são empregados componentes como FPGAs.

 “Cada vez mais as unidades de processamentos estão se especializando na necessidade de treinamento de modelos de IA.”

 Framework:

 Do mesmo jeito que a camada de hardware e infraestrutura esta cada vez mais se especializando em processamento e treinamento de modelos de IA,  em software este cenário se repete com a criação dos 3 principais frameworks de mercado atualmente:

 - TensorFlow (Google):

 - Pythorch:

 - Mxnet(Apache): Amplamente utilizado pela AWS, é opensource 100% e possui as seguintes características:

 - Especializado em escala.

 Ferramentas:

 - Scikit learn: Utilizado especialmente para treinamentos de machine learning.

- Gluon:

- Keras:

  Containers:

 Da mesma forma que outras aplicações utilizam os containers para facilitar na hora de levar o código para produção, atualizar versões e etc, com machine learning não é diferente, containers vem sendo grandes parceiros de desenvolvedores em todos os sentidos e grandes aliados de operações por manterem seus estados.

- Volume de dados pode ser um problema quando utilizar containers.

 [Arquitetura básica de ML]

  [Resumo]

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

 Professor:  Renato Barbosa

EP 06. Explorando dados e preparando o treinamento

Conteudo:

 Ferramentas de desenvolvimento:

 Jupyter Notebook:

 •Plataforma de desenvolvimento de código

• Une texto e código

• Visualização simplificada

• Execução por pedaços

• Debuging

• Suporta JUlia, PYThon & R = JUPYTER

 Esta é uma ferramenta mais utilizada na exploração dos dados.

 R Studio:

 Muito utilizado para fazer analise estatística dos dados.

 • Plataforma de analises estatísticas

• Simplifica desenvolvimento estatistico

• Visualização gráfica simplificada

• Execução por pedaços

• Debuging

• Suporta R

 [ Preparação de dados ]

 De uma forma muito direta, 80% do tempo gasto por um cientista de dados é preparando o dado para ser consumido ou inferido.

  “O trabalho mais duro e mais pesado é preparar o dado.”

 [Feature engineering]

  [Segregação de dados]

 Preparar o treinamento e segregação dos dados que serão utilizados para treinar e para validar o modelo treinado.

 • Divisão do dataset para treinamento:

• Treinamento – 60% - 90%

• Validação – 40% - 10%

• Treinamento – 60% - 80%

• Validação – 20% - 10%

• Teste - 20% - 10%

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

 Professor: Yuri Diogenes

EP 03. Modelagem de ameaças

Conteudo:

 O que é?  É uma técnica de desenho criada para auxiliar arquitetos de software a identificar problemas de segurança logo no começo de desenvolvimento.

O ideal é utilizar deste o começo do desenvolvimento e ser aplicado a casa fase do projeto afim de garantir sempre que o software esta mantendo o nível de segurança adequado.

 “Nada melhor que fazer o threat modeling a cada fase . A gente vai fazer logo no começo e depois quando você adicionar novos componentes você vai aplicar novamente. Fazer novamente outro threat modeling.”

 O threat modeling é uma ferramenta que deve ser adotada por toda equipe, pois demanda diferentes competências e experiencia para criar o modelo adequado de ameaça.

 Categorização dos tipos de ameaça utilizando o STRIDE:

 STRIDE Definição: STRIDE é um modelo de ameaças desenvolvido por Praerit Garg e Loren Kohnfelder da Microsoft para identificar ameaças à segurança do computador. Ele fornece um mnemônico para ameaças à segurança em seis categorias. As ameaças são: Spoofing Adulteração Repúdio Divulgação de informação Negação de serviço.

 Spoofing: Acesso ilegal a um sistema.

Tempering: Modificação maliciosa do dado.

Repuditation: O sistema precisa ter logs suficiente para criar mecanismos de auditoria.

Information disclosure: Exposição de informação indevida por não utilizar mecanismos suficientes para conter ou não permitir este vazamento ou interceptação.

Denial of service: Causar a indisponibilidade do serviço. DDoS.

Elevation of privilegie: Falha de segurança que permite a elevação do privilegio.

 Exemplo de ferramentas de threat modeling:

 - Microsoft theat modeling tool: https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling

 [Resumo]

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

 Professor: Yuri Diogenes

EP 04. Etapas do Threat Modeling

Conteudo:

 1-      Identificar os Assets

2-      Criar a arquitetura

3-      Decompor a aplicação

4-      Identificar as ameaças. (O Desenho começa aqui)

5-      Priorizar as ameaças

    Criar uma arvore do ataque:

Estabelecendo a prioridade das correções usando DREAD:

  [Resumo]

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

Professor: Evandro Melo

EP 03. Tipos de Cloud

Conteudo:

“Tudo que eu consigo fazer dentro de um ambiente de TI tradicional eu consigo obter no Cloud de forma elástica, escalonável, sob demanda e self-service.”

·         Cloud possui 5 Caracteristicas:

 1.       On-Demand e Self-service.

 On-demand self-service. O consumidor pode sozinho provisionar recursos computacionais, como servidores e armazenamento, conforme necessário e sem a necessidade de interação com o provedor de serviço.

  2.       Amplo acesso a rede. (Acesso via internet de qualquer lugar)

Amplo acesso à rede. Recursos disponíveis na rede sendo possível o acesso através de meios comuns de conectividade.

  3.       Recursos compartilhados. (Ganho em escala e menor custo pelo compartilhamento)

Recursos compartilhados. Os recursos de computação sãocompartilhados para atender vários consumidores no modelo multi-tenant , com diferentes recursos físicos e virtuais disponibilizados dinamicamente de acordo com a demanda. Há uma sensação de independência de localização em que o cliente geralmente não tem controle ou conhecimento sobre a localização exata dos recursos fornecidos, mas pode ser capaz de especificar a localização em um nível mais alto de abstração.

 4.       Elasticidade rápida. (Crescimento e diminuição do ambiente)

Elasticidade rápida. Os recursos podem ser elasticamente provisionados e liberados, em alguns casos automaticamente, para escalar rapidamente para cima e para baixo de acordo com a demanda. Para o consumidor, os recursos disponíveis para provisionamento muitas vezes parecem ser ilimitados e podem ser apropriados em qualquer quantidade e a qualquer momento.

 5.       Serviços mensuráveis de forma granular.

Serviços mensuráveis. Os sistemas em cloud controlam e otimizam automaticamente o uso de recursos, alavancando uma capacidade de medição em um nível de abstração apropriado para o tipo de serviço (armazenamento, processamento, largura de banda e contas de usuário ativas). O uso de recursos pode ser monitorado, controlado, proporcionando transparência tanto para o provedor quanto para o consumidor do serviço utilizado.

“Você consegue saber exatamente aquilo que você vai usar, o que vai crescer, o quanto você vai crescer e o quanto vai custar.”

 3 Modelos de serviços:

 Analogia dos modelos de serviço do Cloud:

Iaas: É o mesmo que comprar um carro, ter que dirigir e arcar com todos os custos dele.

PaaS: É como alugar um carro, você ainda precisa dirigi-lo, mas não precisa mais arcar com os custos de mante-lo.

Saas: É o mesmo que utilizar um Uber como meio de transporte, você só utiliza o veiculo mas não precisa dirigir e nem arcar com os custos de mante-lo

   Definição real dos modelos de serviço:

1.       Iaas:

Infrastructure as a Service (IaaS). Modelo de serviço que fornece ao cliente acesso a

processamento, armazenamento, redes e outros recursos de TI essenciais para implantar cargas de trabalho. O provedor de Cloud gerencia a infraestrutura até a camada

de virtualização e o cliente gerencia tudo que estiver acima desta camada, como Sistema Operacional, Aplicações, Customização de segurança.

 Vantagens

Menor despesa de capital com hardware e software básicos;

Mais fácil adoção e migração de ambiente On-Premises;

Escalabilidade alta e simples;

Maior poder de customização e controle dos componentes.

 Desafios

Necessidade de time qualificado em infraestrutura;

Atenção com segurança e manutenção;

Custo a longo prazo potencialmente maior.

   2.       PaaS:

Platform as a Service (PaaS).

Modelo de serviço que fornece uma plataforma com diversos componentes gerenciados para que o cliente desenvolva e/ou customize suas aplicações de negócio.

O cliente não gerencia ou controla a infraestrutura de Cloud, como rede, servidores, storage ou sistema operacional, e pode dar foco nas aplicações. É um nível maior de abstração da camada de infraestrutura.

Como o IaaS, que abstrai as camadas de Data Center e evita que as empresas

tenham que possuir e gerenciar seus próprios servidores, o PaaS vai além e

entrega outros serviços gerenciados, como a camada de infraestrutura do banco

de dados, middleware e sistema operacional.

Alguns serviços e plataformas podem ir além e integrar serviços de Inteligência

Artificial, Analytics, entre outros.

A demanda sempre crescente por PaaS pode ser atribuída à automação. Com a PaaS, os desenvolvedores não precisam mais configurar o ambiente manualmente. Isso garante a liberdade de criar seu aplicativo sem gastar horas construindo a estrutura e sem gastar dinheiro em licenças de software e hardware.

Exemplos:

 aPaaS: Application Platform as a Service, fornece ambientes de desenvolvimento e implantação para aplicações.

Por exemplo:  

SalesForce, Heroku, Mendix, Zoho.

 dbPaaS: DataBase PaaS é um serviço de gerenciamento de banco de dados ou armazenamento de dados, projetado para ser elástico, escalável e com autogerenciamento.

Por exemplo:

Amazon Aurora, Google BigQuery, Microsoft Azure

SQL Database.

 iPaaS: Integration PaaS é um serviço que permite a integração com diferentes sistemas

de forma simples, escalável e centralizada.

Por exemplo:

APIPASS, Mulesoft, Amazon AppFlow.

 APImPaaS: As plataformas de gerenciamento de API executam diversas funções como análises, relatórios de uso, documentação e gerenciamento de autorização, gerenciamento de faturamento e pagamento.

Exemplo:

Google Cloud EndPoint, Mashery, Sensedia, MS Azure API Management,

Amazon API Gateway.

cPaaS: Communication PaaS é uma plataforma que permite às empresas iniciar comunicação em tempo real com usuários de sites e aplicativos sem ter que construir

interfaces e infraestrutura de back-end. Chamadas de voz e vídeo, bate-papos em grupo e conferências, mensagens no aplicativo, notificações push, SMS, entre outros.

Exemplo:

Twilio, Nexmo, Plivo, Avaya, VoxImplant.

 fPaaS: Function PaaS é um serviço que possibilita aos clientes desenvolver, rodar e gerenciar aplicações sem a necessidade de configurar e gerenciar infraestrutura, como

servidores virtuais. Por isso também conhecido como Arquitetura Serverless (sem servidor), muito utilizados em estratégias de microserviços.

Exemplo:

AWS Lambda, Google Cloud Functions, MS Azure Functions.

 3.       SaaS:  Software as a Service (SaaS).

É um modelo de serviço que prove uma aplicação baseada em Cloud ao usuário final,

sem a necessidade de instalar e gerenciar nenhuma infraestrutura, como servidores,

armazenamento, redes e Sistema operacional.

 O modelo SaaS é uma alternativa ao modelo tradicional de compra de licença de

Software. Solução ‘pronta para o uso’, com modelos diferenciados de contratação,

geralmente como uma assinatura, com métricas específicas como: usuário individual

ou concorrente, volume de armazenamento, volume de transações, entre tantos

outros.

 Exemplos:

CRM: SalesForce;

ERP: SAP, TOTVS, SENIOR;

E-commerce: VTEX;

E-mail: Office 365, Gmail.

 Principais vantagens:

q     Redução de custo de licenciamento

q Abstração e redução do custo de manutenção do software

q Redução do custo de atualização do software

q Adoção mais acelerada de novas tecnologias

 Os 4 Modelos de implantação de Cloud:

• Cloud Pública

Cloud pública. A infraestrutura é fornecida para uso aberto pelo público em geral. Pode ser de propriedade, administrado e operado por uma organização empresarial, acadêmica ou governamental, ou alguma combinação deles.

 Fly wheel – Desenho idealizado pelo Jeff Bezzos quando estava buscando investimento para desenvolver um modelo de negócio que se retro estimula.

 Líderes:

AWS - Amazon Web Services

Microsoft Azure

GCP - Google Cloud Plartform

 Nichos:

Alibaba Cloud

Oracle Cloud Infrastructure

IBM Cloud

Tencent Cloud

   • Cloud Privada

A cloud privada é uma infraestrutura de data center virtualizada que atende aos requisitos de cloud computing, para um único cliente.

São desenvolvidas e gerenciadas por uma única empresa para atender sua própria demanda.

Com cloud privada a empresa consegue uma maior autonomia de controle e governança de ponta a ponta.

 [Tecnologias]

 - Vmware

 Vmware entrega uma experiência centralizada de gerenciamento, otimização de capacidade, análise de log em tempo real, análise preditiva de dados

estruturados e não estruturados possibilitando ações proativas de

mitigação de problemas e/ou rápida resolução de problemas.

 vSphere

vRealize Suite

vCloud Suite

  - Redhat

 O Red Hat Cloud Suite combina tecnologias integradas da Red Hat que que permite às

empresas criar uma infraestrutura em cloud e desenvolver aplicações nativas em cloud onpremise.

 Red Hat OpenStack Platform

Red Hat Virtualization

Red Hat Satellite

Red Hat OpenShift

   • Cloud Híbrida

Uma Cloud Híbrida é uma combinação de uma Cloud Privada com o uso de serviços de Cloud Pública onde um ou vários pontos de contato existem entre os ambientes.

O objetivo é combinar serviços e dados de uma variedade de modelos de cloud para criar um ambiente de computação unificado, automatizado e bem gerenciado.

Uma Cloud Híbrida é um ambiente onde os serviços privados e públicos são usados juntos para criar valor.

 Cloud Híbrida é:

Uma empresa que usa uma plataforma de desenvolvimento pública que envia dados para uma Cloud Privada.

Uma empresa que utiliza uma série de aplicativos SaaS e move dados entre recursos

privados.

Quando um processo de negócios é projetado como um serviço para que possa se

conectar a ambientes como se fossem um único ambiente.

Cloud Híbrida não é:

Se alguns desenvolvedores em uma empresa usam um serviço de Cloud Pública para

fazer o protótipo de um novo aplicativo que está completamente desconectado da

Cloud Privada ou do data center.

Se uma empresa estiver usando um aplicativo SaaS para um projeto, mas não houver

movimento de dados desse aplicativo para o data center da empresa.

Uma empresa que usa serviços de dois ou mais provedores de Cloud Pública.

• Cloud Comunitária

A infraestrutura de cloud é fornecida para uso exclusivo por uma comunidade  específica de consumidores de organizações que compartilham preocupações (por exemplo, missão, requisitos de segurança, política e considerações de conformidade).

Pode ser de propriedade, administrado e operado por uma ou mais organizações na comunidade, um terceiro, ou alguma combinação deles, e pode existir dentro ou fora das instalações.

• Multi-Cloud (este não é um modelo de implantação, mas é uma modalidade que esta sendo muito utilizado)

 Adoção de dois ou mais provedores de cloud pública para distribuição de cargas de trabalho entre os provedores.

Geralmente é associado a ter mais flexibilidade e não criar dependência de um único provedor de Cloud.

 Desafios

q Maior complexidade na governança dos ambientes;

q Necessidade de treinamento da equipe em mais de um provedor de Cloud;

q Perda do ganho em escala;

q Necessidade de balizar serviços, optando por serviços básicos e não avançados;

q Maior custo de transferência de dados entre Clouds.

Casos de uso

 Cloud Privada

q Clientes Enterprise com Data Center próprio ou colocation que busca

entregar mais flexibilidade e autonomia às diferentes áreas de negócio,

evitando o ‘shadow IT’. (Quando o TI impacta na dinâmica da empresa)

q Permite maior granularidade e metrificação dos componentes de

infraestrutura para cobrança das diferentes áreas e centro de custos.

q Importante garantir infraestrutura suficiente para escalar rápido.

Cloud Hibrida

Disaster recovery de ambiente on-premises na Cloud.

Integração de ambiente de baixa latência (ex.: chão de fábrica) com serviços

em Cloud.

Transbordo de infraestrutura local, para atender picos e rápido crescimento.

Transformação digital faseada e integrada.

 [Resumo]

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

Professor: Evandro Melo

EP 04. A escolha da Cloud

Conteudo:

 “A transformação esta acontecendo, ou você se transforma ou vai ficar para trás. E a Cloud apoia muito, neste sentido, neste caminho da transformação digital”.

 O principal motivo pelo qual os clientes optam por migrar para a cloud é a agilidade que ganham. Implementação em minutos em vez de meses.

Além da agilidade, outros motivos comuns pelos quais os clientes migram para a cloud incluem aumento de produtividade, consolidação de data center, redução de investimento em ativos.

Algumas empresas querem repensar completamente seus negócios como parte de uma transformação digital.

E, é claro, as organizações estão sempre procurando maneiras de reduzir custos.

 Os direcionadores comuns que se

aplicam ao migrar para a cloud são:

 Custos operacionais - Custos de funcionamento da infraestrutura.

Produtividade da força de trabalho - a produtividade da força de trabalho é a eficiência com que você consegue colocar seus serviços no mercado.

Otimização de custos – Criar um ambiente que não tenha custos desnecessários e

ociosos.

Resiliência operacional – Reduzir o risco da sua organização e o custo da mitigação de

risco.

Agilidade de negócios - Capacidade de reagir rapidamente às mudanças nas condições

do mercado.

   Como definir o modelo e o provedor de Cloud?

 1-      Estrategia de carga de trabalho: (Estrategia dos 6Rs)

Rehost(Lift and shift) - IaaS

Mover suas cargas de trabalho sem alterações. Em migrações legadas emgrande escala, as organizações buscam se mover rapidamente para atender aos objetivos de negócios.

A maioria dos rehosting pode ser automatizada com ferramentas. Alguns clientes preferem fazer isso manualmente enquanto aprendem como aplicar seus sistemas legados à nova plataforma de cloud.

Pode ser mais fácil otimizar ou refazer a arquitetura, uma vez que já está em execução na cloud. Em parte porque sua organização terá desenvolvido as habilidades para fazer isso, e em parte porque a parte difícil - migrar a carga de trabalho, os dados e o tráfego - já foi feita.

 Replatforming (Lift and reshape) – Utilizar PaaS

Fazer algumas otimizações na cloud para obter um benefício tangível, sem mudar a

arquitetura central da carga de trabalho.

Por exemplo, reduzir a quantidade de tempo que se gasta gerenciando instâncias de banco de dados migrando para uma plataforma de banco de dados como serviço (dbPaaS) ou migrando um aplicativo para uma plataforma totalmente gerenciada (aPaaS), utilizando serviços de contêiner. Ou ainda aproveitar a migração para adotar tecnologias abertas ao invés de manter soluções proprietárias.

  Repurchasing (Replace – drop & shop) – SaaS.

 Recompra - Mudar o modelo de licenciamento, onde é necessário a compra, instalação e gerenciamento, para um modelo de software como serviço.

Por exemplo, mudar de servidor de e-mail para Office 365, adotar Salesforce.com como seu CRM, Senior Sistemas como solução de RH.

 Refactoring - (Re-writing/ Decoupling applications) – Maior esforço, mas maior resultados ao longo prazo.

 Repensar como o aplicativo é arquitetado e desenvolvido usando recursos nativos da cloud. Impulsionado pela necessidade do negócio de adicionar recursos, escala ou desempenho que, de outra forma, seria difícil de alcançar no ambiente legado.

Por exemplo, migrar de uma arquitetura monolítica para uma arquitetura orientada a micro-serviços para aumentar a agilidade ou melhorar a continuidade dos negócios.

Essa estratégia tende a ser a mais cara, mas também pode ser a mais benéfica para uma boa adequação do produto ao mercado.

 Retire

 Remover as cargas de trabalho que não são mais necessárias.

Cerca de 10% a 20% do ambiente de TI corporativo não é mais útil e pode ser desativado. Essa economia pode impulsionar novos negócios, direcionar a atenção da

equipe e reduzir a complexidade na gestão.

 Retain - ( Referred to as re-visit.)

 Mantenha as cargas de trabalho que são críticas para os negócios, mas que requerem uma grande refatoração antes que possam ser migrados. Ou ainda aplicações que necessitem permanecer no local, como integração com chão de fábrica, por exemplo.

Essas aplicações podem ser revisitadas posteriormente.

2-      Bechmark

• Forrester

 A Forrester é uma empresa norte-americana de pesquisa de mercado, atuando há mais de 35 anos, que presta assessoria sobre o impacto existente e potencial da tecnologia para seus clientes e o público.

 Forrester Wave

Um guia para tomadores de decisão no mercado de tecnologia.

Usa uma metodologia transparente para comparar os participantes em um mercado

de software, hardware ou serviços para que os profissionais possam tomar decisões

bem informadas sem gastar meses conduzindo suas próprias pesquisas.

Oferece dois benefícios principais aos clientes: uma análise detalhada dos produtos e

serviços dos fornecedores, com base em critérios transparentes, e uma planilha Excel

que permite aos clientes comparar produtos e desenvolver listas personalizadas de acordo com seus próprios requisitos.

 • IDC

 International Data Corporation (IDC) é uma fornecedora global de inteligência de mercado, serviços de consultoria e eventos para o mercado de TI, telecom e tecnologia do consumo, com mais de 50 anos no mercado.

Possui mais de 1100 analistas com entrega de análises globais, regionais e locais, em mais de 110 países.

 “IaaS como espinha dorsal nas organizações no processo de transformação digital e modernização de TI.

Com ritmo de crescimento de mais de 30% ano após ano.

Nos próximos 5 anos, o IDC estima que os gastos com IaaS em Cloud Pública superem os gastos com infraestrutura tradicional e Cloud Privada.”

  IDC - CONSELHOS PARA

COMPRADORES DE TECNOLOGIA

Os serviços de infraestrutura de Cloud Pública cresceram para se tornarem um componente integral e aceito do ambiente de TI corporativo. O uso mais amplo dos serviços de infraestrutura de Cloud Pública permitirá a criação de uma base digital ágil, escalável e resiliente para as organizações.

* As organizações devem investir ativamente na transformação relacionadas ao processo que possam atuar como barreiras para uma adoção mais ampla da cloud.

 IDC MARKETSCAPE

 O IDC MarketScape se concentra em provedores de IaaS de Cloud Pública global, que atingiram um limite crítico de receita e estão presentes em todas as regiões globais.

Os critérios de inclusão para provedores de serviços incluídos no IDC MarketScape:

 ▪ O provedor de serviços ofereceu serviços de computação e armazenamento de IaaS por pelo menos dois anos.

▪ O provedor de serviços gerou mais de US $100 milhões de negócios de IaaS no último ano.

▪ O provedor de serviços tem operações ativas em todas as regiões globais — Américas, Europa, Oriente Médio e África, e Ásia/Pacífico.

 O IDC divide a análise em duas categorias principais: Capacidade e Estratégia.

O posicionamento do eixo Y (Capacidade) reflete a capacidade atual do provedor, o

portfolio de serviços e quão bem alinhado o provedor está às demandas dos clientes.

O posicionamento do eixo X (Estratégia), indica o quão bem o provedor está em

relação a estratégia de futuro. Como está preparado para atender as demandas dos

clientes nos próximos três a cinco anos.

O tamanho do marcador representa a fatia de mercado (market-share) de cada provedor.

• Gartner

 Fundado em 1979, empresa líder em pesquisa e consultoria de TI.

Fornece insights de negócios, conselhos e ferramentas para todos os líderes das empresas, em todos os segmentos.

 Cerca de 16.000 associados;

Presentes em 100 países, incluindo Brasil;

 • Gartner Hype Cycle

 O Gartner Hype Cycle fornece uma representação gráfica da maturidade e adoção de tecnologias e como são potencialmente relevantes para resolver problemas reais de negócios e explorar novas oportunidades.

A metodologia Gartner Hype Cycle oferece uma visão de como uma tecnologia evoluirá ao longo do tempo, fornecendo uma fonte de insights para gerenciar sua implantação dentro do contexto de seus objetivos de negócios.

 • Gartner Score

 A metodologia de diagnóstico Gartner Score fornece um conjunto de avaliações de maturidade com objetivo de apoiar os executivos a medir, priorizar e melhorar desempenho de atividades críticas.

Mapear dentro da organização quais áreas e processos possuem lacunas críticas entre maturidade e as prioridades de negócios.

BOM PARA: Otimizar recursos e esforços em atividades que estão alinhadas aos objetivos de negócio, buscando aumentar a maturidade da área e processos.

 • Magic Quadrant

 O Quadrante Mágico fornece um gráfico com o posicionamento competitivo, com quatro tipos de provedores de tecnologia:

 Os líderes executam bem sua visão atual e estão bem posicionados para o futuro.

Os visionários entendem para onde o mercado está indo ou têm uma visão para mudar as regras do mercado, mas ainda não executam bem.

Os provedores de nicho focam com sucesso em um pequeno segmento ou estão fora de foco e não inovam ou superam os outros.

Os desafiadores executam bem hoje ou podem dominar um grande segmento, mas não demonstram uma compreensão da direção do mercado.

 Os recursos interativos do Quadrante Mágico do Gartner permitem que as empresas

criem uma visão para refletir suas próprias metas, necessidades e prioridades de

negócios.

Os recursos interativos permitem que a empresa ajuste as ponderações aplicadas a

cada um dos critérios de avaliação para gerar um novo gráfico do Quadrante Mágico

específico para aquele mercado.

A empresa pode salvar e compartilhar os Quadrantes Mágicos personalizados para

suas análises internas e tomadas de decisão.

O Quadrante Mágico interativo também reúne a opinião de especialistas do Gartner e

as avaliações de usuários do Peer Insights.

A guia User Review permite que você leia e avalie o que seus colegas têm a dizer

sobre as soluções corporativas de TI que implementaram e usam em suas empresas

diariamente.

 Os Quadrantes Mágicos ajudam:

Aprender rapidamente sobre os fornecedores de tecnologia concorrentes de um mercado e sua capacidade de fornecer o que os usuários finais exigem hoje e no futuro.

Entender como os provedores de tecnologia de um mercado estão posicionados competitivamente e as estratégias que estão usando para competir pelo negócio

do usuário final.

Comparar os pontos fortes e os desafios de um provedor de tecnologia com suas necessidades específicas.

São mais de 200 Quadrantes Mágicos.

Gartner Magic Quadrant – 2020

Líderes:

AWS - Amazon Web Services

Microsoft Azure

GCP - Google Cloud Plartform

 Nichos:

Alibaba Cloud

OCI – Oracle Cloud Infrastructure

IBM Cloud

Tencent Cloud

[Resumo]

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

Professor: Caio Pereira

EP 04.  Automação

Conteúdo:

Os 3 pilares do DevSecOps são: Conceito, gestão de conflitos e automação.

Para ter um ambiente sustentável de DevSecOps operando no dia a dia, é imprescindível ter automação dos processos.

- Automação em:

 1-      Provisionamento de infraestrutura.

2-      Geração de build de código.

3-      Validação e testes.

4-      Validação de segurança.

 [Tecnicas de automação]

 Automatize tudo que for possível e que não traga risco.

 Alguns processos de segurança precisam ser manuais como o penetration test.(PenTest);

[Piramide de testes de segurança]

Dica: Invista mais nos testes da base da pirâmide que naturalmente haverá menor necessidade de investir em testes mais no topo dela.

“Quanto mais você demora para encontrar um problema, mais caro é para resolve-lo.”

 SAST – Static Application security testing. (Teste de caixa branca)

Ferramenta exemplos: Sonar Qube.

- Avalia todo o conteúdo do código fonte de uma aplicação.

- Busca por más práticas de codificação. (ex: atributos como public)

- Não simula ataques.

- Baixo custo

- Falsos positivos são comuns.

 DAST – Dynamic Application security testing. (Teste de caixa preta)

Ferramentas: Fortify, Burp Suite.

- Teste de caixa preta – Não tem acesso ao código fonte da aplicação.

- Simula ataques comuns a uma aplicação.

- Exemplos de ataques simulados: SQL injection, DDoS, XSS(Injeção de código de execução na camada do usuário, javascript).

- Possui custo elevado.

- Apresenta menos falsos positivos se comparado ao método SAST.

 Cross-site scripting (XSS) é um tipo de vulnerabilidade do sistema de segurança de um computador, encontrado normalmente em aplicações web que ativam ataques maliciosos ao injetarem client-side script dentro das páginas web vistas por outros usuários.

 Mast – Mobilie Application security testing.

 Aplicações mobile possuem algumas particularidades em especial.

 - Rodam em diversos tipos de aparelhos (devices).

- Estão em uma rede aberta (4G), estão mais expostos.

- Dados devem ser armazenados de forma segura nestes aparelhos, para evitar que outros aplicativos tenham acesso a estes.

“Quando se trata ou fala de aplicativos mobile deve-se tomar o dobro de cuidado.”

Ferramentas para trazer maior segurança para o código fonte:

 - Ofuscação de código.

- Muito importante ter testes manuais em aplicativos novos.

 Container image scanning (Ex: Aqua Security)

 - Imagens de containers carregam código e sistema operacional em um único artefato.

- Executa verificações para avaliar se existem brechas para invasão. Ex: porta ssh aberta.

- Verifica ferramentas instaladas no container que podem trazer risco. Ex: bash shell

 A ideia final de tudo isso é, incluir todas estas ferramentas na esteira(pipeline) de desenvolvimento do DevSecOps, ou seja, aplicar todas estas ferramentas e conceitos de forma automatizada para entregar software seguro de qualidade de forma continua e automatizada com baixo esforço e custo.

 Code -> Commit -> Build -> Roda o SAST -> constrói o aplicativo -> faz deploy -> roda o dast.

 Com isso você terá um feedback de segurança continuo e deve entregar mais software com segurança e qualidade.

 Ferramentas e site de referencia: https://owasp.org/www-community/Source_Code_Analysis_Tools

 [Resumo]