Estratégias de Arquiteturas e Migração para Cloud: como escolher a certa?

Estamos em 2020 e já considero um assunto batido que precisamos usar cloud computing. Não porque seja um “hype” de tecnologia, mas sim pelos serviços ofertados e pela capacidade de responder sob demanda. Um exemplo claro disso é a quantidade de POCs (provas de conceito) que podemos fazer antes de implementar em produção de larga escala uma nova oferta tecnológica, pagando sob demanda.

No contexto tecnológico, sabemos que o ambiente cloud é o que provê a melhor capacidade de recursos e escalabilidade. Mas como que defendemos a implementação no contexto financeiro?

E quando temos equipes que já utilizam recursos cloud, por exemplo, a de marketing usa o Adsense (e por consequência, a GCP), o time de inteligência utiliza o PowerBI (e por consequência, a Azure) e o time de tecnologia utiliza o S3 para backups (logo, usa a AWS). E ainda temos o ambiente local, normalmente com o ERP da empresa e outros diversos sistemas que estão há anos instalados e que sabemos que será uma dor de cabeça para migrar. Fora que, em muitos casos, faz pouco tempo que foi investido um alto valor na compra de novos servidores, logo, como justificar uma migração para a cloud para o CFO da organização? São estas as questões que pretendo ajudar a elucidar neste artigo. Espero que seja de bom proveito para você.

Estratégias de Migração para um Ambiente Cloud

Quando estamos pensando em migrar para um ambiente cloud, gosto de pensar em três modelos de trabalho: lift and shift; sob demanda; e de-para. Segue abaixo uma descrição a respeito de cada um desses modelos.

Lift and Shift

· O que é: esse modelo de migração tende a ser o mais simples de ser utilizado, onde nada mais é que pegarmos as configurações do nosso parque tecnológico e migrar para o cloud provider com a mesma configuração, afinal, a cloud também é um datacenter em outro lugar.

· Como funciona: quando está vencendo a licença de suporte aos hardwares e aplicações, este é um dos poucos momentos que recomendo a utilização desse método, pois, normalmente ele é o que traz menos valor para a organização e é o método que fará você pagar mais dentro do cloud provider. Vamos a casos práticos de funcionamento desse método. Nosso contrato de suporte dos nossos servidores estará vencendo em 4 meses e para renovar, o valor está além do orçamento anual que a TI possui. O CFO da organização não permitiu um aditivo por questões econômicas, assim, buscando uma alternativa, viu-se que um cloud provider provê a manutenção do hardware e garante todos os SLAs necessários para a organização. Logo, como há pouco tempo para a migração, escolhe-se o provedor que possui o preço mais atrativo e verifica-se questões de suporte e evoluções tecnológicas. Para migrar, “apenas” são levantados os servidores que se fazem necessários na cloud, são tiradas as imagens das máquinas atuais e instanciadas no cloud provider, fazem-se os testes e documentam-se os ajustes que se fazem necessários. Após esse processo, agenda(m)-se a(s) data(s) de migração da infraestrutura.

· Principais Vantagens: a maior vantagem é a agilidade do processo, e em momentos críticos, faz muito sentido essa migração. Também há a vantagem que é o início de uso da cloud, onde se pode elaborar um plano de evolução tecnológica de uso dos serviços do provedor e otimização dos custos.

· Principais Desvantagens: começaremos pagando um valor mais alto nessa abordagem, uma vez que não utilizaremos os serviços do provedor. Um exemplo disso, pode ser o Data Warehouse da empresa, onde sai mais caro ter servidores que a utilização do DW do provedor, seja ele o Redshift da AWS, o BigQuery da GCP ou o Sinapses Analytics da Azure.

Migração Sob demanda

· O que é: o time da área precisa construir uma nova solução ou executar uma melhoria, seja ela em produto ou interna, já se desenvolve essa tarefa usando os recursos do cloud provider.

