Agile DevOps: Ambientes Transitórios

Gerenciando a ilusão de capacidade infinita para reduzir a escassez de ambiente

Frequentemente, depois da provisão de um ambiente compartilhado, ele nunca é desatribuído e pode executar por semanas ou meses, com engenheiros aplicando alterações de configuração manuais por todo o seu tempo de vida. Essa abordagem arriscada causa regularmente problemas de implementação e faz com que outros erros de "ambientes" estranhos ocorram durante os ciclos de implementação, teste e produção. Esta parte do artigo Agile DevOps explica como criar ambientes efêmeros que sejam terminados em uma base frequente. Assim que todos os ambientes estão com script e versão, esses ambientes de teste são usados apenas o suficiente para executar um conjunto de teste à medida que o software se move por uma pipeline de entrega no seu caminho para produção.

Paul Duvall, CTO, Stelligent

Paul DuvallPaul Duvall é o CTO da Stelligent. Um palestrante de destaque em muitas importantes conferências de software, ele trabalhou em praticamente todas as funções em projetos de software: desenvolvedor, gerente de projetos, arquiteto e testador. Ele é o principal autor de Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley, 2007) e Ganhador do 2008 Jolt Award. Ele também é autor de Startup@Cloud e DevOps in the Cloud LiveLessons (Pearson Education, junho de 2012). Ele contribuiu para vários outros livros também. Paul é autor da série de 20 artigos Automation for the people no developerWorks. Sua paixão é levar software de alta qualidade aos usuários de forma mais rápida e com maior frequência por meio da nuvem e de entrega contínua. Leia seu blog em Stelligent.com.



30/Out/2012

Sobre esta série

Os desenvolvedores podem aprender muito com o pessoal de operações, e o pessoal de operações pode aprender muito com os desenvolvedores. Esta série de artigos é dedicada a explorar os usos práticos de aplicar uma mentalidade de aplicativo ao desenvolvimento, e vice-versa — e de considerar produtos de software como entidades holísticas que podem ser entregues com maior agilidade e frequência que nunca.

Em economia, escassez é o problema fundamental de se "ter humanos [com]... desejos e necessidades ilimitados em um mundo de recursos limitados" (veja Recursos). Quando os recursos são escassos, as pessoas competem pelo acesso a eles. A competição por recursos é evidente quando as pessoas obtêm acesso a ambientes em projetos de software tradicionais.

A boa notícia é que graças à comoditização de hardware, virtualização e computação em nuvem, essa competição pode ser reduzida grandemente quando padrões e práticas adequados — tais como ambientes transitórios — são usados em um projeto. Os ambientes transitórios são ambientes de curta duração que são terminados em uma base frequente. Para ser claro, a escassez nunca desaparece, mas você experimenta a ilusão de capacidade infinita. Ao aplicar o padrão de ambiente transitório, você começará a esquecer de que isso é apenas uma ilusão.

Algumas vezes, você vê esses tipos de ambientes ser chamados de outros nomes, incluindo efêmeros, temporais, temporáriose descartáveis. Todos esses significam essencialmente a mesma coisa — que os ambientes que não são de produção duram o mínimo possível. Recentemente, minha empresa tem recomendado que eles não durem mais de 72 horas — e isso na extremidade alta.

Motivações

Um dos problemas mais desafiadores no desenvolvimento de software ocorre quando as equipes precisam corrigir instâncias que ninguém mais pode alterar. Frequentemente, isso ocorre porque o ambiente leva dias, semanas ou meses para ser configurado. Isso é um antipadrão que ocorre porque ninguém tira um tempo para gerar os scripts de criação do ambiente. Assim, os ambientes são recursos escassos, e a competição por eles é feroz. Quando existem políticas de locação de ambiente, elas são frequentemente ignoradas ou os prazos de locação são estendidos várias vezes.

O que é um ambiente?

Um ambiente não é apenas um outro nome para uma máquina (física ou virtual). Um ambiente é uma coleção de recursos do sistema incluindo — não de forma exclusiva — instâncias (físicas, virtuais ou abstrações de máquina), configuração de rede, servidores de software e configuração (para cada uma das instâncias), balanceadores de carga e outros recursos que são tratados como uma unidade lógica. É possível instanciar ambientes com base em modelos ou outra configuração.

