Conteúdo


Agile DevOps

Ambientes Transitórios

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

Comments

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Agile DevOps

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Agile DevOps

Fique ligado em conteúdos adicionais dessa série.

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.

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

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 para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

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