• Por Guilherme Sesterheim*

 

Muito se discutiu, e ainda se discute, sobre a jornada para nuvem. As grandes empresas do mundo já possuem suas estratégias voltadas para a nuvem desde quando as aplicações são idealizadas. Potenciais de segurança, escalabilidade, autonomia e outros assuntos relacionados já não são mais abordados na hora de discutir projetos. A nuvem já não gera mais dúvidas ou desconfianças há algum tempo. Uma vez que a ida para cloud já é assunto vencido, além dos pontos de atenção já levantados, trago alguns erros que presenciei serem cometidos, como forma de apoiar estratégias de movimentação ou outras:

 

Encarar nuvem como suporte

A nuvem é protagonista nas aplicações. É muito comum que empresas comecem suas jornadas com rotinas simples de backup ou storage na nuvem para desonerarem seus datacenters próprios. Isto é um passo importante, muitas vezes necessário para passar segurança a um board cético sobre a mudança. Porém as rotinas de rollback, backup, disaster recovery, e outras muito complexas para os times de OPS já são triviais para os grandes players de nuvem. Usá-las com este fim é como subestimar o potencial da nuvem.

Serviços auto-gerenciados possuem nível de automação dos aspectos mencionados acima altíssimo. O time de operações se beneficia de automações de processos que antigamente lhe consumia enorme tempo e dinheiro em planejamento e execução de projetos. Os serviços que não são auto-gerenciados também possuem muita automação embarcada. Backup, rollback e DR são básicos.

 

Negligência ao executar a matriz de decisão

A opção por um ou outro cloud provider é algo de importância muitas vezes subestimada. Escolher um provedor de nuvem é um casamento que pode trazer relações conturbadas! Tenho visto empresas querendo fugir de seus contratos traumáticos de 10 ou 20 anos com players gigantes como Oracle ou IBM, negligenciando matrizes de decisão de cloud, e assinando outros contratos que os levarão a mais 10 ou 20 anos com X ou Y provider.

Grandes players como Google, SAP, Azure, IBM e SAP permitem um nível de customização altíssimo, que deve ser avaliado na decisão. Estas permitirão configurar todos os aspectos necessários a uma grande aplicação que possua dependências, integrações, relações com outros sistemas e que exigirão práticas customizadas de engenharia. É muito comum também que aplicações complexas possam agregar benefícios de operações em multi-cloud.  Por exemplo: infraestruturas que possuam custo mais atrativo no provider X podem se beneficiar de recursos FaaS de Bigdata do provider Y que é mais veloz ao tratar grandes volumes de dados. Desta forma uma única aplicação pode estar distribuída em mais de um provedor de nuvem, também em mais de uma região geográfica, viabilizando objetivos de negócio como economia, redução de delay e acesso a features exclusivas de players de nicho.

Em paralelo aos grande players, há diversos provedores de nicho de PaaS, FaaS. Digital Ocean, Heroku, Umbler e Elastichosts, por exemplo, são úteis para aplicações que não precisam de tanta robustez. O nível de abstração destas plataformas é altíssimo, o que permite uma curva de aprendizado do time de desenvolvimento e/ou operações muito pequena.

 

Desconhecer o potencial da nuvem escolhida

A economia que pode ser atingida aproveitando recursos da nuvem, como rollback, DR, backup (citados acima), monitoramento, alertas e ações automatizadas, é altíssima e deve entrar na conta das organizações ao conduzirem seus projetos de migração.

Serviços de PaaS para executar aplicações, ou FaaS para automação de tarefas de redes, Machine Learning, deploy, testes, e outros precisam ser avaliados. Como exemplo cito que toda empresa que possuía software sendo executado em infraestrutura on premise, acabou em algum momento desenvolvendo softwares para amadurecer suas práticas de testes ou deploy. Isto significa que, caso 10 empresas tivessem desenvolvido softwares similares, ao custo de 500h cada, teríamos 5000h duplicadas sendo investidas. Com serviços como CodeDeploy, Device Farm, Fastlane e Firebase, este tipo de desenvolvimento não é mais necessário. Com contratações rápidas, muitas horas de desenvolvimento são economizadas, dando velocidade às empresas, e significando que conseguirão responder às necessidades de seus clientes mais rapidamente.

 

Falta de rastreio sobre o investimento

Ainda é comum que o orçamento para cloud seja uma caixa preta. O rastreamento detalhado deste investimento deve ser mantido por pessoas capazes e ser separado por aplicação/negócio/o que fizer sentido naquela realidade. Desta forma decisões assertivas poderão ser tomadas, como a contratação ou descontinuação de determinado serviço contratado. Isto é mais uma prática que evita que o “casamento” com o cloud provider possa se assemelhar aos contratos de muitos anos com Oracle, IBM e etc, dos quais toda grande empresa tenta fugir hoje. Já cometemos erros no passado. Vamos aprender com eles!

 

Falta de atualização do time responsável

Como exemplo, ainda é comum empresas investirem grandes quantias de dinheiro comprando muitos diferentes aparelhos móveis para testar seus aplicativos. O desconhecimento dos serviços que permitem testes automatizados nestes dispositivos fará com que este dinheiro continue sendo desperdiçado e benefícios da automação disponível não cheguem até o processo de desenvolvimento.

Com cada vez mais competidores qualificados de nicho surgindo, a falta de atualização pode ser um grande problema. Desconhecer boas alternativas a serviços já existentes e consumidos pelas empresas, fará com que elas nunca sejam descobertas e seus benefícios não sejam utilizados.

 

* Guilherme é líder de área de desenvolvimento de software na ilegra. Possui experiência em tecnologias Google Cloud, linguagens de programação de código aberto, métodos de gerenciamento de projetos e conhecedor de mindset Lean para melhorar processos internos e para as necessidades de clientes. Concluiu o mestrado na Unisinos em 2013, e atualmente frequenta o curso de MBA em gestão de projetos pela Fundação Getúlio Vargas.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

CAPTCHA
Change the CAPTCHA codeSpeak the CAPTCHA code