AWS, DEVOPS

Reformulação do Seja.Cloud

Pedido de desculpas e Certificação AWS

Pessoal, sei que estou há muito tempo sem postar (iria completar 1 ano), mas estou num período de muitos estudos e muito trabalho.

Estamos em um processo forte de migração de algumas plataformas para a AWS, onde estou coordenando uma equipe de Cloud e DevSecOps responsável por toda definição e gestão da Núvem Pública, ou seja, você criar um “datacenter” do zero não é fácil e nada muito rápido, mas em um post mais para frente comentarei sobre a experiência.

Recentemente tirei minha certificação em AWS Architect (Associate) e iniciei o meu estudo para partir para a AWS Architect Professional. Como a certificação do professional exige MUITO tempo de prática e MUITO estudo, resolvi reformular todo o meu site para praticar um pouco alguns conceitos. O Resultado ficou show, e principalmente: BARATO.

No ínicio um monolitico.

No lançamento do meu site, por questão de praticidade para mim e querer fazer o lançamento rápido, eu criei uma estrutura muito simples, mas com bastante falhas (só que me atendia bem).

Eu tinha um Route53 para gerenciar meu DNS, uma VPC Default e uma instancia EC2 T2.micro com um WordPress e um MySQL juntos (desenho abaixo).

Esta configuração é muito amadora, básica, mas para um site que não tinha muitos acessos e eu queria utilizar somente para fazer meus posts estava me atendendo bem.

O problema é que em dias de picos o Apache matava o processo do SQL buscando memória, pois a instancia era pequena, e diversas vezes eu tinha que reiniciar a máquina (por ser mais rápido) para voltar ao normal.

Ou seja, para um ambiente onde só eu utilizava e poucos amigos acessavam estava ótimo, mas de fato, precisava dar um upgrade.

Estudos certificação e hora da 2a versão.

Como eu estava estudando para a certificação da Architect Associate, eu resolvi juntar o útil ao agradável e fazer uma segunda versão melhorada e que pudesse parar de derrubar meu site.

Fui para a seguinte configuração:

  • Criei uma VPC customizada (deixei de usar a Default) – Aqui é uma dica importante para o exame, é importante você saber criar a VPC da tua memória, com todos os passos necessários. Eu vou fazer um post mais para frente sobre a certificação e comentarei sobre isso.
  • Route53 gerenciando o DNS.
  • Criei duas subnets – 1 publica e 1 privada – Esta configuração permite com que você não exponha os teus dados à internet. E pode fazer o controle de segurança via ACL.
  • Criei duas instancias t2.nano (o meu periodo de instancias free já havia terminado), uma instância na subnet pública com abertura da porta 80 via security group e uma instancia na subnet privada para ser banco de dados. Também fiz o ajuste abaixo no /etc/my.conf a fim de deixar o mysql mais light para rodar em uma t2.nano
    • [mysqld]
    • skip-external-locking
      key_buffer_size = 16K
      max_allowed_packet = 1M
      table_open_cache = 4
      sort_buffer_size = 64K
      read_buffer_size = 256K
      read_rnd_buffer_size = 256K
      net_buffer_length = 2K
      thread_stack = 128K
  • Criei um Nat Gateway na subnet publica e uma rota da instancia da subnet privada para o Nat Gateway: Isto permite com que você consiga que a instancia da subnet privada possa acessar a internet sem expor ela para a internet (ela tem somente um ip privado) e é útil para rodar o yum update entre outras coisas mais, mantendo segurança.
  • Criei um internet gateway na minha subnet publica: É isto que caracteriza uma subnet publica. Ter um internet gateway libera a subnet para a internet.

Neste meu case ainda faltou algumas configurações por exemplo ACL para restringir o tráfego a nivel de subnet, o que deixaria mais seguro (é uma segurança além do security group), também poderia ter criado um servidor para servir de bastion host, e somente este servidor eu liberaria a porta SSH (22) para meu ip de casa, mas, como não é um ambiente corporativo, deixei a configuração do jeito que descrevi acima (e foto abaixo) pois me atendia bem em termos de segurança e em termos de estabilidade.

