Inicial > Não categorizado > Meus apontamentos sobre a prova CLO-001–Cloud Essentials da CompTIA–Capitulo 3

Meus apontamentos sobre a prova CLO-001–Cloud Essentials da CompTIA–Capitulo 3

Saudações,

Hoje vamos entrar nos apontamentos do terceiro capítulo do livro “Cloud Essentials – Preparatório para a prova CLO-001”. Apontamentos estes que fiz durante meu período de estudos.

Reitero que essa série de posts foi autorizada pelo autor Yuri Diógenes.

Nenhuma imagem do livro será compartilhada aqui. Recomendo a aquisição do mesmo. Caso se interesse, me procure que posso lhe ajudar.

A quem está chegando agora, comecei no dia 12/02 essa série com a introdução onde faço algumas considerações e coloco os objetivos da prova. Além disso você pode acessar todos os volumes desta nos links abaixo:

Meus apontamentos sobre a prova CLO-001 – Cloud Essentials da CompTIA – Introdução

Meus apontamentos sobre a prova CLO-001 – Cloud Essentials da CompTIA – Capitulo 1

Meus apontamentos sobre a prova CLO-001 – Cloud Essentials da CompTIA – Capitulo 2

Cap 3 – Perspectiva Técnica dos Tipos de Nuvem

O Foco do capítulo é estabelecer a diferença técnica entre os principais tipos de nuvem e explicar o funcionamento básico e as técnicas para realizar a implementação da nuvem.

Aqui também veremos os principais riscos da computação em nuvem e descreve o impacto da computação em nuvem nas aplicações e processos de desenvolvimento. Relembrando que a parte de riscos é muito falada no fim do livro e diversos cenários com esses riscos caem na prova.

Diferenças entre Nuvem Privada e Publica do ponto de vista técnico:

Privada: utilizada por uma única organização. Pode ser administrada por ela própria ou por terceiros e estar (ou não) em instalações próprias. O serviços afetados são de uso da própria organização. Construída para funcionar utilizando os recursos dos datacenters empresariais. Traz uma facilidade maior no que tange a segurança e arquitetura de dados, exatamente por ser privada.

Pública: Suporta arquitetura Multitenancy (multi-inquilino), na qual todos os usuários e aplicativos compartilham uma única infraestrutura e a base de códigos é mantida centralmente. As implantações individuais de aplicativos em arquitetura Multi tenant ocupam partições virtuais, em vez de pilhas físicas separadas de hardware e software. Mesmo sendo interessante, essa arquitetura pode trazer problemas para a segurança dos dados.

Multi tenant – Compartilhamento da mesma infraestrutura física e versão de aplicativos

Single tenant – Infraestrutura própria e única para o dono da nuvem privada

Guardem bem: O armazenamento de dados pessoais do cliente em um provedor de serviços é um dos riscos da computação em núvem – você verá os autores explanando sobre este tema de forma detalhada no decorrer do ultimo capitulo do livro.

De maneira geral, a nuvem privada é utilizada como alternativa à nuvem pública quando há a necessidade de níveis mais rigorosos de segurança e privacidade, ou de garantia de disponibilidade da aplicação. – se lembrarem do que compartilhei aqui nos primeiros volumes da série, alguns dados muito confidenciais podem fazer com que nem tudo da empresa seja migrado para a nuvem, tornando a opção da nuvem privada como solução ou até mesmo ficando em ambiente on-premisses.

O crescimento da adoção de nuvens privadas está sendo influenciado pelo aumento da oferta de soluções com este foco, pela rápida expansão da vitualização e pela pressão por implantações rápidas e baratas de TI.

Técnicas e métodos de distribuição de Computação em nuvem:

  1. Rede
  2. Automação
  3. Federação
  4. Padronização

Rede: mesmas técnicas do que é utilizado em redes convencionais. O que muda na nuvem é que a camada de rede passa a ser uma abstração (web services) permitindo utilizar os componentes de rede de forma mais simples e ágil.

Ao se implementar aplicações em nuvem, a solução de rede utilizada deve permitir manter o controle completo sobre a configuração do endereçamento IP. Isso significa que deve ser possível continuar a usar o seus esquemas de endereçamento atuais e se conectar a rede IP já existentes.

Um outro exemplo de rede na nuvem é o uso de um dispositivo de hardware à sua escolha para estender sua rede empresarial para a núvem pública com segurança usando uma VPN – integrando a infra existente com os recursos de rede em nuvem.

Automação: (Self-Service) – é a capacidade de prover funcionalidades computacionais de maneira automática, sem que haja necessidade do usuário interagir com o provedor de serviço. Provedores têm direcionado esforços no sentido de fornecer elasticidade nos recursos de seus clientes – um dos pontos lá do começo da série em que disse que os autores reforçam bastante.