· Como funciona: normalmente é uma estratégia muito utilizada em equipes de desenvolvimento de produto, onde faz-se o desenvolvimento sob a demanda do produto, utilizando os serviços que o cloud provider entrega. Vamos à um case prático para exemplificar: você é do time de infraestrutura e o time de desenvolvimento necessita de um novo servidor para testes, na nossa infra local já temos um ambiente limitado e há poucos recursos disponíveis para uma nova VM, assim, levantamos o servidor no cloud provider. Criamos o agendamento para que ele fique ligado apenas quando a equipe estará trabalhando, pagando um custo bem menor, uma vez que estamos respondendo sob demanda. Finalizados os testes, o time de desenvolvimento quer colocar a aplicação online, podemos colocar essa aplicação diretamente no cloud provider e para acessá-la com fluidez, pode-se colocar uma solução de rotas ou de gateway de APIs para apontar para a nova aplicação.

· Principais Vantagens: nos casos mais comuns, há uma economia grande financeira. O processo de migração para a cloud é menos custoso e menos estressante para os times e, consequentemente, para a empresa. É a estratégia mais simples de testar uma migração e traz o menor risco para o negócio.

· Principais Desvantagens: é muito comum ser o processo mais lento para a migração, pois vai depender do roadmap dos produtos e dos times. Existe uma taxa de dataout que temos que começar a cuidar no billing. Se não for bem gerenciado e documentado, há facilidade imensa dos ambientes se tornarem uma “concha de retalhos e puxadinhos”, aumentando a complexidade tecnológica.

Migração de-para

· O que é: utilizar os serviços do cloud provider referente à necessidade da aplicação, não precisando subir instâncias para servidores e realizar toda instalação e configuração da aplicação.

· Como funciona: esse tipo de implementação é mais comum quando trabalhamos em ambientes e times que não possuem muito tempo para se dedicarem a monitoria e operação, e sim, são focados em desenvolvimento do produto. Este formato de migração é para migrar, por exemplo, o servidor Kubernetes para a opção serverless do cloud provider: EKS na AWS, GKE na GCP ou AKS na Azure. Neste modelo, o time trabalhará na migração de uma solução para uma de plataforma onde ela já possui todas as interfaces de configuração e é responsável pela manutenção, monitoramento e operação da solução.

· Principais Vantagens: principalmente, diminuição de responsabilidades e facilidade para escalar uma solução.

· Principais Desvantagens: principalmente, lock in com a cloud e curva de aprendizado para a implementação em uma nova tecnologia.

Até esse momento, apresentei os três principais modelos de migração para um cloud provider, mas qual é o certo a ser adotado? Normalmente, a resposta é a mescla entre esses modelos, dependendo do contexto em que estamos trabalhando. Uma equipe responsável por um produto, poderá optar por manter a solução em um servidor dentro da cloud, fazendo apenas um “lift and shift”. Outra equipe, pode pensar em fazer uma migração gradual da solução, variando pelo roadmap e por fim, uma outra equipe, para deixar o desenvolvimento mais ágil, pode pensar em reescrever seu produto e migrar para os produtos da cloud. Assim, nesse momento, entramos no próximo tópico que precisamos discutir, que são as Arquiteturas Cloud.

Arquiteturas Cloud

Assim como as estratégias de migração para o cloud provider, também classifico em três grandes grupos as estratégias de arquiteturas cloud. A seguir apresento-as e vamos discutir elas.

Lock in Cloud

· O que é: ambiente 100% dentro de um cloud provider específico.

· Como funciona: esse modelo é muito comum em startups, onde há um investidor e a necessidade de retorno o mais rápido possível, fora que não existem grandes data centers vinculados a organização. Assim, pagando sob demanda, utiliza-se os produtos serverless que o provider possui em seu catálogo, para agilizar o processo de desenvolvimento e baratear os custos.

· Principais Vantagens: velocidade no desenvolvimento e apenas uma cloud para gerenciar o billing e infra.

· Principais Desvantagens: no âmbito técnico, é o melhor dos mundos, pois facilita a gestão por parte da infra e também facilita o desenvolvimento. Limitar nem sempre é pejorativo. Porém, quando falamos na visão de negócio, podem haver problemas: imagine se para fechar um contrato com uma prospecção, os dados só não podem estar na AWS porque a Amazon é concorrente de sua prospecção em outro ramo? O mesmo vale para Azure, GCP e as outras clouds. Você também fica “refém” do provider e das suas soluções.

Ambientes Híbridos

· O que é: temos ambientes em data centers locais e utilizamos um cloud provider.

