Melhores Práticas para
Arquitetura em Cloud
Computing

http://ZenCloud.co

Daniel Checchia
Consultor de Tecnologia
daniel@ZenCloud.co
Daniel Checchia…. Quem??
•  +30 anos em Tecnologia
•  Passagem por todos os grandes e-Commerce nacionais
(americanas.com, shoptime.com, submarino.com,
pontofrio.com), empresas de internet (imovelweb.com,
zap.com.br) e startups (psafe.com, sitepx.com).
•  Especializado em Arquitetura Corporativa,
Infraestrutura, segurança e Cloud Computing.
•  “T-Rex” evoluído J

2
O que eu faço….
§  Planejamento Estratégico TI
§  Arquitetura Corporativa de TI
§  Consultoria Estratégica
§  Mentoring para Startups
§  CTO Virtual ou On Demand
§  Hands on

§  Lavo
§  Passo
§  Cozinho....
3
Referência desta
Apresentação

4
Próximas Palestras
2013:
12/11 - Melhores Práticas para Hosting de Aplicações na AWS
19/11 - Criando aplicativos tolerantes a falhas na AWS
2014:
20/01 - Framework de Arquitetura para Cloud Computing
* Lançamento do eBook!

5
Licenciamento desta
Apresentação
Atribuição-Uso Não-Comercial-Compatilhamento pela
mesma licença 2.5 Brasil
Você pode:
• copiar, distribuir, exibir e executar a obra
• criar obras derivadas
Sob as seguintes condições:
Atribuição. Você deve dar crédito ao autor original, da forma
especificada pelo autor ou licenciante.
Uso Não-Comercial. Você não pode utilizar esta obra com
finalidades comerciais.
Compartilhamento pela mesma Licença. Se você alterar, transformar, ou criar outra
obra com base nesta, você somente poderá distribuir a obra resultante sob uma licença
idêntica a esta.

6
BENEFÍCIOS FINANCEIROS

7
“Quase” zero de
investimento inicial
Modelo Tradicional:
•  Sala “CPD” (NoBreaks, Geradores, ar condicionado,
segurança física, servidores, roteadores, switches, etc)
Outsourcing:
•  Aquisição servidores, switches, contratação links
Cloud Computing:
•  OPEX

8
Infraestrutura “Just-in-time”
Modelo Tradicional:
•  “Vítima do próprio Sucesso da Aplicação”
•  Dimensionamento no “TOPO” e pelo “pior cenário”
•  Alta ociosidade de infraestrutura
Cloud Computing:
•  Auto-escalonamento em momento de “pico”
•  Pay-as-use

9
BENEFÍCIOS TECNOLÓGICOS

10
Automação
“Scriptable infrastructure”
•  Gestão por APIs (programação em Shell Script)
•  Puppet
•  Opscode Chef
•  (inserir imagem da subida de um servidor na linha de
código)

11
Auto-scaling
• 
• 
• 
• 

Defina parâmetros de utilização
Defina os alarmes
Defina quantidade de instâncias (mínimo e máximo)
Configure o auto-scalling

•  Relax!

12
Ciclo de Desenvolvimento
mais eficiente
•  “Clone” o ambiente de Produção de forma rápida
•  Ciclo de desenvolvimento encurtado e mais ágil
• 
Beanstalk
•  Deploy automatizado com testes unitários
•  Jenkins

13
CONCEITOS CLOUD
COMPUTING
14
Construindo Arquiteturas
escaláveis
Características de um aplicativo verdadeiramente
escalável:
•  Aumento de recursos resulta em um aumento
proporcional no desempenho
•  Um serviço escalável é capaz de lidar com a
heterogeneidade
•  Um serviço escalável é operacionalmente eficiente
•  Um serviço escalável é resiliente
•  Um serviço escalável deve tornar-se mais rentável
quando cresce (Custo unitário diminui à medida que o
número de unidades aumenta)
15
Entendendo a tal de
Elasticidade

16
Entendendo a tal de
Elasticidade

17
Entendendo a tal de
Elasticidade

18
Entendendo a tal de
Elasticidade

19
Entendendo a tal de
Elasticidade

20
Sem medo das Restrições
•  Cloud foi planejada para um modelo on-demand – não
para um moving AS-IS de seu ambiente
•  1 servidor de 64Gb de RAM = X servidores em auto-scalling
•  Muito IO de Leitura = Memcached
•  Busca em banco = CloudSearch (ElasticSearch, Solr)
•  E outras soluções escaláveis!

21
Administração “Virtual”
•  Com a mudança de Paradigma, vem a agilidade
•  Ambiente “ganha” em performance e escalabilidade
•  Equipes Desenvolvimento e Operações “andam” juntas
para gerir o ambiente

