It was a great event! For more information about miniPLoP, check the event website: http://www.miniplop.ita.br/Apresentacao.html

It was a great event and I’m very happy to be part of it. QCON was awesome! I hope you enjoy the pictures

Sexta passada estive no evento DevOpsDays, que aconteceu em Santa Clara (Califórnia), no escritório central do LinkedIn. O termo DevOps (criado por Patrick Debois) surgiu no final do ano passado, mais ou menos na época em que Andrew Schafer e Paul Nasrat deram uma palestra na Agile 2009 sobre Infraestrutura Ágil.

Onde Surgiu DevOps?

DevOps tem vários signifcados. O mais óbvio deles, como o próprio termo já diz, significa a união de Desenvolvedores (devs) e Operadores (ops) de Sistemas (também conhecidos como SysAdmins).

Em startups, é muito comum que não exista separação entre Devs e Ops. Nessas empresas, os técnicos sabem tanto escrever o software como dar manutenção e administrar os servidores de produção. Conforme as empresas crescem, começa a surgir a necessidade de especialização nas áreas de desenvolvimento e sysadmins (DBAs, Storages, Rede, Linux, Windows, etc). Problemas começam a surgir quando criam-se silos e a empresa fica dividida entre aqueles que criam o software e aqueles que mantém tudo funcionando em produção. Essa divisão pode ser muito nociva para a empresa, uma vez que os profissionais, ao invés de colaborarem para o sucesso da empresa, ficam num jogo de apontar o dedo um para o outro, na busca de um culpado que, convenhamos, pouco importa para o negócio.

DevOps tem o objetivo de trazer os conceitos e boas práticas aprendidas pelos Engenheiros de Software Ágeis para o mundo dos SysAdmins. Não só isso, DevOps também procura clarear para os desenvolvedores as preocupações (justas) e práticas dos SysAdmins. O principal trabalho do SysAdmin é manter tudo no ar. Qualquer coisa a mais que o desenvolvedor quiser, coloca em risco o trabalho o SysAdmin. O desenvolvedor tem que entender isso e trabalhar como parceiro do SysAdmin. Ele tem que se preocupar para que nada quebre em produção e estar disponível para ajudar o administrador caso algo dê errado. Faz parte do trabalho de devs e ops estarem alinhados e colaborarem um com o outro.

O vídeo abaixo, criado por Patrick Debois, foi exibido no início do DevOpsDays e vale a pena ser visto:

Cultura

Uma das grandes preocupações dos Administradores está relacionada com os requisitos não funcionais de um sistema. Requisito não funcional seria tudo aquilo que existe “por traz dos panos”, coisas que o cliente nem sabe que existe, mas que é fundamental para o sucesso do negócio. Alguns exemplos de requisitos não funcionais são: backup, monitoração, escalabilidade, balanceamento de carga, segurança. 89% das start-ups concentram todos os seus esforços em requisitos funcionais. Isso porque, segundo a filosofia ágil, precisamos entregar valor para o cliente o mais rápido possível. Isso faz com que os times foquem nas funcionalidades dos produtos e, algumas vezes, negligenciem a infra-estrutura que suportará o crescimento deste. Um dos grandes desafios é saber o momento de dedicar tempo para os requisitos não funcionais. Mas tanto desenvolvedores quanto sysadmins têm a obrigação de levantar essas necessidades para o PO e este, por sua vez, tem que ser muito perspicaz em ouvir os argumentos técnicos e ceder tempo de desenvolvimento é pró da evolução do produto.

Se formos refletir bem, DevOps não tem nada de novo em relação ao que foi dito há quase 10 anos, quando surgiu o Manifesto Ágil. O manifesto propunha que o cliente e o time trabalhassem juntos, numa relação de confiança e cumplicidade. DevOps propõe que esse “trabalhar junto” se estenda para todos os envolvidos. Não só quem faz o produto, mas também quem mantém (SysAdmins), quem vende (Comercial), quem divulga (Marketing), quem atende o cliente (suporte técnico). Todos têm que se conversar, se respeitar e principalmente, trabalharem juntos.

Em muitos casos, esse tipo de comportamento não é comum. Por isso, vestir a camisa de DevOps exige grandes mudanças culturais. Como foi bem dito no DevOpsDays, não se muda a cultura, se muda o comportamento. E essa mudança normalmente tem que partir da liderança. Se o gerente tem um comportamento de ficar acusando outros gerentes ou  membro de outros times, naturalmente os seus subordinados agirão da mesma forma. Se ao invés disso, o líder confiar nas pessoas e estiver presente nos momentos de tensão, sempre disposto a colaborar e a ouvir, seu time o seguirá, gerando um clima saudável de compromisso entre as áreas da empresa.