Ex: Auto Scaling da Amazon AWS – util para aplicativos que apresentam variabilidade de uso por hora, dia ou semana, escalando a capacidade do servidor virtual para cima ou para baixo de acordo com as condições que o contratante define.

Federação: A federação de identidade permite que clientes habilitados usem suas identidades existentes (usuários, por exemplo) para ter acesso seguro a API´s de determinada núvem e outros recursos usando controles provenientes do seu sistema de identidade e acesso, sem a necessidade de criar um usuário específico para cada identidade.

SSO (single sign-on) – A idéia da federação é que os funcionários façam login uma única vez em seu diretório corporativo e depois usem recursos de nuvem sem ter que fazer login novamente.

O SSO possibilita o reuso das políticas existentes de acesso a aplicativo, para controlar o acesso acesso a aplicativo SaaS. A integração do serviço de diretório com a aplicação SaaS significa que uma determinada ação não precisará da confirmação de usuário e senha.

Segundo a Microsoft, os aplicativos SaaS podem fornecer autenticação SSO pelo uso de um serviço de federação na rede do cliente que faz interface com o serviço de diretório do usuário da própria empresa do cliente. Deverá existir uma relação de confiança entre o servidor de federação do cliente e do provedor do aplicativo SaaS.

Para ter acesso ao aplicativo, o servidor de federação da empresa autentica o usuário localmente e negocia com o servidor de federação SaaS para fornecer ao usuário um token de segurança aceito pelo sistema de autenticação do provedor SaaS, que o utiliza para dar acesso ao usuário.

Padronização: Existem muitas normas para a computação em nuvem. O problema é que há uma profusão delas e muitas pessoas não sabem o que eles significam. Apensar da diversidade normas e definições, caminha-se para uma consolidação por meio de várias entidades que se destacam:

  1. Cloud Security Alliance
  2. IEEE Standards Association – Institute of Electrical and Electronics Engineers
  3. DMTF – Distributed Management Task Force
  4. NIST – National Institute of Standards and Technology

A padronização dos formatos é importante para facilitar o movimento de dados entre provedores de serviço de nuvem.

Desafios técnicos e Riscos da Computação em Nuvem:

1.Falta de interoperabilidade e aprisionamento: Quando os modelos adotados pelos fornecedores de computação em nuvem são integrados verticalmente e limitam a escolha da plataforma.

2. Incompatibilidade de aplicações: Quando aplicativos construídos para computação em nuvem são incompatíveis com os aplicativos legados.

3. Dificuldade em obedecer as normas regulatórias: Quando a regulação limita o uso da computação em nuvem para alguns ambientes. Nuvens privadas podem ser uma saída para diversas organizações.

4. Segurança inadequada: Quando em muitas situações a segurança é um gargalo para adoção da computação em nuvem.

Para os decisores envolvidos com projetos de nuvem os desafios técnicos devem ser superados naturalmente, e o foco é a conexão da TI ao negócio.

Segundo estudo da Capgemini, as decisões relativas a nuvem estão cada vez mais sendo tomados pelos gestores do negócio.

A decisão de migrar para nuvem foi tomada por gestores do negócio em 45% dos casos e por gestores de TI em 46% – Estudo da Business Cloud – The State of Play Shifts Rapidly.

O mesmo estudo aponta que em um futuro próximo as decisões sobre nuvem serão centralizadas nos gestores de negócios.

O processo de adoção da computação em nuvem apresenta benefícios e riscos e o mesmo deve ter um processo de gerenciamento de riscos associados. Existem diversas características importantes no modelo de computação em núvem e a combinação destas características fornecidas pelo modelo adotado pelos provedores pode fazer o risco variar.

Alguns cuidados que o cliente deve ter para mitigar o risco referente à aquisição de serviços de um provedor de computação em núvem sugerido pelo Gartner:

. Saber como é feito o acesso dos usuários

. Saber como o provedor obedece ás normas de regulação

. Saber onde se localizam os dados

. Saber como os dados são segregados

. Saber como os dados são recuperados

. Saber como é feito o suporte

. Ententer a viabilidade do provedor no longo prazo

Um dos riscos a ser avaliado na entrega dos serviços de TI para a computação em núvem é o risco da perda do controle dos dados internos e ele de fato existe.

Aplicativos que eventualmente continuem operando localmente, podem utilizar serviços de infraestrutura providos pela nuvem (ex: Armazenamento de dados), e funcionar utilizando serviços providos interna e externamente. Normalmente os riscos aumentam até nesses casos.