22
MELHORES PRÁTICAS
CLOUD COMPUTING
23
Arquitetura Resiliente
“Design for failure and nothing will fail”
Seja um pessimista ao projetar arquiteturas em nuvem;
assuma que as coisas vão falhar.
Em outras palavras, sempre que projetar, inclua a
recuperação automática de falhas (redundância de
regions, de banco e etc) em seu projeto.

24
Arquitetura Resiliente
Assuma que seu hardware irá falhar
Assuma que interrupções ocorrerão (AWS, Links, etc)
Assuma que algum desastre vai atingir a sua aplicação
Assuma que você vai ser atingido com mais do que o
número esperado de solicitações por segundo alguns dias
•  Assuma que, com o tempo, o seu aplicativo falhará
também
• 
• 
• 
• 

Ser pessimista é fundamental para a criação de uma
arquitetura (software e infra) resiliente.

25
Separe seus Componentes
Cloud reforça o princípio de design da SOA, onde quanto mais
segregado e flexível forem os componentes do sistema,
mais ele será escalável.
Fundamental para arquiteturas em nuvem:
•  Segregação dos seus componentes;
•  Construção de sistemas assíncronos;
•  Dimensionamento para crescimento horizontal

26
Separe seus Componentes
u  Trate cada módulo como uma “Caixa Preta”:
•  Engine de Busca
•  Banco de Dados
•  Frontend
•  Backend
•  Banco de dados
u  Use APIs para “Falar” entre cada módulo
u  Sempre que possível, implemente queues e torne sua
aplicação Assincrona.
27
Implemente Elasticidade:
Automatize sua Infraestrutura
•  Use as APIs de gestão Cloud
•  Crie uma biblioteca de “Recipes” – Scripts mais utilizados
•  Gerencie suas configurações e Deploy utilizando-se de
agents dentro de suas AMIs
•  Opscode Chef
•  CFEngine
•  Puppet
•  Git hacks

28
Implemente Elasticidade:
Bootstrap de suas instâncias
•  Crie “Roles” para sua
aplicação (“DBServer”,
“WEBServer”, “DEVServer”,
etc)
•  Busque estas informações
durante o Boot para
configurar sua instância

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html!

29
Pense Paralelo
A beleza da nuvem aparece quando você combina
elasticidade e paralelismo
•  Garanta que sua aplicação seja assincrona e “stateless”
•  Sempre que possível, utilize APIs entre o front e o
Backend
•  Utilize load balance e cache tanto no frontend como no
backend, nas APIs e XMLs

Estes cuidados permitirão o rápido escalonamento de sua
aplicação de forma automatizada
30
Mantenha seus dados perto
das requisições
Keep dynamic data closer to the compute and static data
closer to the end-user
•  Segregue dados dinâmicos do estático por sub-domínios
•  Coloque dados estáticos em uma CDN (ou crie um cache)
•  Mantenha seus servidores de Processamento, banco de
dados e frontend na mesma region – minimize custos e
latência

31
MELHORES PRÁTICAS
SEGURANÇA
32
Proteja os dados em trânsito
• 

Esqueça HTTP – Use sempre HTTPS:
•  Entre Browser e WebServer
•  Entre Front e APIs

• 

Utilize VPNs:
•  Entre seu escritório e seu provedor de Nuvem
•  Entre Notebooks e Tablets e seu provedor de
Nuvem

• 

Faça Segregação de Ambientes:
•  Crie VPCs (=VLANs) entre recursos da AWS
•  Seja rígido nas regras de firewall entre as
VPCs

33
Proteja seus dados
armazenados
Se você está preocupado com o armazenamento de dados
sensíveis e confidenciais na nuvem:
•  Criptografe seus dados sensíveis antes do upload (PGP)
•  Use EFS para armazenar seus dados (windows ou Linux)
•  Ou Criptografe seu Volume (EBS) - EncFS, Loop-AES, dmcrypt, TrueCrypt
•  OpenSolaris suporta ZFS

PROTEJA suas Chaves Criptográficas! Sem elas, você pode
ficar sem seus dados!!!
34
Protect your APIs
credentials
AWS fornece dois tipos de credenciais de segurança:
•  AWS Access Keys
•  Certificados X.509
AWS Access Keys são compostas de dois “pedaços”:
•  access key ID
•  secret access key
Gerenciando Credenciais (atualizado recentemente):
Parte 01:
http://www.elastician.com/2009/06/managing-your-aws-credentials-part-1.html
Parte 02:
http://www.elastician.com/2009/06/managing-your-aws-credentials-part-2.html

