As 'Ops' no DevOps
As “Ops” no DevOps
Recentemente, um cliente me fez uma pergunta muito interessante sobre DevOps. Minha equipe está apoiando sua empresa através de um processo de transformação digital iniciado pelo departamento de desenvolvimento, e ele trabalha no departamento de infraestrutura.
Ele e seus colegas se interessaram por essa “maneira moderna de trabalhar”, e estão fazendo o melhor que podem para se encaixar. Apesar de seus esforços, a velocidade para mudar ou fornecer novas infraestruturas é frequentemente vista como um gargalo para o desenvolvimento.
Ele perguntou: como a equipe de Operações pode ser ágil também?
Uma representação comum do DevOps
Ele pode ter pensado que sua equipe poderia implementar o Scrum como os desenvolvedores fizeram, e sua equipe estaria mais envolvida com suas tarefas e entregaria mais rapidamente. Mas há um pouco de equívoco.
Imagine a seguinte situação: somos uma equipe de Operações que lida com uma infraestrutura On Premisses. Nós nos reunimos para implementar essa estrutura agradável que os desenvolvedores estão usando e seguimos a receita de introdução de timeboxes Sprint que consistem em
- Planejando as atividades do sprint
- Reunião diária para ser transparente sobre o que é feito e será feito em breve
- Mostrando o trabalho e recebendo/dando feedback
Digamos que, no segundo dia, um dos usuários do desenvolvedor foi bloqueado. A senha de outro expirou. Enfrentamos problemas de conectividade depois de alguns dias causados por um problema com a configuração do proxy. No final do Sprint, tivemos que instalar uma atualização de segurança em um servidor, mas uma das dependências necessárias não era compatível com ela.
A questão é: muitas das demandas de Operações são urgentes. Um servidor fora do ar não é uma coisa com a qual você lidaria quando tivesse tempo, ele tem que ser corrigido assim que acontecer.
As equipes de operações geralmente trabalham com base em ticks, com níveis de prioridade. Não é fácil criar um backlog e segui-lo quando há uma organização inteira para suportar. A verdade é que, para este caso e muitos outros, o Agile simplesmente não é adequado.
Mesmo sem implementar um Agile Framework em si, os Operadores podem lidar melhor com esse tipo de cenário. Tyrell Payton escreveu um artigo incrível sobre isso, “Como as operações de TI podem funcionar melhor com equipes ágeis”, no qual ele dá algumas dicas úteis. Meu favorito é: embora alguns dos trabalhos não possam ser previstos, alguns deles podem. Se a equipe de operações estiver trabalhando perto da equipe de desenvolvimento, algumas necessidades podem ser facilmente identificadas, como servidores mais robustos ou melhor conexão com a Internet. Eles podem ser proativos e resolver esse tipo de problema antes mesmo que a equipe de desenvolvimento pergunte.
DevOps é mais do que Agile
Uma coisa que temos que ter em mente é que o objetivo não deve ser implementar uma estrutura específica, mas trabalhar de forma eficiente para trazer melhores resultados, o que é melhor descrito pelos princípios do DevOps do que pelo próprio Agile.
DevOps é sobre a redução do tempo de ciclo de entrega de valor de negócios para os usuários finais. O planejamento ágil é apenas uma das disciplinas que podem ser consideradas para conseguir isso, mas isso não significa que ele tenha que ser implementado por toda a empresa. Isso poderia até causar o efeito oposto – Ron Jeffries fala sobre isso em seu artigo cheio de isenções de responsabilidade “Os desenvolvedores devem abandonar o Agile”.
Um dos pontos-chave para alcançar o DevOps, como o nome sugere, é reduzir as barreiras entre Desenvolvimento e Operações, o que não é tão simples quanto parece.
Os desafios
Áreas separadas para Operações e Desenvolvimento — Além das startups, não é incomum que empresas de médio e grande porte tenham áreas completamente separadas para Operações e Desenvolvimento. Para separados, quero dizer que geralmente eles não são apenas equipes diferentes, mas têm gerentes e objetivos diferentes, até mesmo centros de custo distintos e, às vezes, ficam em edifícios diferentes. Pode levar a um conflito de interesses eventualmente.
Sobre a infraestrutura de Premisses – considero isso como a principal ameaça às entregas rápidas. Isso significa que a equipe de operações é responsável por manter não apenas a infraestrutura da própria empresa, como Servidores de Arquivos, Active Directory, Rede e computadores dos usuários, mas os ambientes das soluções digitais que a empresa oferece. O problema é que lidar com software hoje em dia não é como construir uma casa ou um avião – o software muda o tempo todo. Uma mudança de planos, como um crescimento inesperado dos pré-requisitos da solução, pode ser vista como algo negativo pelos operadores. Adicionar uma nova infraestrutura envolve adquirir novo hardware, instalá-lo, configurar seu middleware e suas conexões de rede… e essas coisas levam tempo. Por outro lado, preparar um ambiente maior do que o necessário para a solução atual, pensando que a solução pode crescer, pode implicar em prejuízos financeiros.
Burocracia – Geralmente vem junto com os dois tópicos acima. Para evitar um inferno para os operadores, a empresa cria processos, que consistem em diferentes tipos de tickets com seus próprios SLAs. Eles se tornam o maior medo dos desenvolvedores – tudo o que eles não conseguiram identificar cedo o suficiente provavelmente não será entregue pela equipe da Infra no final do Sprint. Eles logo começam a procurar atalhos para evitar a criação de tickets ou marcar cada ticket como urgente. Quando isso não é suficiente, eles solicitam que seus gerentes convençam os gerentes de Operações a priorizar seus tickets, criando um inferno para os operadores novamente.
Cultura – Tenho notado que Desenvolvimento e Operações têm pessoas com diferentes perfis e mentalidades. Normalmente, a principal preocupação de um desenvolvedor é trazer inovação para agregar valor ao negócio. A principal preocupação de um operador / sysadmin é a segurança, estabilidade e adição de tecnologia que eles podem realmente suportar e manter.
O primeiro passo — Trabalhar mais perto dos desenvolvedores
Boa comunicação e compreensão são pontos-chave no DevOps. Os operadores devem entender que o software não é tão previsível e as mudanças podem ser boas para os negócios. Os desenvolvedores devem entender que as mudanças podem levar tempo e devem ser rápidos em identificar e relatar qualquer mudança de plano, para que as operadoras possam trabalhar com menos pressão.
Para aproximar essas duas áreas, existem alguns modelos que podem funcionar:
Já vi equipes multidisciplinares, com especialistas em plataforma dentro de cada equipe de desenvolvimento de produtos. Nesse caso, a própria equipe é responsável por implantar e manter a solução, e existem outros especialistas dedicados a dar suporte ao ambiente como um todo, que podem conter mais de uma solução.
Também vi equipes separadas, mas dedicadas, trabalhando exclusivamente para apoiar cada produto, estando envolvidas em planejamentos ou outras reuniões e se comunicando com frequência.
Ambos os modelos têm duas coisas em comum: comunicação aberta e também tempo dedicado – é difícil apoiar uma solução específica quando você tem tickets de toda a empresa para resolver.
Seja o primeiro ou o segundo modelo, o objetivo é o mesmo: manter operadores e desenvolvedores trabalhando próximos. Todos os indivíduos envolvidos precisam entender as necessidades de negócios e as plataformas que estão usando, de modo que uma mudança não é vista como desnecessária e um atraso não é visto como uma falta de engajamento.
A infraestrutura pode crescer tão rápido quanto o software?
Mesmo com operadores dedicados trabalhando lado a lado com a equipe de desenvolvimento durante o ciclo de vida do produto, se sua empresa tiver um datacenter On Premisses, você poderá experimentar algo como o que é apresentado abaixo:
O que sua empresa esperava
O que realmente aconteceu
Isso acontece porque o trabalho de operações não é escalável. Há um limite do que uma única pessoa pode fazer por hora. Contratar mais pessoas para a equipe agrega um crescimento linear de capacidade, mas às vezes não é suficiente, já que o crescimento de uma solução digital pode ser exponencial.
Existem algumas disciplinas no DevOps que poderíamos explorar para trazer mais velocidade às Operações, mesmo em cenários adversos como este. Algumas delas introduzem mudanças radicais na Organização, outras são mais simples de alcançar e menos polêmicas. Comecemos por eles.
Infraestrutura como código
Esse conceito envolve a criação de scripts automatizados para baixar, instalar e configurar os requisitos de software de um ambiente. Pense nisso como um script powershell ou ansible, por exemplo, responsável por configurar uma máquina de desenvolvimento ou ambiente de implantação. Com a infraestrutura como um código, podemos replicar ambientes facilmente, testá-los e até mesmo testá-los.
No Azure e na AWS, por exemplo, é possível criar scripts para provisionar todo um ambiente, não apenas o software, mas também as máquinas virtuais e as conexões de rede.
É preciso alguma disciplina para manter os scripts, mas isso traz muito valor sem necessariamente quebrar nenhum paradigma na organização.
Integração Contínua e Entrega Contínua
Consiste em criar um conjunto de instruções em um script ou ferramenta para automatizar o fluxo de implantação. As ferramentas mais usadas são o Microsoft VSTS e o Jenkins.
O VSTS fornece uma ferramenta visual para definir um pipeline de implantações em diferentes ambientes, como DEV →BETA →PROD, por exemplo, com aprovadores, condições pré e pós e muito mais.
Há um exemplo abaixo dos conceitos de Integração Contínua (CI) e Entrega Contínua (CD). Todas as alterações no código-fonte acionam um Build, que constrói o software, garante que tudo esteja funcionando e gera um “pacote”, também chamado de artefato, pronto para ser implantado. Neste exemplo, há uma implantação automática após cada compilação bem-sucedida no ambiente DEV. Depois que a solução é validada, as alterações são aprovadas e o artefato é promovido para o próximo ambiente, BETA. Depois de validada, outro grupo de pessoas valida e aprova a solução e permite que ela seja promovida para o ambiente final, o PROD.
Exemplo de IC e CD
Tudo isso pode ser facilmente configurado. Depois que tudo estiver configurado, uma implantação que costumava levar horas por causa de seu processo complexo — pode ser iniciada por um desenvolvedor preenchendo um formulário de solicitação de implantação, especificando onde encontrar o pacote/artefato e como instalá-lo e configurá-lo em cada ambiente — pode ser executada em poucos minutos, tão simples quanto pressionar um botão de aprovação.
Registro em log e monitoramento
Embora a implementação do log de aplicativos adequado seja uma responsabilidade da equipe de desenvolvimento, é uma prática fundamental para solucionar problemas que podem estar relacionados à infraestrutura, como problemas de conectividade, ou relacionados a aplicativos, como bugs.
O log de aplicativos deve ser combinado com o log do ambiente, coletado e exibido corretamente em uma ferramenta como Application Insights, New Relic ou outra plataforma. Ele fornece informações relevantes e permite que ambas as equipes identifiquem pontos de falha e melhorias nas quais devem trabalhar antes que se tornem críticas.
Containerization
Uma equipe de operações regular geralmente lida com virtualização. É um passo adiante em trabalhar com servidores bare metal em termos de velocidade – a empresa não precisa comprar novo hardware com tanta frequência, em vez disso, eles adquirem um cluster robusto e alocam seus recursos para criar servidores virtuais sob demanda. Se um servidor não for mais necessário, ele poderá ser desligado, seus binários poderão ser copiados e os recursos estarão disponíveis novamente. É fácil alterar a configuração de um servidor — adicione mais espaço em disco, RAM e núcleos de processamento. Também é fácil replicar o servidor, a fim de criar um saldo de carga, por exemplo.
Digamos que, com contêineres, você pode ter todas as vantagens da virtualização e muito mais.
Os contêineres são mais leves que as Máquinas Virtuais porque têm menos camadas de virtualização e compartilham mais recursos com a máquina host. Os binários de um contêiner, também nomeados como uma imagem, podem ter apenas 5MB! Este é o caso de uma imagem Alpine padrão, uma distribuição Linux.
O uso mais comum de contêineres é fornecer um ambiente em área restrita, com o sistema operacional e todas as dependências do aplicativo já configuradas, com o aplicativo auto-hospedado em execução sobre ele. O que será promovido para cada ambiente (DEV →BETA →PROD, por exemplo) é uma imagem pronta para ser executada descrevendo todo esse pacote, e não apenas o conteúdo do aplicativo.
O principal efeito é evitar o clássico problema “funciona na minha máquina” – quando o aplicativo funcionou na máquina desenvolvedora, mas falhou em outro ambiente. É comum porque o computador do desenvolvedor geralmente é muito diferente de um servidor, com diferentes sistemas operacionais, versões de software e capacidade de computação. Com os contêineres, as barreiras de Infraestrutura e Desenvolvimento se tornam realmente finas – o mesmo contêiner em execução na máquina de desenvolvimento será implantado em cada ambiente, até mesmo na produção.
Se o aplicativo já permite o dimensionamento por design (é sem monitoração de estado ou lida com dados de memória de acordo), o dimensionamento é tão simples quanto executar mais instâncias da mesma imagem.
A plataforma de contêiner mais popular é o Docker. Quando a solução envolve microsserviços, que geralmente são dezenas ou centenas de serviços conectados, uma plataforma de orquestração, como o Kubernetes, pode facilitar o gerenciamento.
Com o Kubernetes, você configura um mestre — o servidor de gerenciamento — e vários nós, que são servidores que armazenam os contêineres. Se um nó ficar indisponível, os contêineres em execução serão realocados para outros nós disponíveis. Muito trabalho que poderia implicar em interferência manual nos servidores poderia ser reduzido a tarefas administrativas no Kubernetes.
A nuvem é o limite
Todas as disciplinas mencionadas até agora podem ser implementadas em Premissas. Mas para dar mais um passo adiante é inevitável falar em Nuvens Públicas ou Híbridas.
Suponha que sua empresa tenha todas as outras disciplinas de DevOps bem implementadas. Há um cluster do Kubernetes (conteinerização), com scripts para configurar novos nós e projetos (infraestrutura como código) e pipelines automatizados para implantar os aplicativos (integração contínua e entrega contínua). Mesmo assim, se o cluster atingir seus limites, você ainda terá que comprar mais servidores. Levará algum tempo para que eles cheguem, mas depois que eles forem colocados corretamente, você poderá configurar os novos nós rapidamente e dimensionar os aplicativos sem esforço.
Isso significa que uma operação que poderia levar semanas, agora leva apenas alguns dias, dependendo principalmente da velocidade que os novos servidores chegam. É definitivamente melhor, mas e se pudesse levar minutos?
Pensando como um serviço
A única maneira de conseguir isso é fazer uso de nuvens públicas. Talvez você não queira mover todos os seus dados e serviços para a nuvem, e provavelmente não deveria. Mas se sua equipe está interessada em eficiência, você deve se perguntar: existem alguns dos serviços que usamos que realmente precisam ser executados no local? Quanto tempo, energia, recursos humanos e financeiros gastamos para fornecer e manter um ambiente?
A maneira mais simples de migrar para a nuvem é criar uma estrutura equivalente como máquinas virtuais com IaaS:
A infraestrutura como serviço (IaaS) ajuda a evitar as despesas e a complexidade de comprar e gerenciar seus próprios servidores físicos e outras infraestruturas de datacenter. Cada recurso é oferecido como um componente de serviço separado, e você só precisa alugar um determinado pelo tempo que precisar. O provedor de serviços de computação em nuvem gerencia a infraestrutura enquanto você compra, instala, configura e gerencia seu próprio software — sistemas operacionais, middleware e aplicativos. — O que é IaaS/Azure
Se você estiver pensando em usar contêineres, há alguns recursos específicos que abstraem a configuração e a manutenção de baixo nível, como as Instâncias de Contêiner do Azure (ACI) ou os Aplicativos Web para Contêineres, nos quais você pode publicar contêineres que não precisam de orquestração avançada. O Serviço Kubernetes do Azure (AKS) ou o Service Fabric são mais adequados para cenários complexos.
Estes são bons exemplos de Contêineres como Serviço, ou de uma forma mais geral, Plataforma como Serviço:
A Plataforma como Serviço (PaaS) é um ambiente completo de desenvolvimento e implantação na nuvem, com recursos que permitem que você forneça tudo, desde aplicativos simples baseados em nuvem até aplicativos corporativos sofisticados e habilitados para a nuvem. Você compra os recursos de que precisa de um provedor de serviços em nuvem em uma base de pagamento conforme o uso e acessa-os por meio de uma conexão segura com a Internet.
Como o IaaS, a PaaS inclui infraestrutura — servidores, armazenamento e rede — mas também middleware, ferramentas de desenvolvimento, serviços de business intelligence (BI), sistemas de gerenciamento de banco de dados e muito mais. A PaaS foi projetada para oferecer suporte ao ciclo de vida completo do aplicativo Web: criação, teste, implantação, gerenciamento e atualização.
A PaaS permite que você evite a despesa e a complexidade de comprar e gerenciar licenças de software, a infraestrutura de aplicativos subjacente e o middleware ou as ferramentas de desenvolvimento e outros recursos. Você gerencia os aplicativos e serviços que desenvolve e o provedor de serviços em nuvem normalmente gerencia todo o resto. — O que é PaaS / Azure
Com IaaS você tem mais controle do software subjacente. Pode ser uma coisa positiva se você tiver uma implementação específica de um serviço que o provedor de PaaS não oferece. Se você usar uma instalação padrão, a PaaS o poupará de instalar o serviço e garantir sua disponibilidade 24 horas por dia, 7 dias por semana.
Além da eficiência, as principais vantagens das soluções “As A Service” são:
Eles são econômicos: Basicamente, você pode pagar pelo que usa, mesmo em IaaS, devido à simplicidade de criar e descartar todo um ambiente. Um bom exemplo é o Teste de Carga – esse tipo de ambiente é preferível ser o mais semelhante possível à produção. Seria muito caro tê-lo em premissas, mas em nuvens públicas, você pode facilmente replicar o ambiente de produção, executar todos os testes, coletar os resultados e descartar o ambiente após a conclusão dos testes. Você será cobrado apenas pelos dias em que o ambiente esteve ativo.
Eles trazem menos sobrecarga administrativa: Ele poupa você de tarefas de operações que são mais mecânicas e lhe dá tempo para trabalhar com decisões de nível superior. Mais importante ainda, você não precisa de uma equipe trabalhando 24 horas por dia, 7 dias por semana, para dar suporte ao meio ambiente. A plataforma de nuvem de sua escolha é responsável por isso.
Eles permitem que a empresa se concentre em seu core business: Correndo o risco de afirmar o óbvio, a maioria das empresas digitais que têm um datacenter privado não vende armazenamento ou hospedagem de dados. Eles têm um e-commerce, ou uma plataforma, ou outro tipo de produto. Com IaaS ou PaaS, a empresa pode se concentrar em seu negócio principal, em vez de na infraestrutura de TI, em diferentes níveis. Então, a questão é: por que eles ainda não mudaram suas soluções para a nuvem?
É seguro?
Na maioria dos casos, é por causa de preocupações de segurança. Se você faz parte da equipe de Operações, é pago por se preocupar com a segurança. O trabalho da sua equipe é fornecer e manter um ambiente estável, seguro e confiável, especialmente se sua empresa lida com dados altamente confidenciais, como transações financeiras.
Mas vamos rever alguns fatos sobre os grandes provedores de nuvem pública:
- Eles têm uma infraestrutura melhor do que você.
- Eles têm mais pessoal e recursos para mantê-lo do que você.
- Eles têm mais certificados de segurança do que você.
- Eles têm um SLA mais forte do que você.
Ainda não acredita? Assista a este breve vídeo sobre o Azure Datacenter e pense se o datacenter privado da sua empresa poderia ser mais confiável do que isso.
Se você quiser ter mais detalhes, assista ao vídeo abaixo do Microsoft Build 2018, no qual o CTO do Microsoft Azure, Mark Russinovich, explica sobre os Datacenters, Rede, Servidores e muito mais do Azure.
Conclusão
Quando uma organização não tem operadores dedicados trabalhando com os desenvolvedores no ciclo de vida de seus produtos, é provável que as demandas de infraestrutura sejam vistas como um gargalo. Muitos fatores podem piorar o cenário, como a infraestrutura On Premisses e a falta de comunicação ou objetivos comuns entre os desenvolvedores e operadores.
Os melhores aliados dos operadores são as ferramentas e recursos que trazem eficiência. Pode envolver infraestrutura como código, integração e entrega contínuas, contêineres, nuvens híbridas ou públicas em diferentes modelos – IaaS e PaaS, por exemplo. Produzirá muitas melhorias para a organização, reduzindo custos, riscos, aumentando a disponibilidade e elasticidade dos ambientes. A velocidade de provisionamento de novos servidores ou plataformas pode ser reduzida de semanas para minutos. Os operadores gastarão menos tempo com tarefas mecânicas e poderão se concentrar em decisões estratégicas e administrativas de nível superior.