No modelo de computação em núvem (diferente do modelo de computação tradicional), teremos a alteração do modelo amparado em equipamentos para outro baseado em serviços. Usa-se nesses casos o Service Leve Agreement (SLA) como interface natural entre provedores e organizações clientes.

Dica: Riscos legais podem ocorrer caso um provedor limite suas responsabilidades na SLA com o cliente.

Os riscos que a computação em núvem pública traz devem ser minimizados nas áreas de armazenamento, desempenho, integração de dados e segurança:

Armazemanto: Os provedores oferecem suporte à autenticação de usuários para controlar o acesso aos dados. Mecanismos de acesso como ACL (Access Control List) deverão ser usados para conceder permissões seletivamente a usuários e grupos.

Uploads/Downloads deverão ser feitos por SSL usando o protocolo HTTPS ou pelos próprios métodos de autenticação que o cliente possa ter com suas bibliotecas de criptografia própria.

Dados armazenados em repouso podem ser criptografados via SSE (Server Side Encryption), fornecido por alguns provedores.

Obtenção de log´s mostrando as solicitações enviadas ao armazenamento em nuvem pode ser util para monitorar aplicativos ou para fins de auditoria.

Implementação de dispositivos locais para transferência automática de dados para uma plataforma de armazenamento em nuvem altamente disponível e durável – soluções de recuperação de desastres com o mínimo de esforço e custo com ferramentas híbridas de amazenamento.

Desempenho: O acesso de baixa latência a dados em grande escala é um desafio. As unidades de estado sólido oferecem tempos de resposta muito mais rápidos e previsíveis e já são opções oferecidas por alguns provedores de computação em nuvem.

Um cache na memória pode ajudar a melhorar o desempenho do aplicativo. O uso de um cache gerenciado na memória significa que você não precisa se preocupar com o gerenciamento, o monitoramento e a operação do cache em memória e pode se concentrar em seu aplicativo.

Para um desempenho superior considere um serviço de balanceamento de carga com escalabilidade e gerenciamento automáticos. Este serviço também deve verificar a saúde (disponibilidade) do seu aplicativo para que falhas não afetem os usuários.

Integração de dados: Como dados empresariais não estão preparados para análise, o uso de ferramentas que carregam e transformam esses dados é algo de extrema importância. No caso de provedores em nuvem esta realidade não é diferente.

O serviço de banco de dados gerenciado (oferecido por diversos provedores em nuvem), permite configurar a alta disponibilidade mais facilmente, evitando tarefas com este fim e lhe dando oportunidade de se dedicar aos recursos do próprio aplicativo e evitar altos custos.

Os provedores em nuvem oferecem recursos baseados em réplicas para melhorar os serviços de dados. As réplicas de leitura oferecem o recurso de escalabilidade horizontal além das restrições de capacidade de uma única instância de banco de dados para cargas de trabalho de bancos de dados com uso intensivo de leituras. Também é certo afirmar que o serviço de replicas em um ambiente gerenciado poupa custo e tempo nas tarefas de configuração.

Segurança: A computação em nuvem deve tratar os aspectos básicos de segurança:

Confidencialidade

Disponibilidade

Integridade

Autenticidade

Não repúdio

O aspecto chave da computação em nuvem é o gerenciamento de identidade e controle de acesso. Como se trata de ambiente disitribuído, é necessário implantar serviços de gerenciamento de segurança que funcionem de forma distribuída.

Ex: Seviços de identidade – delegando direitos administrativos, a fim de que gerentes individuais possam administrar contas dentro do seu próprio domínio.

Também usar o SSO (Single Sign On), conforme já mencionado para autenticar usuários em aplicações executadas na nuvem.

Arquitetura de aplicação e processo de desenvolvimento:

As atuais arquiteturas de software não atendem ao novo cenário dos negócios ávidos por arquiteturas flexíveis. Neste caso se faz necessário um novo modelo de arquitetura de software chamado Multitenancy ou multi-inquilino.

Multitenancy – permite que múltiplos inquilinos (empresas clientes) compartilhem os mesmos recursos físicos como um aplicativo ERP, mas permanecendo logicamente isolados.

Reforçando: Multitenancy trata da arquitetura de aplicações onde uma única instância do software roda em um servidor e vários inquilinos (tenants) a acessam.

Na arquitetura Multitenancy os inquilinos utilizam a mesma instância do servidor e não máquinas virtuais distintas. A arquitetura Multitenancy implica em ter poder para forçar aplicação de políticas, segmentação, isolamento, governança, níveis de serviço de forma diferente por perfís de usuários.

A arquitetura SaaS depende totalmente da arquitetura multitenancy – ter uma aplicação atendendo a múltiplos clientes.