Infraestrutura como Código

Com o surgimento do Cloud Computing, fica cada vez mais fácil para uma empresa administrar e escalar a sua infra-estrutura de servidores. Hoje a nuvem permite que o único hardware de uma start-up seja a máquina de café. Todo o resto pode ser administrado remotamente, em máquinas criadas na Internet. Idealmente, essas máquinas não deveriam nunca ser acessadas. Tudo que for feito nelas deveria ser feito de forma automática. Hoje, já existem ferramentas de Gerenciamento de Configuração (Configuration Management ou CM) como o Chef, Puppet ou CFEngine que permitem que todo software (pacote) instalado em um servidor seja controlado de longe usando templates, receitas, papéis e outros artefatos, configurados e testados previamente. Isso significa que toda infra-estrutura de um produto pode estar mapeada em linhas de código, com testes e tudo mais.

Imagine a situação de um sistema de loja virtual que comece a crescer rapidamente. Um único servidor de Apache começa a não dar conta da enorme quantidade de requisições de clientes. O procedimento normal seria instalar um outro servidor, configurar todos os pacotes nele, coloca-lo atrás de um balanceador de carga e dividir o tráfego entre dois servidores. Mas se esse tráfego dobrar de novo? O SysAdmin terá que configurar outras duas máquinas? E se isso acontecer bem na época de Natal, onde as vendas explodem? Ele terá tempo hábil para configurar as novas máquinas? Claro que não. Essa estrutura tem que escalar de forma automática. Hoje, isso é possível! Podemos detectar automaticamente o aumento nos acessos e provisionar uma nova máquina para atender a demanda. Mais ainda: quando essa demanda cair, podemos excluir um dos servidores com baixa utilização para economizarmos recursos. Isso é Cloud!

Esse “céu encantado” só é possível se Dev e Ops trabalharem juntos. O deploy de uma aplicação precisa ser automatizado. Uma vez que o código em produção estará rodando em vários servidores, todas essas máquinas precisam ser atualizadas quando surgir uma nova funcionalidade. Se forem 20.000 máquinas (como é o caso do Facebook) isso só é possível se for de uma forma automática e muito bem organizada, inclusive com a possibilidade de rollback caso algo não dê certo por algum motivo.

E isso não é tudo

Essas ideias são apenas uma introdução a DevOps. O assunto é novo e muito pouco explorado. Se quiserem saber mais, separei algumas referências importantes:

1. Blog do Patrick Debois
2. Operações no Twitter
3. Site do DevOpsDays
4. Theo Schlossnagle – Scalable Internet Architectures
5. Adam Jacob, John Willis – Infrastructure Automation With Chef
6. Lee Thompson, Alex Honor – Getting Fast: Moving Towards a Toolchain for Automated Infrastructure
7. John Willis, Damon Edwards – The Infrastructure Philharmonic: How Out of Tune are Your Operations?
8. Andrew Clay Shafer – Change Management: A Scientific Classification
9. John Allspaw – Ops Meta-Metrics: The Currency You Use to Pay For Change
10. Perhaps DevOps Misnamed

Fotos do Evento

Após o DevOpsDays, fomos todos para um bar em Montain View conversar mais sobre o assunto. Foi muito divertido e “produtivo”. Seguem as fotos.

This weekend I was working at the first Random Hack of Kindess mundial edition. There were 4 people in our team and we worked on a project called Urban Fact (Fato Urbano in Portuguese). The main idea of this project is to emphasize GOOD orBAD facts in your city. If you see someone throwing the garbage over the streets, just take a picture and post it on twitter using #urbanfact hashtag (or #fatourbano). This picture automatically  goes to the project website, where people can vote, comment and share with friends.

For the solution, we used Rails for the web interface, MySql as database and Python for the backend twitter collector. We also used Google Maps API to automatically generate the map with all entries. All code is available at my github account. We hosted the website in a Locaweb Cloud Server.

Our project earned the 2nd best project prize!

Visit my flickr account to see the pictures of this event.

Apreciem com moderação!

http://picasaweb.google.com/danicuki/2008_10_10EncontroGil