35
Protect your APIs
credentials
Access Key são utilizadas para:
•  Comunicação entre serviços via API
•  Comunicação entre sua instância e as APIs
•  Toda comunicação é via HTTPS
Uma boa prática:
•  Crie um usuário específico para uso com as APIs
•  Crie um script de geração periódica de novas chaves
•  Utilize o Bootstrap para armazenar suas Access Keys

Um erro comum: Armazenar as Access Keys em arquivos
na sua própria AMI! Prefira utilizar o processo de Bootstrap
para passar suas Access Keys para as instâncias
36
Manage multiple Users and
their permissions
AWS Identity and Access Management (IAM), é a central
de controle de acessos da AWS.
•  IAM é seguro por natureza. Cada usuário criado inicia
sem acesso. O administrador precisa atribuir quais
serviços e quais privilégios ele terá.
•  Usuários podem habilitar Multi-factor para autenticação
•  Usuários e senhas são distintos das Access Keys

37
Proteja sua Aplicação
Security Groups:
•  Aplicados em instâncias
ou para uma VPC
•  Regras de
“entrada” (ingress Rules)
Configure o Firewall de seu SO:
•  Linux: Netfilter / IPTables
•  Windows Firewall

Seja restritivo entre VPCs

38
Proteja sua Aplicação
•  Crie snapshots de suas AMI para testar os patches
•  Aplique regularmente os patches para seu SO em sua
AMI de testes
•  Revalide sua aplicação após os patches para ver se não
“quebrou” nenhuma funcionalidade após o patch
•  Garanta que TODAS suas AMIs estão com os últimos
patches
•  Invista tempo para criar scripts de validação de
segurança e para automatizar este processo de
validação e atualização

39
Ferramentas Cloud8
Cupom Cloud8 – 60 dias grátis
http://www.cloud8.com.br

DANIEL-888
(válido até 30/11/2013)