OBS: Inquilinos (tenants) não são usuários individuais.

Segundo Cezar Taurion, os modelos multi-inquilo (Multitenancy) podem ser classificamos como:

Inquilino Isolado: Modelo em que cada inquilino tem seu próprio Stack de Tecnologia, não havendo o compartilhamento de recursos. Mesmo sentindo a experiência de multi-inquilino (por acessar uma aplicação oferecida a múltiplos clientes a partir do mesmo datacenter), não se trata de um modelo multi-inquilino. É similar ao modelo tradicional de hostpedagem (hosting) onde cada usuários tem seu próprio conjunto de recursos computacionais e sua própria instância da aplicação. Este modelo, por ser uma oferta SaaS, carece de agilidade e elasticidade, pois para adicionar um novo inquilino requer o provisionamento de sua própria instância de hardware e software. Também não permite economia em escala.

Multi-inquilino via hardware compartilhado (virtualização): Cada inquillino tem seu próprio stack de tecnologia, mas o hardware é alocado dinamicamente a partir de um pool de recursos, via mecanismo de virtualização. Permite elasticidade na camada de hardware. Este modelo apresenta uma limitação: pois a unidade de alocação e liberação de recursos é a máquina virtual onde a aplicação vai operar.

Multi-inquilino via container: Neste modelo várias inquilinos são executados na mesma instância de um container de aplicação (servidor de aplicação), mas cada inquilino está associado a uma instância separada do software de banco de dados. O ambiente de execução é compartilhado entre vários inquilinos, mas a plataforma de dados é a a mesma.

Multi-inquilino de stack de software compartilhado: Similar ao modelo multi-inquilino via container – compartilhando todo o stack de software. Além do container da aplicação, também uma única instância do banco de dados é compartilhada por todos os inquilinos.

“Os negócios atualmente demandam agilidade e a TI precisa prover sistemas que permitam que a empresa se reconfigure de forma rápida em função das mudanças do ambiente, o que se convenciona chamar de flexibilidade estratégica”. – Por Jinesh Varia – consultor da Amazon AWS.

A elasticidade deve ser um dos requisitos do projeto arquitetônico ou mesmo uma propriedade do sistema. – e aqui mais uma vez vemos a questão da elasticidade sendo abordada.

Algumas perguntas se fazem necessárias quando pensamos a arquitetura dos aplicativos:

  1. Quais os componentes ou que camadas em minha arquitetura de aplicativo podem se tornar elásticas?
  2. O que será necessário para tornar esse componente elástico?
  3. Qual será o impacto da implementação da elasticidade na arquitetura geral do sistema?
  4. Será que a infraestrutura está preparada para otimizar a elasticidade do aplicativo?

Você vai notar que a nuvem pode não ter a especificação exata do recurso que você tem no seu ambiente local. Deve-se compreender que a nuvem fornece recursos abstratos, e eles se tornam poderosos quando você os combina com o modelo de provisionamento on demand.

Um aspecto a ser considerado é a forma como os datacenters estão sendo construídos. Existe uma relação direta entre a arquitetura do datacenter e a arquitetura do aplicativo. A infraestrutura orientada a serviço deve suportar a arquitetura orientada a serviço do aplicativo (Services Oriented Architecture – SOA).

A arquitetura SOA utiliza o paradigma request/reply para estabelecer a comunicaçãoentre os sistemas clientes e os sistemas que implementam os serviços.

O provisionamento do datacenter sempre foi feito no limite, provisionando recursos no máximo da capacidade, para fugir das dificuldades em realizar o planejamento de capacidade (capacity planning). Este processo gera perda de eficiência e um custo muito elevado para a operação como um todo.

A modularidade foi introduzida recentemente tanto para os aspectos da construção como para os componentes da solução para melhorar estes aspectos e permitir uma infraestrutura orientada a serviços.

O modelo tradicional de datacenters provisionam servidores web com capacidade elevada para atender as demandas de pico, o que quase sempre resulta em capacidade ociosa.

Servidores de cache otimizam o uso dos servidores de banco de dados e fazem com que boa parte das requisições seja atendida em cache.

A arquitetura do datacenter deve suportar o modelo de três camadas utilizado para construção de uma aplicação:

Camada de apresentação – presentation tier – pt

Regras de negócio – business tier – bt

Camada de dados – data tier – dt

E aqui encerro esse capítulo 3 dos meus apontamentos do livro. Logo posto o capitulo 4.

Espero que estaj série o ajude em seus estudos

Abraço

Uilson

Categorias:Não categorizado
  1. Nenhum comentário ainda.
  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

%d blogueiros gostam disto: