Tecnologia de DevOps: infraestrutura em nuvem

Muitas organizações estão adotando a computação em nuvem. Mas há mais na nuvem além de comprar sua infraestrutura de um provedor de nuvem. O Instituto Nacional de Padrões e Tecnologia (NIST, na sigla em inglês) dos EUA define cinco características essenciais da computação em nuvem (link em inglês):

  • Autoatendimento sob demanda: os consumidores podem provisionar recursos de computação conforme necessário, sem interação humana do provedor.
  • Acesso à rede amplo: os recursos podem ser acessados por meio de várias plataformas, como smartphones, tablets, laptops e estações de trabalho.
  • Pooling de recursos: os recursos do provedor são agrupados em um modelo multilocatário, com recursos físicos e virtuais atribuídos dinamicamente sob demanda. O cliente pode especificar o local em um nível mais alto de abstração, como país, estado ou data center.
  • Elasticidade rápida: os recursos podem ser provisionados de maneira flexível e liberados para aumentar ou diminuir rapidamente sob demanda, parecendo ilimitados e apropriados em qualquer quantidade a qualquer momento.
  • Serviço medido: os sistemas em nuvem controlam, otimizam e informam automaticamente o uso de recursos com base no tipo de serviço, como armazenamento, processamento, largura de banda e contas de usuário ativas.

O relatório State of DevOps 2019 da DevOps Research and Assessment (DORA) descobriu que apenas 29% das pessoas que alegam ter adotado tecnologias de nuvem concordaram ou concordaram totalmente que atenderam todas as cinco características definidas acima. Em 2018 e 2019, a pesquisa da DORA descobriu que as equipes de alto nível eram 23 vezes mais propensas a ter atingido as cinco características essenciais da nuvem do que as de baixo desempenho. Isso pode explicar por que equipes e executivos que alegam ter adotado tecnologias de computação em nuvem também expressam frustração por não conseguir os resultados esperados.

Como muitas organizações ainda usam as práticas e os processos tradicionais do data center para gerenciar a infraestrutura de nuvem, eles não conseguem alcançar os benefícios esperados, que, de acordo com a pesquisa DORA, incluem:

  • Melhor desempenho de entrega de software: capacidade mais rápida e níveis mais altos de estabilidade.
  • Melhor disponibilidade de serviço
  • Visibilidade de custo aprimorada: em 2019, descobrimos que os entrevistados que atenderam a todas as características essenciais da nuvem tinham 2,6 mais chances de estimar com precisão o custo de operação do software. Eles também são 2 vezes mais propensos a identificar facilmente os aplicativos mais caros em termos operacionais.

Por exemplo, muitas organizações com infraestrutura em nuvem não permitem que os desenvolvedores autoatendam os ambientes sob demanda: elas exigem que eles aumentem tíquetes ou enviem e-mails e aguardem dias para que os ambientes sejam provisionados ou para que as alterações de configuração sejam feitas. Nesse caso, mesmo que a organização possa pagar por um serviço de nuvem, ela não tem uma nuvem de acordo com a definição do NIST.

Ao migrar para a nuvem, as organizações precisam investir na reformulação dos processos e práticas que implementaram quando usavam data centers tradicionais. Eles precisam adotar padrões e práticas nativas da nuvem para alcançar a agilidade, a estabilidade, a disponibilidade e a transparência de custos da computação em nuvem. Se a tecnologia subjacente estiver na nuvem, mas os resultados para os profissionais permanecerem inalterados (dias ou semanas para conseguir ambientes de teste, provisionar nova infraestrutura ou receber alterações de configuração), as organizações não terão os resultados pretendidos.

Como implementar a infraestrutura em nuvem

A adoção de processos e práticas nativas da nuvem para implementar as cinco características do NIST envolve mudanças significativas por várias funções de TI, incluindo desenvolvedores, equipes de operações, segurança das informações, compras e finanças. As alterações exigem uma estreita colaboração entre essas funções para identificar e resolver objetivos conflitantes.

