Em teoria, um dos benefícios da computação em nuvem é que ela permite que as empresas paguem apenas pelos recursos que consomem. Na realidade, as organizações só desbloqueiam esse benefício se se destacarem no cloud parking – o que significa desativar os recursos quando eles não são necessários.

Infelizmente, é muito mais fácil dizer do que fazer o cloud parking. Identificar quais recursos alocar, estacioná-los e retirá-los de uma forma que não comprometa a confiabilidade e o desempenho da carga de trabalho pode ser bastante desafiador.

É por isso que é fundamental desenvolver uma estratégia sofisticada para cloud parking – o que o artigo ajuda você a fazer.

Abaixo, explico o que significa cloud parking, por que ele pode ser desafiador e como tirar o máximo proveito desse recurso, indo além das práticas básicas para desativar recursos de nuvem não utilizados.

O que é cloud parking?

O cloud parking, um componente do FinOps, é a prática de desligar recursos de nuvem quando sua empresa não os está usando.

Por exemplo, se você tiver uma instância de servidor em nuvem em execução em um serviço como o EC2, desativar o servidor quando ele não estiver hospedando uma carga de trabalho ativa é um exemplo de cloud parking.

Mais tarde, se você quiser usar o servidor novamente, você irá “desfazer o estacionamento” iniciando o backup da instância.

O cloud parking é importante porque quase todos os serviços de nuvem cobram, pelo menos em parte, com base no tempo total de execução.

Ao realizar o cloud parking de recursos de nuvem que você não está usando ativamente, você interrompe a cobrança e evita pagar por recursos que você realmente não precisa.

Ao lado de práticas como escolher as configurações de recursos certas e aproveitar os descontos de uso comprometido, o cloud parking é um passo fundamental para a otimização de custos na nuvem.

Os desafios do cloud parking

Desligar recursos de nuvem não utilizados pode parecer simples. No entanto, pode se tornar desafiador na prática, por vários motivos:

● Identificar recursos não utilizados: determinar quais recursos de nuvem estacionar pode ser difícil, especialmente em grandes organizações com várias equipes e vastas propriedades de nuvem. Mesmo que os engenheiros marquem cuidadosamente os recursos de nuvem para ajudar a identificar sua finalidade, nem sempre é óbvio apenas pelas tags se um recurso realmente precisa estar ativo.

● Necessidades imprevisíveis: nem sempre está claro quando um recurso de nuvem precisará ser reiniciado – o que pode se tornar um problema se você precisar colocar em funcionamento um recurso rapidamente, mas você o estacionou de uma maneira que torna impossível uma reinicialização rápida. Por esse motivo, as estratégias de cloud parking exigem insights não apenas sobre quando os recursos não são necessários, mas quando eles podem ser necessários novamente.

● Falta de automação: as ferramentas e procedimentos para desligar e reiniciar recursos de nuvem variam muito de um tipo de serviço de nuvem para outro. Como resultado, pode ser desafiador automatizar o processo, e os próprios fornecedores de nuvem oferecem poucas plataformas e integrações para ajudar.

● Dependências complexas: geralmente um tipo de recurso de nuvem (como uma instância de servidor) depende de outro (como um volume de armazenamento). Se você estacionar e reiniciar recursos interdependentes na ordem errada, você pode desestabilizá-los e dificultar o reinício deles posteriormente.

Em suma, embora o conceito de cloud parking seja fácil de entender, os desafios surgem na hora de projetar e executar uma estratégia cloud parking.

Práticas recomendadas para cloud parking

A complexidade do cloud parking não significa, no entanto, que a única maneira de estacionar recursos de forma eficaz é adotar uma abordagem manual e ad hoc.

Com as ferramentas e estratégias certas, você pode agilizar suas iniciativas de cloud parking de maneiras que otimizem o valor e, ao mesmo tempo, minimizem os riscos.

Para aproveitar ao máximo o cloud parking, considere essas estratégias.

Rastreie continuamente o uso de recursos

Novamente, estratégias como a marcação não são suficientes para identificar quais recursos de nuvem estacionar e prever quando reiniciá-los.

Em vez disso, as empresas devem rastrear de forma contínua e abrangente os recursos de nuvem que executam e, em seguida, analisar os dados de uso para detectar padrões que podem orientar o cloud parking.

Por exemplo, você pode notar, por meio do rastreamento abrangente de recursos, que uma instância específica do servidor em nuvem é executada apenas um dia por semana e que, portanto, deve ser estacionada no resto da semana.

Rótulos como “servidor de desenvolvimento” e “servidor de backup semanal” não necessariamente indicariam quando e com que frequência o servidor deveria ser executado, mas os dados de uso seriam.

Estabeleça prioridades de estacionamento e reinício

Como mencionei, muitas vezes alguns recursos de nuvem precisam iniciar e parar antes de outros.

Por exemplo, se você tiver uma aplicação que depende de um banco de dados, normalmente precisará ativar a instância do banco de dados antes que a aplicação possa operar. E você vai querer finalizar a aplicação antes de desligar o banco de dados, para não deixar o aplicação em um estado em que não possa ler e gravar dados.

Para acomodar necessidades como essas, defina níveis de prioridade para diferentes recursos de nuvem ao formular planos de cloud parking.

Quando estacionar e reiniciar, faça isso de forma que os recursos de alta prioridade sejam iniciados primeiro e desligados por último, evitando o risco de causar interrupções em recursos interdependentes.

Recursos de dados de cloud parking

Uma oportunidade que as organizações geralmente perdem ao estacionar recursos de nuvem é a redução dos custos de dados.

A maioria dos tipos de recursos de dados na nuvem, como bancos de dados e volumes de armazenamento, não pode ser desligada da mesma forma que os recursos de computação, de modo que as empresas acabam pagando por seus dados mesmo depois que os aplicativos que interagem com os dados não estão mais em execução.

Com um conjunto de ferramentas sofisticado que permite converter entre tipos de armazenamento de dados rapidamente, é possível minimizar esse custo. Por exemplo, imagine que você desligue uma instância do EC2 e queira parar de pagar pelo volume do EBS que a instância usa.

Você pode fazer isso fazendo snapshot do volume do EBS, movendo esses dados para o S3 (onde os preços de armazenamento geralmente são mais baixos do que no EBS) e, em seguida, restaurando os dados para um volume do EBS quando quiser iniciar o backup da instância do EC2.

Contanto que você mantenha os metadados intactos para garantir que o sistema operacional reconheça o volume restaurado do EBS, essa estratégia pode reduzir drasticamente o custo de armazenamento de dados durante períodos em que você não precisa deles.

Alinhe o cloud parking com as unidades de negócios

É provável que diferentes unidades de negócios e grupos tenham diferentes necessidades de estacionamento e reinício na nuvem.

Os desenvolvedores podem aceitar algum atraso no reinício de uma instância de servidor que eles usam para testar o código, por exemplo, mas um banco de dados que hospeda dados financeiros de missão crítica pode precisar ser reiniciado o mais rápido possível quando seu departamento de contabilidade precisar acessá-lo.

Por esse motivo, projete políticas de cloud parking que sejam granulares o suficiente para refletir as diferentes prioridades de diferentes grupos de negócios. Não deve haver uma abordagem única para o cloud parking.

Conclusão

É um fato simples: se você quer economizar dinheiro na nuvem, você precisa realizar o cloud parking de seus recursos de nuvem de forma eficaz e, embora a organização típica já invista algum esforço em identificar e desligar recursos de nuvem não utilizados, uma estratégia avançada de cloud parking deve ir muito além disso.

Você precisa saber exatamente o que estacionar e como e quando estacionar e reiniciar, e precisa estender sua estratégia de cloud parking a todos os tipos de recursos de nuvem suportados, não apenas instâncias de servidor e outros candidatos óbvios.