Afinal o que é DevOps

Sempre em minhas palestras começo dizendo que "DevOps" não é um cargo que aparecem no
linkedin, não é um departamento, mas sim uma cultura, que por mais incrivel que seja não tem
ainda uma manifesto! Mas vamos voltar uma pouco no tempo, para contar uma parte da história, em
2008, começaram a utilizar o termo "Infraestrutura ágil" em algumas listas de discussão com foco
no desenvolvimento ágil, e na mesma época durante o evento Agile 2008, surgiram conversas que
abordavam o tema metodologia ágil, para administração de infraestrutura, inspirada no modelo ágil
de desenvolvimento, a lista de discussão com nome agile-sysadmin que começou a abordar o tema
com propriedade, ajudou a colocar os primeiros tijolos na ponte que faria a ligação entre developers
e sysadmins. Um dos participantes desta lista era Patrick Debois (@patrickdebois), além de muito
ativo ele era e ainda é um grande entusiasta do assunto.

Em 2009 foi a primeira vez que foi citado o termo "DevOps", no famoso evento europeu chamado
Velocity organizado pela empresa O'Reily, edição que contou com os engenheiros da famosa Flickr,
onde mostraram um pouco das métricas de desenvolvimento e que ja trabalhavam com mais de 10
deploys por dia, na época todos os participantes ficaram maravilhados com tal revelação, era algo
surreal, , logo em 2010, foi realiza então o maior encontro sobre o assunto, o "DevOpsday", que
agora e realizado em vários países ao redor do mundo...É importante falar que ao levar o evento
para diversas cidades, os realizadores deste evento foram responsáveis por disseminar a cultura
"DevOps", com isso, direta ou indiretamente eles se tornaram a força motriz de uma discreta
revolução no mundo da TI.

Inicialmente a cultura "DevOps" se mostrou muito presente no ambiente das startups, porém, algum
tempo depois começou a fazer parte do mundo corporativo, aqui neste texto procuro trazer a visão
da cultura DevOps no meio corporativo.

Apesar de existir um evento que é realizado em diversos países, nunca foi estabelecido um
manifesto ou manual para o assunto, de como aplicar a cultura, portanto existem várias
interpretações acerca deste termo, então não tem como eu lhe dizer se você esta aplicando ou não a
cultura dentro da sua empresa.

Mas antes de determinar ou não a aplicabilidade da cultura, vamos entender a dinâmica entre os
times das areas de infraestrutura(ops) e desenvolvimento(dev), espero que isto lhe ajude a
compreender melhor o que teremos o por que do "DevOps".

Imaginamos o seguinte cenário, uma empresa que desenvolve aplicações web, em sua maioria
portais e em alguns caso aplicações web, nessa empresa o desenvolvedor lida com várias
linguagens, PHP, Python, Ruby, JAVA, consideramos dois perfils para este exemplo:

1 - O desenvolvedor que já trabalha com metodologias ágeis (evolutivo e continuo)

2 - A infra que trabalha no modelo tradicional de administração(muitas vezes manual e
reativo)

Foco na INFRA

O Time de infra e sempre composto por sysadmins, que tem a missão de manter os sistemas
funcionando, são eles que fazem os deploys ou rollbacks das aplicações dos DEVs, e ainda ter a
responsabilidade de manter o ambiente de produção estável e intacto, os sysadmins, tem que rodar
as aplicações, monitorar o funcionamento, a performance, avaliar e propor melhorias de forma a
manter as aplicações rodando de forma rápida e estável minimizando os riscos envolvidos, tem que
se preocupar com a segurança, escabilidade e com o SLA de cada produto que é fundamental para o
negócio.

Entenda que se uma aplicação para de funcionar o impacto no SLA, pode gerar perdas financeiras
significativas, afinal, o produto fora significa cliente insastifeito e prejuízo, seja ele financeiro, seja
ele institucional, em resumo, a infra(sysadmins) se preocupam em proteger o valor do négocio.

Foco no DEV

O time Dev e composto por desenvolvedores, que trabalham com lógica e critividade, eles passam
boa parte do tempo codificando soluções, e focam seus esforços em construir aplicações baseadas
nos requisitos que um analista mapeou junto com o cliente, e constantemente estão aprimorando e
evoluindo novas versões de suas soluções, que precisam ser disponibilizadas para seus clientes, para
que estes possam usufruir os recursos solicitados.

Uma nova versão significa um novo deploy, caso ocorra um problema demandara'um rollback,
ambos realizados pelo time de Infra, em resumo, o Dev se preocupa em aumentar o valor do
négocio.

E onde está o conflito?

Os desenvolvedores querem mais rápido possivel, colocar suas aplicações em funcionamento, por
outro lado, os sysadmins querem ter certeza de que essa aplicação, está estável o suficiente para
entrar em produção, para que incidentes, paradas ocorram no ambiente ou serviço.

Este conflito durante muitos anos foi latente no mundo de TI, em alguns casos, as empresas impoem
regras tão rigidas que so permitem o deploy uma vez por semana, muitas vezes de madrugada, ou
em outras casos mais rigidos uma vez por mês, tudo isso pensando em proteger o negócio.

nem é preciso dizer que um deploy por semana não combinada nada com o desenvolvimento ágil,
com isso faz necessário que o time de infra, meça esforços para aumentar o numero de deploys,
para que as entregas do produto seja coerente com prazos acordados com cliente, mas claro que a
Infra trabalhando metodos que estava acostumado (deploy 1 vez por semana e manual) não dava
vazão para as demandas, e logo o Dev não consegue ter um ambiente adequado para desenvolver de
forma contínua.