Pontos de falha:

  • Não há instancias em multi AZ, ou seja, em caso de picos e a instancia parar (a t2 nano até que aguenta bem o tráfego do meu site) o meu site ficaria indisponivel,
  • Não há nenhum anti DDoS ou outro tipo de mitigador de ataques
  • Não há escalonamento automático das instancias para crescer conforme demanda.

Vendo estes pontos de falhas e buscando redução de custo , pois meu blog estava com um custo de aproximadamente 8 USD (sim é pouco mas se dá para reduzir….) eu fui para a nova versão dele.

Auto escalavel, baixissimo custo e super protegido – SERVERLESS!!!!

Pessoal, o grande benefício de você seguir para uma Cloud Pública, sem sombra de dúvidas é você aproveitar as plataformas da núvem (no meu caso AWS) e deixar de usar como hosting. Existem diversos artigos pela internet (recomendo você buscar pelo site http://acloud.guru que tem bastante informação) falando sobre soluções serverless e foi por aí que eu parti.

O meu blog não tinha nenhuma funcionalidade dinâmica, exceto os comentários. Então se eu encontrasse alguma solução onde os comentários pudessem ser escritos via javascript eu poderia muito bem armazenar meu site em um bucket S3 e marcar o bucket como webhost. Além disto, eu precisaria de algum programa que pudesse varrer meu site e converte-lo em .html;

Procurando pela internet encontrei o plugin DISQUS (http://disqus.com). Ele permite que você substitua os comentários do wordpress por posts em javascript. Eis a solução para meu problema!

Além do Disqus encontrei o programa Win HTTrack Website Copier (https://www.httrack.com/) este programa é fantastico, ele varre teu site e links e cria ele em paginas estaticas (html), também respeitando CSS e javascript.

Pronto, consegui converter meu site inteiro em wordpress php para html!

Feito isto parti para a criação do meu bucket S3 com webhost, fiz o upload do meu site e configurei o Route 53 para apontar  para o bucket. Aqui um ponto de atenção: o seu bucket precisa ter o mesmo nome do dominio (no meu caso: seja.cloud (http://seja.cloud.s3-website-us-west-2.amazonaws.com) e quando você for configurar o Record Set “A” deve setar a opção ALIAS. Automaticamente teu bucket irá aparecer na lista.

Logo, meu site ficou na seguinte configuração:

Porquê Bucket S3?

O S3 é uma plataforma da AWS com altissima disponibilidade, escalabilidade e durabilidade.

Ele garante uma durabilidade de 99,999999999%, ou seja, se você armazenar 10.000 objetos com o Amazon S3, você pode esperar que em média ocorrerá a perda de somente um objeto a cada 10.000.000 anos. Ele também armazena os objetos em multiplos equipamentos em várias instalações em uma região, ou seja, altamente tolerante a falhas.

Ele tem 3 tipos de storage que podem baratear o custo: S3 Standard (custo padrão), S3 IA (Acessos menos frequentes) e S3-RRS (Reduced Redundancy Storage) no meu caso, como o meu site não é tão acessado assim, eu criei meu bucket em um S3 IA mas que está me garantindo uma latencia muito boa, não estou sentindo problemas de velocidade.

Outra coisa interessante dele é quanto aos acessos, no meu caso, eu criei uma ACL onde somente meu usuário pode efetuar algum tipo de alteração no bucket, ou seja, ninguem conseguirá hackear meu site. Para acessar meu usuário é necessário MFA (Multi Factor Autenticator), ou seja, somente se roubarem meu celular e tiverem minha senha conseguem acessar meu site.

Também não tem banco de dados, ou seja, não é possivel me atacar com SQL Injection, etc.

O Custo é irrisório!! Na região que estou, ele custa os primeiros 50 TB mês U$ 0.0125 por GB. Meu site esta com 3 MB, ou seja, não custará mais que U$ 0.54 USD (já considerando o Route 53). Uma redução de 93% no custo.

Criei um WAMP (Windows + apache + mysql + php) na minha máquina pessoal e repliquei meu blog nele, desta forma, quando eu quero atualizar um post (como este) eu atualizo na minha máquina, rodo o HTTrack e faço upload dos arquivos no bucket. Desta forma, consegui desativar todas minhas instancias, elastic ip, natgateway, internet gateway, etc.

Conclusão

Utilizar os benefícios da Cloud Publica com certeza reduz muito o custo, deixe de utilizar a Cloud como hosting e passe a utilizar ela em seus recursos. Você ganhará muito em segurança, escalabilidade e custo.

Esta versão do meu site agora está altamente escalavel, segura (se você achar forma de hackear me avise, pois eu não encontro) e baixissimo custo.

 

Proximos posts

Planejo fazer os seguintes posts, acompanhe:

Eu palestrei no AWS Summit 2017 sobre Como escalar com segurança na Núvem, irei fazer um post sobre ele.

Também irei escrever um post sobre como passei na certificação da AWS Architect Associate e darei dicas.

Escreverei um pouco mais sobre alguns serviços da AWS, principalmente sobre os que tive utilizando no meu SITE e explicarei como montar um website como o meu.

Eu no AWS Summit 2017 com meu grande amigo Rozzati (Arquiteto SR da AWS)

Abraços.

Marcos.

 

 

 

Entendendo o DEVOPS

Entendendo o DEVOPS, e porquê esta mudança cultural tem se tornado cada vez mais necessidade, e não opção.

No post anterior eu deixei escrito que iria falar sobre DEVOPS, neste artigo explicarei melhor a cultura.

Ainda não temos uma boa adoção da cultura no Brasil, e muitas empresas estão agindo no sentido de DEVOPS ser uma área, o que também não é uma boa estratégia, conforme falaremos a seguir.

DEVOPS – O início

Após o surgimento do manifesto ágil, em 2001, os profissionais de TI começaram a ver cada ano que passava que fazia-se necessária uma mudança na forma de entrega.

Em 2005 com o surgimento do Puppet e GIT, começamos a vislumbrar uma forma de entrega de infraestrutura como código podendo unir-se aos deploys de sistemas.

Ano de 2007, Patrick Debois foi contratado como consultor para uma migração de um sistema do governo da Bélgica e ficou muito incomodado com os muitos conflitos que existiam (e nota: ainda existem!!!) entre os desenvolvedores e o sysadmins. Neste momento ele começou a pensar em formas de mudar o cenário.

Logo mais em 2008 com grandes investimentos nos softwares livres de entrega de infraestrutura como código, começou-se a citar o termo “Infraestrutura Ágil”  nos fóruns de discussões.

Também em 2008, a conferência Ágile gera uma grande divulgação dos conceitos de Deploy Contínuo e nesta conferência, Andrew Shafer apresenta a palestra “Agile Infrastructure” e somente uma pessoa assiste a ela: Patrick Debois. Após a palestra, eles conversam muito e decidem inaugurar o grupo “Agile Systems Administration Group”. Aí começa a abertura do caminho para DEVOPS.

Em 2009 na conferencia Velocity da O’Reilly (Toronto), que John Allspaw (Etsy.com) e Paul Hammond (Typekit) apresentam uma palestra cujo objetivo é demonstrar uma forma de unir Desenvolvedores (DEV) e Administradores de Infraestrutura (OPS) com o objetivo de estabelecer um método de entrega contínua, e desta forma dar agilidade nas entregas de TI. O nome da palestra: “10+ Deploys a Day: Dev and Ops Cooperation at Flickr”.

Patrick Debois assistiu a esta palestra remotamente e em seu twiter lamenta-se por não ter conseguido assistir à palestra pessoalmente. Recebe uma provocação de Paul Nasrat: “Por quê você não faz uma Velocity Conf aí na Bélgica?”

Patrick Debois aceita o desafio e em Outubro de 2009 cria a conferência DEVOPS Day. Esta conferência torna-se um sucesso, milhares de desenvolvedores e sysadmins, além de profissionais de qualidade e automação. Após a conferência, inicia-se no twiter a hashtag #DevOps e a partir daí começa-se a difundir o termo mundialmente.

Mas o que é DEVOPS?!

Como deu para observar sobre o início da história do DEVOPS, não estamos falando de uma ferramenta, muito menos de um departamento. Também não estamos falando de uma metodologia única.

Quando falamos de DEVOPS, nós falamos na essência de uma cultura.

E porquê uma cultura ?

Primeiro ponto é que de fato, existe um enorme conflito entre DEV e OPS e este conflito precisa ser quebrado. É necessário sair da zona de confronto onde um diz que o outro está errado, para entrar na zona de trabalho colaborativo.

As pessoas precisam entender que o que importa é o cliente final, ou seja, o que a empresa consegue gerar de valor para as pessoas que se relacionam com ela. Também precisam entender que é necessário agilidade na entrega de valor para o cliente, pois no mundo atual de mudanças rápidas e constantes, qualquer valor novo que o concorrente entregue para o cliente, a difusão da informação em redes sociais faz com que o impacto financeiro para a empresa seja grande. Entretanto também é necessário entender que este valor e agilidade tem que ser entregue com qualidade e garantindo disponibilidade.

Então, para atender os requisitos de Qualidade, Disponibilidade, Agilidade e Entrega contínua, DEVOPS começou a ser resumido na imagem abaixo

devops-figura-3

Ou seja, DEVOPS é uma mudança cultural apoiada por metodologia de automação e trabalho colaborativo unindo as áreas de Desenvolvimento, Operações e Qualidade para entregar valor para o cliente final, de forma contínua.

Fabiano de Freitas em seu post Devops: Matter of Survival apresenta uma imagem que para mim gera a cultura devops “in one page”:

circulo_devops_culture_full

Para uma implantação com sucesso da cultura DEVOPS, a gestão deve preocupar-se em implantar estes principios:

  • Mudar é bom
  • Utilização de ferramentas de automação
  • Transparencia entre todos
  • Reconhecer bons comportamentos
  • Inovar
  • Prestação de contas entre as áreas
  • Não culpar os outros
  • Aceitar as falhas
  • Confiança
  • Trabalho colaborativo
  • Honestidade e abertura entre todos.
  • Trabalhar a comunicação.
Conclusão

Pode-se observar que o início para aplicar o DEVOPS na sua empresa, é a adoção da mudança cultural. A gestão deve estimular o bom relacionamento entre sistemas e infraestrutura, e se possivel, incluir neste bolo a equipe de negócios, pois todos juntos serão responsáveis pelas entregas, o que gera mais engajamento e sentimento de dono.

Outro ponto importante, é a adoção de ferramentas de automação, não há como você entregar DEVOPS se o time da infraestrutura ainda estiver atuando no modelo tradicional de entrega, onde para atendimento dos projetos perde-se alguns meses.

Eu diria, que se fosse classificar o item número um de importância para a entrega de DEVOPS na empresa, este item seria a infra ágil.

No próximo artigo irei começar a detalhar um pouco mais o operacional de uma infraestrutura ágil, citando algumas ferramentas.

Até lá!

 

Acelere a entrega da operação com o poder da Infraestrutura Ágil

Irei falar neste artigo sobre o poder da Infraestrutura ágil e como você pode acelerar a tua entrega de operações tratando infraestrutura como código. Este artigo mostra uma visão gerencial, não tratarei o uso das ferramentas ou como criar uma configuração. Em posts posteriores detalharei mais o assunto ao nível técnico.

Infraestrutura não é Ágil.

Muito se fala sobre DEVOPS nos dias atuais, porém, tenho visto nas empresas quando trata-se de DEVOPS focarem no DEV e esquecerem do OPS.

Este cenário, não é culpa das empresas em sí. O ponto que eu vejo é que a área de desenvolvimento, esteve à frente da área de operações.

Por exemplo, Manifesto Ágil surgiu em 2001, e a área de operações não se juntou à ele.

Enquanto cada vez mais a área de desenvolvimento se organiza para acelerar sua entrega, buscando deploy contínuo, a área de infraestrutura caminha(va) pelo lado contrário, buscando cada vez menos mudanças em seu ambiente.

E este pensamento vem da premissa que está sendo quebrada de que quanto menos mudanças você fizer no teu ambiente, menos chances de indisponibilidade você estará correndo.

Entretanto, uma revolução como a revolução industrial tem mexido na forma de trabalho das empresas. A era do conhecimento, que trouxe junto com ela toda revolução digital.

A era digital

Cada vez mais, o consumidor está se conectando ao mundo digital.

De acordo com um relatório publicado ainda em 2015 pela ONU, no mundo há 3,2 bilhões de pessoas com acesso à internet. Para se ter uma idéia, em 2000 tinhamos apenas 400 mil usuários, ou seja, a evolução de pessoas conectadas cresce cada vez mais.

E o que o cliente final espera das empresas ?

O consumidor digital busca maior interação com a marca, mas também exige mais de seu posicionamento no mercado, o que se caracteriza por novas demandas e novas oportunidades para as empresas

MCLUHAN, 1964, p. 23

Ou seja, cada vez mais, o cliente busca que a empresa entregue produtos de forma mais ágil e tenha mais interação com ele, saiba quem ele é, e quebre os paradigmas das formalidades. O cliente quer ter um relacionamento com a empresa, da mesma forma que se relaciona com um amigo próximo.

Deploy Contínuo e início de infraestrutura ágil

O desenvolvimento ágil foi cada vez mais evoluindo com o surgimento do manifesto ágil, e conseguindo atender à demanda do novo cliente digital. Tivemos grandes marcos, como por exemplo,  em 2005 o lançamento do GIT que acelerou a forma colaborativa de desenvolvimento, acelerando muito a entrega.

Ao mesmo tempo, um cara de operações (sysadmin) que sabia de programação iniciou a criação do PUPPET, a sua idéia era conseguir evoluir o “shell script” e fazer algo mais poderoso para a entrega da infraestrutura.

Em 2008, a VMWARE e outras empresas começam a investir pesado no Puppet, o que faz com que ele se torne um software de entrega de infraestrutura ágil, e a partir daí começa-se usar o termo Infra Ágil.

O ponto de ebulição vem com a conferência Agile em 2008 onde começou-se a mudar a forma de desenvolvimento em cascata para deploy contínuo.

DEVOPS DAY

Em 2009 durante a conferência Velocity da O’Reilly, John Allspaw e Paul Hammond citam pela primeira vez o termo DEVOPS, onde demonstram uma cultura que une Desenvolvimento, Operações e QA (irei falar mais sobre esta cultura em artigos posteriores).

Uma pessoa que assistiu a palestra ficou fascinada: Patrick Debois. ele resolveu criar uma conferência chamada DEVOPS Day. A partir daí o termo se expandiu mundo a fora e a área de operações começou a abrir a cabeça para entrega contínua e ágil.

Quebrando paradigmas – Deploy Contínuo na infraestrutura

O curioso da adoção da infraestrutura ágil, é que diferente do velho paradigma que diz que quanto menos deploy você fizer no ambiente maior o índice de disponibilidade, você ter uma comunidade de entrega contínua reduz drásticamente a chance de ter um problema em produção.

É o que comprova o estudo da PuppetLab chamado “State of Devops”. Eles entrevistaram ao longo dos últimos 5 anos mais de 25 mil profissionais e chegaram aos seguintes números:

  • Organizações de alta performance fazem até 200x mais deploys e reduzem em 2.555 x o lead time (tempo de entrega de um produto da sua concepção ao lançamento).
  • O tempo de recuperação de uma falha é 24x mais rápido e 3x menos chances de ter uma falha em mudanças.
  • Os times de alta performance diminuem em 50% vezes o tempo em que perdem com problemas de segurança no ambiente.
  • Outro ponto é que reduzem em 22% a perda de tempo com re-trabalhos. O que faz com que eles fiquem maior parte do tempo focados em entrega de novos produtos.

Conclusão

A adoção da infraestrutura ágil é uma das bases para você implementar DEVOPS em sua empresa.

Não adiantará você ter todo o desenvolvimento e qualidade entregando de forma contínua se não tiver a infraestrutura conseguindo suportar todos os novos deploys.

Ter o time de infraestrutura participando junto ao desenvolvimento na elaboração do produto, aumenta o engajamento dos teus funcionários para melhores entregas.