40
Referências
AWS (http://aws.amazon.com/pt/architecture/)
Netflix (http://techblog.netflix.com/)
Twitter (https://blog.twitter.com/engineering)
Facebook:
• 
• 
• 
• 

https://www.facebook.com/Engineering
https://www.facebook.com/data
https://www.facebook.com/MemcacheAtFacebook
https://www.facebook.com/MySQLatFacebook

41
Obrigado!!
Daniel Checchia
daniel@zencloud.co
@checchia

Skype: daniel.checchia
(11) 3010-0140

Site pessoal:
http:/
/Checchia.NET

42

Melhores práticas para Arquitetura em Cloud Computing

  • 1.
    Melhores Práticas para Arquiteturaem Cloud Computing http://ZenCloud.co Daniel Checchia Consultor de Tecnologia daniel@ZenCloud.co
  • 2.
    Daniel Checchia…. Quem?? • +30 anos em Tecnologia •  Passagem por todos os grandes e-Commerce nacionais (americanas.com, shoptime.com, submarino.com, pontofrio.com), empresas de internet (imovelweb.com, zap.com.br) e startups (psafe.com, sitepx.com). •  Especializado em Arquitetura Corporativa, Infraestrutura, segurança e Cloud Computing. •  “T-Rex” evoluído J 2
  • 3.
    O que eufaço…. §  Planejamento Estratégico TI §  Arquitetura Corporativa de TI §  Consultoria Estratégica §  Mentoring para Startups §  CTO Virtual ou On Demand §  Hands on §  Lavo §  Passo §  Cozinho.... 3
  • 4.
  • 5.
    Próximas Palestras 2013: 12/11 -Melhores Práticas para Hosting de Aplicações na AWS 19/11 - Criando aplicativos tolerantes a falhas na AWS 2014: 20/01 - Framework de Arquitetura para Cloud Computing * Lançamento do eBook! 5
  • 6.
    Licenciamento desta Apresentação Atribuição-Uso Não-Comercial-Compatilhamentopela mesma licença 2.5 Brasil Você pode: • copiar, distribuir, exibir e executar a obra • criar obras derivadas Sob as seguintes condições: Atribuição. Você deve dar crédito ao autor original, da forma especificada pelo autor ou licenciante. Uso Não-Comercial. Você não pode utilizar esta obra com finalidades comerciais. Compartilhamento pela mesma Licença. Se você alterar, transformar, ou criar outra obra com base nesta, você somente poderá distribuir a obra resultante sob uma licença idêntica a esta. 6
  • 7.
  • 8.
    “Quase” zero de investimentoinicial Modelo Tradicional: •  Sala “CPD” (NoBreaks, Geradores, ar condicionado, segurança física, servidores, roteadores, switches, etc) Outsourcing: •  Aquisição servidores, switches, contratação links Cloud Computing: •  OPEX 8
  • 9.
    Infraestrutura “Just-in-time” Modelo Tradicional: • “Vítima do próprio Sucesso da Aplicação” •  Dimensionamento no “TOPO” e pelo “pior cenário” •  Alta ociosidade de infraestrutura Cloud Computing: •  Auto-escalonamento em momento de “pico” •  Pay-as-use 9
  • 10.
  • 11.
    Automação “Scriptable infrastructure” •  Gestãopor APIs (programação em Shell Script) •  Puppet •  Opscode Chef •  (inserir imagem da subida de um servidor na linha de código) 11
  • 12.
    Auto-scaling •  •  •  •  Defina parâmetros deutilização Defina os alarmes Defina quantidade de instâncias (mínimo e máximo) Configure o auto-scalling •  Relax! 12
  • 13.
    Ciclo de Desenvolvimento maiseficiente •  “Clone” o ambiente de Produção de forma rápida •  Ciclo de desenvolvimento encurtado e mais ágil •  Beanstalk •  Deploy automatizado com testes unitários •  Jenkins 13
  • 14.
  • 15.
    Construindo Arquiteturas escaláveis Características deum aplicativo verdadeiramente escalável: •  Aumento de recursos resulta em um aumento proporcional no desempenho •  Um serviço escalável é capaz de lidar com a heterogeneidade •  Um serviço escalável é operacionalmente eficiente •  Um serviço escalável é resiliente •  Um serviço escalável deve tornar-se mais rentável quando cresce (Custo unitário diminui à medida que o número de unidades aumenta) 15
  • 16.
    Entendendo a talde Elasticidade 16
  • 17.
    Entendendo a talde Elasticidade 17
  • 18.
    Entendendo a talde Elasticidade 18
  • 19.
    Entendendo a talde Elasticidade 19
  • 20.
    Entendendo a talde Elasticidade 20
  • 21.
    Sem medo dasRestrições •  Cloud foi planejada para um modelo on-demand – não para um moving AS-IS de seu ambiente •  1 servidor de 64Gb de RAM = X servidores em auto-scalling •  Muito IO de Leitura = Memcached •  Busca em banco = CloudSearch (ElasticSearch, Solr) •  E outras soluções escaláveis! 21
  • 22.
    Administração “Virtual” •  Coma mudança de Paradigma, vem a agilidade •  Ambiente “ganha” em performance e escalabilidade •  Equipes Desenvolvimento e Operações “andam” juntas para gerir o ambiente 22
  • 23.
  • 24.
    Arquitetura Resiliente “Design forfailure and nothing will fail” Seja um pessimista ao projetar arquiteturas em nuvem; assuma que as coisas vão falhar. Em outras palavras, sempre que projetar, inclua a recuperação automática de falhas (redundância de regions, de banco e etc) em seu projeto. 24
  • 25.
    Arquitetura Resiliente Assuma queseu hardware irá falhar Assuma que interrupções ocorrerão (AWS, Links, etc) Assuma que algum desastre vai atingir a sua aplicação Assuma que você vai ser atingido com mais do que o número esperado de solicitações por segundo alguns dias •  Assuma que, com o tempo, o seu aplicativo falhará também •  •  •  •  Ser pessimista é fundamental para a criação de uma arquitetura (software e infra) resiliente. 25
  • 26.
    Separe seus Componentes Cloudreforça o princípio de design da SOA, onde quanto mais segregado e flexível forem os componentes do sistema, mais ele será escalável. Fundamental para arquiteturas em nuvem: •  Segregação dos seus componentes; •  Construção de sistemas assíncronos; •  Dimensionamento para crescimento horizontal 26
  • 27.
    Separe seus Componentes u Trate cada módulo como uma “Caixa Preta”: •  Engine de Busca •  Banco de Dados •  Frontend •  Backend •  Banco de dados u  Use APIs para “Falar” entre cada módulo u  Sempre que possível, implemente queues e torne sua aplicação Assincrona. 27
  • 28.
    Implemente Elasticidade: Automatize suaInfraestrutura •  Use as APIs de gestão Cloud •  Crie uma biblioteca de “Recipes” – Scripts mais utilizados •  Gerencie suas configurações e Deploy utilizando-se de agents dentro de suas AMIs •  Opscode Chef •  CFEngine •  Puppet •  Git hacks 28
  • 29.
    Implemente Elasticidade: Bootstrap desuas instâncias •  Crie “Roles” para sua aplicação (“DBServer”, “WEBServer”, “DEVServer”, etc) •  Busque estas informações durante o Boot para configurar sua instância http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html! 29
  • 30.
    Pense Paralelo A belezada nuvem aparece quando você combina elasticidade e paralelismo •  Garanta que sua aplicação seja assincrona e “stateless” •  Sempre que possível, utilize APIs entre o front e o Backend •  Utilize load balance e cache tanto no frontend como no backend, nas APIs e XMLs Estes cuidados permitirão o rápido escalonamento de sua aplicação de forma automatizada 30
  • 31.
    Mantenha seus dadosperto das requisições Keep dynamic data closer to the compute and static data closer to the end-user •  Segregue dados dinâmicos do estático por sub-domínios •  Coloque dados estáticos em uma CDN (ou crie um cache) •  Mantenha seus servidores de Processamento, banco de dados e frontend na mesma region – minimize custos e latência 31
  • 32.
  • 33.
    Proteja os dadosem trânsito •  Esqueça HTTP – Use sempre HTTPS: •  Entre Browser e WebServer •  Entre Front e APIs •  Utilize VPNs: •  Entre seu escritório e seu provedor de Nuvem •  Entre Notebooks e Tablets e seu provedor de Nuvem •  Faça Segregação de Ambientes: •  Crie VPCs (=VLANs) entre recursos da AWS •  Seja rígido nas regras de firewall entre as VPCs 33
  • 34.
    Proteja seus dados armazenados Sevocê está preocupado com o armazenamento de dados sensíveis e confidenciais na nuvem: •  Criptografe seus dados sensíveis antes do upload (PGP) •  Use EFS para armazenar seus dados (windows ou Linux) •  Ou Criptografe seu Volume (EBS) - EncFS, Loop-AES, dmcrypt, TrueCrypt •  OpenSolaris suporta ZFS PROTEJA suas Chaves Criptográficas! Sem elas, você pode ficar sem seus dados!!! 34
  • 35.
    Protect your APIs credentials AWSfornece dois tipos de credenciais de segurança: •  AWS Access Keys •  Certificados X.509 AWS Access Keys são compostas de dois “pedaços”: •  access key ID •  secret access key Gerenciando Credenciais (atualizado recentemente): Parte 01: http://www.elastician.com/2009/06/managing-your-aws-credentials-part-1.html Parte 02: http://www.elastician.com/2009/06/managing-your-aws-credentials-part-2.html 35
  • 36.
    Protect your APIs credentials AccessKey são utilizadas para: •  Comunicação entre serviços via API •  Comunicação entre sua instância e as APIs •  Toda comunicação é via HTTPS Uma boa prática: •  Crie um usuário específico para uso com as APIs •  Crie um script de geração periódica de novas chaves •  Utilize o Bootstrap para armazenar suas Access Keys Um erro comum: Armazenar as Access Keys em arquivos na sua própria AMI! Prefira utilizar o processo de Bootstrap para passar suas Access Keys para as instâncias 36
  • 37.
    Manage multiple Usersand their permissions AWS Identity and Access Management (IAM), é a central de controle de acessos da AWS. •  IAM é seguro por natureza. Cada usuário criado inicia sem acesso. O administrador precisa atribuir quais serviços e quais privilégios ele terá. •  Usuários podem habilitar Multi-factor para autenticação •  Usuários e senhas são distintos das Access Keys 37
  • 38.
    Proteja sua Aplicação SecurityGroups: •  Aplicados em instâncias ou para uma VPC •  Regras de “entrada” (ingress Rules) Configure o Firewall de seu SO: •  Linux: Netfilter / IPTables •  Windows Firewall Seja restritivo entre VPCs 38
  • 39.
    Proteja sua Aplicação • Crie snapshots de suas AMI para testar os patches •  Aplique regularmente os patches para seu SO em sua AMI de testes •  Revalide sua aplicação após os patches para ver se não “quebrou” nenhuma funcionalidade após o patch •  Garanta que TODAS suas AMIs estão com os últimos patches •  Invista tempo para criar scripts de validação de segurança e para automatizar este processo de validação e atualização 39
  • 40.
    Ferramentas Cloud8 Cupom Cloud8– 60 dias grátis http://www.cloud8.com.br DANIEL-888 (válido até 30/11/2013) 40
  • 41.
    Referências AWS (http://aws.amazon.com/pt/architecture/) Netflix (http://techblog.netflix.com/) Twitter(https://blog.twitter.com/engineering) Facebook: •  •  •  •  https://www.facebook.com/Engineering https://www.facebook.com/data https://www.facebook.com/MemcacheAtFacebook https://www.facebook.com/MySQLatFacebook 41
  • 42.