Por exemplo, muitos desenvolvedores esperam ter controle total sobre a infraestrutura de produção ao usar plataformas de nuvem. Profissionais de segurança da informação se opõem a essa prática por um bom motivo, sem gestão da mudança com disciplina, a infraestrutura de nuvem se transforma em uma obra de arte frágil de gerenciamento, vulnerável para ameaças externas e que não atende aos requisitos regulamentares.

No entanto, os desenvolvedores podem ser capacitados para provisionar os recursos necessários enquanto atendem a esses requisitos. Muitas organizações adotaram o paradigma de infraestrutura como código. O GitOps é um exemplo. A configuração da infraestrutura é verificada no controle de versões, e os desenvolvedores podem provisionar ambientes, fazer alterações de configuração e executar implantações por meio de um mecanismo automatizado. O mecanismo extrai o código do controle de versão e executa operações por meio da API da nuvem sob demanda, sem intervenção humana. Com o controle e a automação de versões, todas as ações e os resultados delas são registrados para fornecer capacidade de rastreamento completa e auditoria de cada alteração em cada ambiente.

A infraestrutura como código permite que você gerencie as alterações com eficiência e aplique os controles de segurança da informação. Por exemplo, é possível implementar a segregação de tarefas exigindo que todas as alterações na configuração especificada no controle de versões sejam aprovadas por alguém de um grupo específico de pessoas (como é feito no Google). No entanto, a mudança para a infraestrutura como código requer um esforço significativo de engenharia e alteração de processos, incluindo a alteração de políticas para implementar controles de segurança das informações.

Considere outro exemplo. Os provedores de nuvem costumam cobrar por infraestrutura enquanto ela está em uso (atendendo a quinta característica de serviço de medição do NIST), mas essa mudança da infraestrutura de custo fixo para custo variável pode ter implicações significativas para a aquisição e o financeiro. Conforme descrito no relatório State of DevOps 2019:

"Algumas pessoas nas finanças podem dizer que a nuvem não aumentou a economia em curto prazo, mas sabemos que ela oferece mais transparência na informação. Como isso é possível? Ainda que a nuvem forneça informações transparentes sobre os custos aos proprietários do sistema, os usuários não pagam por eles, a menos que haja um modelo de estorno ou mecanismo semelhante. Isso pode levar a custos muito variáveis que não são checados, tornando os custos de nuvem imprevisíveis. Nesses cenários, as equipes que pagam por infraestrutura podem preferir data centers porque são previsíveis, mesmo que a visibilidade incentive os usuários do sistema a criar sistemas mais eficientes. Sugerimos que as organizações alinhem melhor os incentivos para que os proprietários do sistema tenham visibilidade para criar sistemas mais eficientes e para que os incentivos façam isso, usando estorno ou mecanismos semelhantes."

Além de considerar como a infraestrutura é gerenciada no nível de configuração e finanças, os aplicativos geralmente precisam ser reprojetados para aproveitar os benefícios da maior estabilidade, confiabilidade e agilidade que a nuvem fornece. A reestruturação de sistemas em um modelo de nuvem nativa é discutida no artigo do Google Cloud Nova arquitetura para a nuvem nativa: uma abordagem evolutiva para aumentar a produtividade do desenvolvedor em escala.

A consideração mais importante é se a implantação na nuvem ajudou sua organização a alcançar versões mais seguras e confiáveis e níveis mais altos de disponibilidade, velocidade e confiabilidade (em inglês).

Dificuldades comuns da implementação da infraestrutura em nuvem

Os maiores obstáculos para atender às cinco características definidas pelo NIST são:

  • alinhamento e colaboração insuficientes entre as funções organizacionais que precisam trabalhar juntas para implementá-las;
  • investimento insuficiente em mudanças técnicas, de processos e organizacionais.