· Como funciona: é o ambiente mais comum de encontrarmos nas empresas, pois normalmente as empresas já possuem uma infraestrutura física ou um ambiente de data center contratado em terceiros, e necessitam adicionar um ambiente cloud em sua infra, seja para a utilização de um produto ou estratégia de mercado. Normalmente os responsáveis pela infraestrutura constroem túneis de VPN entre os data centers da cloud e os locais para manter um ambiente seguro e restrito.

· Principais Vantagens: começa-se a agregar o valor que uma cloud tem dentro da organização e não se “mata” o que já foi desenvolvido até então.

· Principais Desvantagens: administrar mais de um ambiente pode se tornar um pouco complexo assim como o tráfego de dados entre eles, fazendo-se necessário criar regras de monitoramento.

Ambientes MultiCloud

· O que é: ambientes que podem conter mais de um cloud provider e infraestruturas locais.

· Como funciona: muitas vezes as melhores soluções para a sua necessidade estão em mais de um fornecedor e isso acontece também com a cloud. Já presenciei ambientes em que o time de marketing e growth necessitava das ferramentas do Google (GCP) para as campanhas. Em outro, o time de negócios e inteligência utilizava o PowerBI e componentes da Azure para entender o produto e saber o que fazer na análise de mercado. A equipe de ciência de dados utilizava tanto AWS, quanto GCP e Azure para suas análises e hipóteses. Fora que a empresa possuía data centers legados na sua infra.

· Principais Vantagens: um maior leque de opções, podendo a empresa utilizar o fornecedor que melhor lhe provê soluções para a sua necessidade.

· Principais Desvantagens: alta complexidade no gerenciamento tanto de infra quanto financeiro; complexidade de desenvolvimento também, pois estaremos lidando com diferentes latências e data outs; e necessidade de profissionais em todas as clouds e ambientes locais.

Agora que conhecemos os formatos de arquiteturas e os modelos de migrações, podemos ter certeza de que não existe um melhor modelo, e sim, aquele que melhor se encaixa para o seu contexto.

Todos os modelos possuem vantagens e desvantagens a adotá-lo. Já ouvi me dizerem que o melhor seria uma arquitetura multicloud usando uma migração sob demanda, porém, há a necessidade de um item a ser analisado: o data out, que se refere ao “download” dos dados do cloud provider. Se o seu ambiente de análise de dados estiver em um local e o seu data lake estiver em outro, o seu data out será imenso. Trouxe esse exemplo porque não é apenas o técnico que importa quando estamos trabalhando em arquiteturas e migrações, o fator financeiro, por mais que muitas pessoas técnicas e entusiastas não gostem, importa e tem um peso muito forte na tomada de decisão. Assim, no próximo tópico, quero apresentar os dois pilares que os administradores de ambiente precisam levar em conta na tomada de decisão: payback e billing.

Controle Financeiro

Payback

O payback é uma das técnicas mais antigas nas corporações para justificar o investimento e ela é realmente muito útil para quem é o responsável pelo ambiente cloud, uma vez que o pagamento é feito conforme a demanda. Assim, pensamos que estamos sempre investindo ao subir um novo servidor ou utilizar um novo serviço. Dessa maneira, quando temos ambientes híbridos ou multiclouds, vale sempre a pena realizarmos esse exercício de payback sobre o novo serviço para garantirmos financeiramente também a escolha tecnológica.

Billing

Por fim, o controle do billing é uma das atividades essenciais na vida de quem está migrando para a cloud ou implementando uma nova estratégia. E também uma atividade base no seu dia-a-dia. Todos os cloud providers oferecem formatos de gestão do billing da conta e formas de implementação de alertas de gastos e limitações. Use-as dentro da sua conta para fazer uma gestão efetiva e pró-ativa, para que não haja surpresas na hora de pagar a conta.

Conclusão

Reconheço que a explicação de todos os itens foi superficial, porém, a ideia foi de apresentar os três pilares para a implementação de seu ambiente e/ou migração para a cloud. Quando você consegue escolher o formato de ambiente, alinhado com a estratégia e seu controle financeiro, dificultará surpresas na execução do planejado, aumentando a chance de sucesso para o projeto em questão. Esses três pilares devem estar muito bem descritos, assim, para você, pessoa técnica, negociar com a área financeira, facilitará muito o seu mundo.

Espero ter ajudado ou ao menos ter lhe fornecido um norteador nesse ponto. Sinta-se à vontade para comentários e sugestões, terei o maior prazer em discuti-los. 🙂