E claro muitas vezes os Devs não tem conhecimento para prever aspectos importantes relativos a
infra, que fica de cara com o cliente, portanto, quando uma aplicação vai para produção,
normalmente ocorrem constantes incidentes, a vezes pequenos e outras grandes, que geram enorme
perdar de valor de negócio.

E com paradas, sistema fora do ar, por sua vez o cliente reclama - com razão - e a gerência de TI
tenta encontrar um ponto de falha ou dono do problema, um verdadeiro caça as bruxas, de um lado
o DEV dizendo que a culpa é da Infra que é muito engessada e do outro a infra dizendo que os Dev
fazem código ruim e instável e que não é culpa deles que a aplicação não funciona.

Para acabar com o conflito

Então, qual a receita mágica? Como melhorar sem afetar o négocio?

Segue algumas fatores importantes:

A Infra precisa evoluir, e precisa fazer isso rapidamente. O Dev precisa ter mais controle de todas
as fazes do deploy.

A Infra precisa começar a trabalhar de forma automatizada e dinâmica, precisando de velocidade

para subir novos ambientes ou mesmo reconstrui-los, para suprir as necessidades dos DEVs, não é
mais possivel trabalhar de forma manual e faz necessário o uso de novas metologias.

Infraestrutura como código, o objetivo é fazer deploy não só de aplicações, mas deploy de
infraestrutura de forma rápida e controlada.

Isso significa que se você precisa subir um ambiente JBOSS você vai fazer isto em poucos minutos
e não em dias.

Atualmente para se ter uma infraestrutura ágil, existem várias ferramentas, que basicamente temos
três tipos:

1.Orquestradores
2.Ferramentas para gerenciamento de configurações
3.Ferramentas para bootstrapping e provisionamento

Orquestradores são ferramentas que nos permitem executar comandos e controlar nodes/instâncias
de nosso parque em tempo real. Alguns destes são Fabric, Capistano, Func e Mcollective.

Ferramentas de gerência de configuração normalmente controlam estados de seu sistema, ajudam a

centralizar toda as configurações e facilitam a administração e criação de novos ambientes.
Algumas delas são Puppet, Chef, Cfegine e Salt.

Ferramentas de bootstrapping são aquelas que nos ajudam a instalar um sistema operacional seja em
uma máquina física, seja em um máquina virtual, seja em uma instância na nuvem, dentre elas
temos alguns provedores de CLOUD como AWS e Rackspace que já oferecem isso nativamente,
existem também ferramentas como o Kickstart e Cobbler que atuam neste segmento.

A combinação destes três tipos de ferramentas nos permite ter o que chamamos de infraestrutura
ágil.

Mas apesar da qualidade e dos ganhos em utilizar tais tecnologias, a ferramenta sozinha não
resolverá seus problemas, é preciso mudar a cultura e a forma de trabalhar a infraestrutura.

Uma equipe de infraestrutura ágil

Equipes que trabalham com infraestrutura ágil também precisam de um método diferenciado de
organização, normalmente estas equipes estão trabalhando seguindo estes eixos:

1.Versionamento do código e arquivos de configuração (git)

2.Organização de atividades de forma visual (KANBAN BOARD)
3.Trabalho em pares
4.Divisão das atividades em sprints
5.Reuniões ágeis diárias (standup meeting de 10 minutos - em pé)
6.Reuniões ágeis periódicas (retrospectiva e planejamento de sprints).

Parece com SCRUM mas não é, mas é fortemente inspirado nele e no Kanban.
Então DevOps e Infraestrutura ágil são a mesma coisa?

Não, infraestrutura ágil é parte da cultura DevOps.

DevOps depende de infraestutura ágil, mas ainda tem muito mais.

Apesar da evolução da infra, ainda falta algo que conecte as duas áreas, precisamos de um agente de
mudanças principalmente no meio corporativo.

A Cultura DevOps

Chegou a hora de entrar neste assunto, agora nós vamos aprofundar nossos estudos em relação a
cultura DevOps.

Características da cultura DevOps

Para entender a cultura devops sem fazer um texto muito longo, vou pontuar as suas principais
características - em minha opinião.

Em relação as características da cultura

Patrick Debois (foi quem cunhou o termo) diz que DevOPs essencialmente é uma cultura, e a
descreve utilizando 4 eixos, são eles:

Cultura
Colaboração
Fim das divisões
Relação saudável entre as áreas
Mudança de comportamento
Automação
Deploy
Controle
Monitoração
Gerência de configuração
Orquestração
Avaliação
Métricas
Medições
Performance
Logs e integração
Compartilhamento
O feedback é tudo
Boa comunicação entre a equipe

Como eu já mencionei não existe uma metodologia clara, DevOps ainda é um movimento em
constante construção e definição, eu citei uma série de melhorias que fazem parte da cultura
DevOps, cabe a cada empresa ou a cada gestor estudar e descobrir a melhor forma de combinar
essas pequenas receitas técnicas e aplicar em seu ambiente.

Espero que este artigo tenha te ajudado a entender melhor a cultura DevOPs.
Referencias

https://conferences.oreilly.com/velocity/vl-ca
https://pt.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
https://www.devopsdays.org/