A maioria dos projetos que eu vi não tinha políticas de locação de ambiente — ou elas eram definidas muito liberalmente e frequentemente violadas. Para aqueles que não têm políticas de locação, os ambientes necessitam da instalação manual de ferramentas, datas e configuração — depois de o ambiente ter sido criado. Isso torna cada ambiente exclusivo e, portanto, mais difícil de gerenciar, porque centenas de ambientes podem ser provisionados em projetos corporativos maiores. Nesse caso, não há nenhuma abordagem simples para obter uma linha de base do ambiente. Além disso, nenhum membro da equipe sabe como retornar a esse estado de linha base. Como resultado, os membros da equipe podem ficar relutantes de terminar — ou mesmo modificar — tais ambientes. Esse antipadrão torna proibitivamente mais caro criar e terminar ambientes.


Recursos

Com ambientes transitórios, todos os ambientes são transitórios, exceto os de produção (embora haja modos efetivos de tornar ambientes de produção transitórios também). Ainda que isso possa variar entre projetos, a heurística é que esses ambientes existam por apenas tempo suficiente para executar um conjunto de testes automatizados e exploratórios. Os pré-requisitos principais para ambientes transitórios é que eles sejam baseados em script, testados e atribuídos em versão. Em condições ideais, você deve estar usando uma ferramenta de automação de infraestrutura como aquela que eu abordei em "Agile DevOps: Infrastructure automation."

Os principais recursos que compõem os ambientes transitórios são:

  • Ambientes baseados em scripts: eles são completamente baseados em script, atribuídos em versões e testados.
  • Ambiente de autoatendimento: qualquer pessoa autorizada na equipe pode ativar um novo ambiente.
  • Término automático: os ambientes são automaticamente baseados na política da equipe. Os membros da equipe não têm nenhuma opção para substituir a política.

Assim que você tenha um ambiente completamente baseado em script, é possível ativar membros de equipe autorizados para obtê-lo em um modo de autoatendimento. Com a liberdade para ativar simplesmente e terminar exemplos sob demanda vem a responsabilidade. Essa responsabilidade é reforçada para definir políticas de finalização e forçar essas políticas por processos automatizados que terminam os ambientes em uma base regular. (Abordarei as infraestruturas conduzidas a teste e com versão em artigos futuros nesta série).


Benefits

Participe

Uma comunidade de transformação Agile fornece notícias, discussões e treinamento para ajudar você e sua organização a desenvolver uma base sobre princípios de desenvolvimento Agile.

Por definir políticas de ambiente transitório e automatizar a implementação das políticas nos seus projetos, é possível reduzir a proliferação de ambientes exclusivos, implementações de autoatendimento de suporte, aumentar automação da instanciação do ambiente, mover-se para uma cultura de ambientes como commodities, permitir o isolamento de teste e reduzir significativamente a quantidade de resolução de problemas em problemas específicos do ambiente. Alguns dos benefícios principais são:

  • Reduzir a dependência do ambiente: reduza a dependência que a sua equipe tem de um ambiente específico fornecendo o recurso para ativá-los e terminá-los de acordo com a sua vontade.
  • Melhor utilização de recurso: ao finalizar ambientes que não estão mais sendo usados, você libera capacidade para outros.
  • Transferência de conhecimento: quando os membros da equipe sabem que seus ambientes serão terminados em tempos específicos, a automação torna-se a única solução para o conhecimento institucional de como o ambiente é configurado.

Como funciona

A coisa boa sobre ambientes transitórios é que ele é um padrão especialmente simples de implementar uma vez que os ambientes são completamente baseados em script, atribuídos em versão e testados. A esta altura, você tem três tarefas primárias para executar:

  • Criar uma política de equipe: em colaboração com seus membros de equipe, determine a política de equipe com base nos requisitos do projeto. Eu recomendo iniciar agressiva e regularmente reduzindo o número de horas que esse ambiente funciona — para cerca de 72 horas.
  • Automatizar o término do ambiente: escrever um script que termine todos os ambientes que excedam as políticas de locação da equipe.
  • Programar o término do ambiente: programe um processo para executar em uma base regular que executa o script de terminação do ambiente.

Baseie a sua política de equipe no tempo que leva para executar todo o teste necessário.