Muitas organizações começam com uma abordagem de migração lift-and-shift para mover aplicativos para a nuvem. Ela requer uma alteração mínima nos aplicativos e nos processos estabelecidos para gerenciar a infraestrutura de nuvem e pode ser feita de maneira relativamente rápida. Mas também oferece benefícios mínimos. É importante planejar além da migração lift-and-shift para um paradigma nativo da nuvem para novos softwares, bem como para os sistemas estratégicos atuais que continuarão a evoluir.

A migração para a nuvem é uma jornada de vários anos. Como todas as mudanças que causam interrupção, é importante começar devagar e testar rapidamente para descobrir o que funciona ou não, e ser persistente e disciplinado sobre os aprendizados de escalonamento horizontal e padrões e práticas eficazes em toda a organização.

Haverá muitos obstáculos nesta jornada, incluindo:

  • redefinição de processos, arquitetura e governança para atender aos requisitos regulamentares, de maneira nativa da nuvem;
  • planejamento da arquitetura de infraestrutura de vários locatários, para que as equipes possam fazer implantações de autoatendimento e alterações de configuração, garantindo separação lógica entre ambientes, possibilitando estornos e impedindo a expansão da nuvem e infraestrutura órfã;
  • criação de um recurso de desenvolvimento de produtos para sua plataforma de infraestrutura em nuvem;
  • ajuda na transição de compras para a infraestrutura como um serviço limitado em vez de um investimento em capital;
  • ajuda para os desenvolvedores entenderem a criação de aplicativos nativos da nuvem;
  • permitir que as operações mudem para as práticas modernas de engenharia de confiabilidade do site (SRE), incluindo a implantação de infraestrutura como código como substituto para o gerenciamento manual de configurações baseadas em tíquetes (link em inglês);
  • planejamento e execução da integração entre sistemas nativos da nuvem e sistemas não baseados na nuvem, incluindo mainframes e software empacotado/COTS.

Para superar esses obstáculos, é necessário um programa de mudança substancial que envolva investimento e colaboração contínuos entre pessoas de todos os níveis da organização.

Como avaliar a infraestrutura em nuvem

Para decidir o que avaliar, comece considerando os benefícios que você espera ganhar com a implementação da infraestrutura em nuvem. Em seguida, comece a avaliar até que ponto esses benefícios estão sendo realizados.

Por exemplo, se sua meta é melhorar a visibilidade dos custos, é possível acompanhar o desempenho da infraestrutura para garantir que o custo dela seja cobrado corretamente para a linha de negócios, a equipe, o produto ou o ambiente relevante.

Você também pode avaliar diretamente se foi ou não um bom trabalho implementar as características essenciais do NIST: pergunte às equipes até que ponto elas concordam com as declarações dessas características listadas no início deste documento. Equipes que concordam ou concordam totalmente estão indo bem. As equipes neutras ou que discordam precisam de ajuda e suporte para remover obstáculos e atingir os resultados. Depois, pense em quantas equipes que usam a nuvem podem realmente atender aos critérios do NIST.

Alguns aspectos das características essenciais também podem ser medidos diretamente por meio da instrumentação dos processos. Por exemplo, se você tem um processo para gerenciar alterações de infraestrutura, é possível medir o tempo necessário para fazer uma alteração. Você também pode ver como as tecnologias nativas da nuvem são comuns na sua organização: por exemplo, a proporção de clusters ou máquinas gerenciadas usando o Kubernetes ou grupos de escalonamento automático em vez do provisionamento manual ou o tempo de vida dos hosts. Em data centers, longos tempos de atividade geralmente indicam alta confiabilidade. No paradigma nativo da nuvem, geralmente são feitas alterações de configuração iniciando novos hosts virtuais com a nova configuração, em vez de alterar os atuais. Essa prática é conhecida como infraestrutura temporária, em que um longo tempo de atividade é um indicador de uma máquina sem patch.

A seguir