Para programar o término do ambiente, é possível iniciar usando um programador como cron ou — se estiver usando o Java — Quartz (veja Recursos). Também é possível usar o planejador fornecido pelo servidor Continuous Integration para executar uma tarefa em um tempo regular cada dia. Este exemplo mostra uma expressão cron que executa um script uma vez por dia, às 2:15.

0 15 02 * * /usr/bin/delete_envs.sh

O próximo exemplo usa a interface de linha de comandos fornecida pelo Amazon Web Services (AWS) CloudFormation para terminar um ambiente como definido por uma pilha CloudFormation:

/opt/aws/apitools/cfn/bin/cfn-delete-stack --access-key-id $AWS_ACCESS_KEY \
--secret-key $AWS_SECRET_ACCESS_KEY --stack-name $current_stack_name --force

Um script como esse pode ser expandido para loop por um catálogo de ambiente e terminar todos os recursos associados.

Por definir uma política de equipe agressiva, programar um processo e automatizar a terminação de ambiente, sua equipe pode gerenciar recursos proativamente e reduzir a possibilidade de que os ambientes dos quais o projeto depende existam por semanas ou meses.

Resolução de problemas

Como a resolução de problemas do ambiente normalmente funciona na maioria dos projetos? Em minha experiência, é um longo caminho determinar o que mudou, quem mudou e por quê. Frequentemente, várias pessoas investigam o problema para determinar a solução adequada. O problema é frequentemente replicado porque cada ambiente é exclusivo — como modificações exclusivas são feitas nele já que ele executa por semanas ou meses.

Como alternativa, com uma política de ambiente transitório — ambientes baseados em script, atribuídos em versões e testados — você fica com o ambiente em um estado conhecido. Para fazer isso, ative um novo ambiente e aplique as alterações para determinar seu efeito. Em seguida, grave testes e scripts automatizados e atribua versões às alterações. Como o gerenciamento de mudança está em vigor, sempre é possível retornar a um estado conhecido para fazer alterações, em vez de gastar horas ou dias determinando o que mudou em um ambiente modificado por milhares de usuários. Essa é a essência de ter um ambiente canônico.


Uma suspensão transitória

Neste artigo, você aprendeu que ambientes Agile DevOps duram o mínimo possível — apenas algumas horas e até poucos dias. Por definir uma política e programar o término automatizado de ambientes, você reduz a dependência de um número limitado de ambientes exclusivos, utiliza melhor os recursos e encoraja a automação de modo que ambientes possam ser ativados e terminados sob demanda.

Na próxima parte do artigo Agile DevOps, você aprenderá a como criar um ambiente que falha constantemente — paradoxalmente, com a finalidade de prevenir falha. Nele, eu abordarei o Chaos Monkey, uma ferramenta desenvolvida pela equipe técnica da Netflix que intencional e randomicamente, mas regularmente, termina as instâncias na infraestrutura de produção do Netflix para assegurar que os sistemas continuem a operar no caso de falha.

Recursos

Aprender

Obter produtos e tecnologias

  • Quartz: Quartz é um serviço de planejamento de tarefas de software livre.
  • IBM Tivoli® Provisioning Manager: Tivoli Provisioning Manager habilita uma infraestrutura dinâmica automatizando o gerenciamento de servidores físicos, servidores virtuais, software, armazenamento e redes.
  • IBM Tivoli System Automation for Multiplatforms: Tivoli System Automation for Multiplatforms fornece alta disponibilidade e automação para aplicativos corporativos e serviços de TI.
  • Avalie os produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto online, use-o em um ambiente de nuvem ou passe algumas horas no no Ambiente de Simulação da SOA aprendendo a implementar Arquitetura Orientada a Serviços de modo eficiente.

Discutir

  • Participe da comunidade do developerWorks. Entre em contato com outros usuários do developerWorks, enquanto explora os blogs, fóruns, grupos e wikis orientados ao desenvolvedor.
  • Uma comunidade de transformação Agile fornece notícias, discussões e treinamento para ajudar você e sua organização a desenvolver uma base sobre princípios de desenvolvimento Agile.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tecnologia Java, Cloud computing
ArticleID=843403
ArticleTitle=Agile DevOps: Ambientes Transitórios
publish-date=10302012