Com a aceleração digital das empresas, a necessidade por infraestruturas de TI maiores e mais flexíveis provocou uma corrida para a cloud. Para muitas companhias, contudo, o processamento de dados na nuvem não foi a solução de melhor aderência, gerando um oneroso processo de retorno do trabalho ao data center on premise.
Entender sobre as causas deste movimento de pivotagem e gerenciar o risco desta manobra na tomada de decisão rumo à nuvem é o assunto deste episódio do podcast greenTALKS: Como evitar a repatriação de workloads, com o Arquiteto de Soluções da green4T, Gustavo de Biasi.
Acompanhe a seguir a transcrição da entrevista dada ao jornalista Fabiano Mazzei para o podcast:
Fabiano Mazzei – Olá, seja muito bem-vindo, seja muito bem-vinda a mais um episódio do podcast greenTALKS. Lembro que você pode encontrar este conteúdo aqui no Spotify, no YouTube, em nosso blog Insights e também em todas as nossas mídias sociais.
O tema hoje é “Como evitar a repatriação de workloads”: quais são os casos mais frequentes e as dificuldades que as empresas encontram para acabar adotando essa estratégia. A importância do planejamento correto e da análise do workload antes da migração. E como evitar esse risco? Para falar sobre o assunto, nós convidamos Gustavo de Biasi, que é Arquiteto de Soluções da Green 4T, que volta aqui para o podcast na sua segunda participação. Gustavo, muito obrigado por aceitar o convite. Seja bem-vindo de volta o greenTalks.
Gustavo de Biasi – Valeu, Fabiano. Obrigado! Tudo bom?
Fabiano – Tudo certo. Vamos conversar sobre esse assunto que é bastante importante no mercado. Eu queria começar perguntando a você quais são os casos mais frequentes e que tipo de dificuldade as empresas podem encontrar que as levam a tomar essa decisão de retorno de repatriação de workload?
Gustavo – Bom, primeiramente a repatriação do workload – da cloud para dentro de infraestruturas on premise ou dentro de data center – é algo que começou a acontecer a partir do momento que algumas empresas sentiram dificuldade em manter esses workloads dentro da nuvem, exatamente por não entenderem ou não compreenderem corretamente a jornada para a cloud.
Algumas vezes, foi por conta de uma tendência do momento ou por conta de alguma aplicação que demandava soluções específicas e decidiu-se migrar os seus workloads do datacenter para dentro da cloud. E isso é algo que tem crescido. Não era tão visível, até mesmo com grandes analistas de futurologia: olhando para esse tipo de coisa, muitas empresas não imaginavam que isso ia acontecer. Mas isso aconteceu.
São alguns motivos que foram aparecendo e se mostrando cada vez mais explícitos, fazendo com que as empresas voltassem a olhar para dentro do seu data center, do seu ambiente on promise, e compreendesse que faria sentido voltar (com o processamento de dados) para “dentro de casa”. Isso, como eu disse, é algo que veio por conta de uma… não vou falar de uma falha na estratégia, mas, talvez, de alguns pontos que não foram observados.
A partir do momento que você está desenhando um modelo futuro de ambiente, isso pode levar a ter custos que se tornam mais elevados exatamente por conta de não compreender a utilização desses recursos que estavam dentro de casa na hora que você leva para uma cloud pública, por exemplo.
Tem também a parte da segurança, o modelo de segurança dentro da cloud. Ele é um pouquinho diferente do modelo de segurança de dentro de um ambiente on premise e, por conta disso, as ferramentas que são utilizadas e os processos têm que ser alterados. E isso não muda única e exclusivamente no ferramental: é necessário olhar para a parte regulatória para, a partir de relatórios de acompanhamento, você conseguir manter essa segurança.
Então, vai criando uma certa complexidade e isso é algo que leva o pessoal a reavaliar alguns pontos e voltar para dentro do data center. Existe uma preocupação muito grande também em relação ao vendor location, que na verdade nada mais é do que você estar preso a uma determinada tecnologia, mesmo quando a gente fala de infraestrutura como serviço.
Mas se nós percebermos, existem diferentes formas de manter os seus recursos e levar a produção para frente. Então, o tipo de rede, o tipo de aplicações, de balizadores, de cargas, tudo isso, por conta de algumas das regras serem as mesmas. Mas as APIs mais a forma de você aplicar essas regras serem diferentes, isso vai demandar mais conhecimento, vai ter essas especificidades que vão quase que te obrigar a se manter em determinado hyperscaler. Então, por conta disso tudo, na hora que você olha para para todos esses pontos e analisa a forma como você faria e como você, como você poderia fazer isso olhando pelo seu prisma de uma TI clássica que estava dentro do seu on premise, você vê que faz bastante sentido para determinados ambientes e levá-los de volta para casa. Não todos os ambientes, mas alguns ambientes, sim.
Fabiano – Muito bom. Vamos entender como as empresas podem evitar esse risco de repatriação?
Gustavo – Para evitar a repatriação, é necessário você compreender muito bem a sua jornada para cloud. Quando a gente fala que é o cloud, não é uma simples migração para a cloud: simplesmente pegar o seu hardware com os seus workloads e colocá-los de forma única, como uma máquina virtual que estava dentro de um ambiente em uma cloud privada. Você precisa compreender e entender os recursos que ela demanda, qual seria a melhor aplicação disso e o que é necessário para você tocar sua produção, para você fazer as operações do dia a dia, para você manter o ambiente.
Então, existe uma estratégia de jornada para cloud. Você tem que saber que tem que ser o que tem que ser observado. Dentro dessa jornada, a gente tem a identificação e o preparo primeiro da empresa como um todo, com o time de TI integrado com as preocupações das soluções da empresa. Ou seja, ela faz parte do core da empresa, fica muito mais simples de você identificar o fluxo de informações e desenvolver melhor uma estratégia para cloud.
Então, quando você precisa de uma inovação e ela vai ser colocada dentro do seu ambiente de TI, ela tem que estar amarrada e ter uma mensagem única para toda a empresa. Essa estratégia é fundamental: você entender a origem e a aplicação desses workloads dentro da cloud é importante. Alguns workloads, alguns itens de produção que são mais sensíveis à latência ou, então, que demandam uma quantidade maior de informação que você vai fazer o download, a utilização desses recursos quando você tem uma quantidade muito grande de informação que você vai ter que processar dentro de casa – e administrativamente falando –, começa a ficar muito caro para estar em cloud.
Se você tem, por exemplo, problemas com conectividade ou mesmo limitações por conta de latência, você pode estar em perigo colocando uma determinada execução ou sistema dentro da cloud. Então, observar isso tudo é entender suas características e entender que cada workload tem uma aplicabilidade e, a partir disso, desenvolver uma boa estratégia.
E, obviamente, realizar isso em passos, onde você possa validar a sua infraestrutura, sua operação, para que você consiga instalar o seu ambiente, posicionar o seu core dentro de uma cloud da melhor forma possível e, obviamente, utilizando isso de uma forma inteligente, de uma forma onde você não vai ter problemas com custo ou coisas do gênero.
Fabiano – Perfeito. Qual a solução para uma empresa que necessita da cloud, mas também deve manter parte dos dados on premise. Seria a cloud híbrida? O que você recomenda?
Gustavo – Sim, a cloud híbrida hoje ela faz. Na verdade, há algum tempo a gente fala de cloud e a partir do momento que você coloca algum ver cloud dentro de uma nuvem pública. Mas eles estão ainda interligados de alguma forma, com recursos que estão dentro de seu data center ou dentro do ambiente e você tem de orquestrar isso tudo. E a cloud híbrida é onde ela toma forma.
Então, para ter a cloud híbrida funcionando bem é básico que você tenha um conhecimento muito grande dos seus workloads. Como eu disse, entenda suas necessidades. Eu acredito também que quando a gente olha para esses ambientes onde você tem uma solução pronta e nativa para cloud, ela já tem os seus recursos todos lá e você não vai utilizar apenas uma infraestrutura como serviço, mas o recurso pronto e já gerido, orquestrado, você tem uma boa aplicação de cloud, de workload. Ferramentas de orquestração, que conseguem abstrair o máximo da complexidade da cloud e do on premise para um modelo único de gestão, auxiliam bastante na operação e isso obviamente diminui os custos envolvidos, a complexidade da manutenção dos itens de produção. E isso auxilia bastante.
Tudo isso faz parte de um desenho, de uma estratégia que é tomada e gerida não apenas pelo time de TI, mas também pelo cerne da empresa, pelo desenvolvimento do produto, dos processos da empresa para que você consiga obter isso daí. Mas, é claro, a partir do momento que a gente olha para uma análise de modelo de maturidade de TI, que isso faz parte do estudo dessa estratégia, a gente consegue identificar onde a gente tem que reforçar o time e o que a gente precisa aprender para poder ter uma jornada exitosa para cloud, sem o medo de ter que repatriar isso depois. Porque o custo de levar pode ser alto, mas o custo de trazer de volta… Você já teve toda a oneração de levar (para cloud), para depois precisar gastar um pouquinho mais para trazer de volta. Então, isso é importante. Estratégia é tudo.
Fabiano – Deu para entender a vantagem financeira embutida nesse processo e o ganho de eficiência. Podemos conectar neste tema a questão da sustentabilidade?
Gustavo – Podemos sim. Principalmente com o seguinte: quando a gente está falando de cloud, a gente sabe que o nosso ambiente vai estar dentro de um data center que consumirá recursos que, algumas vezes, serão compartilhados ou não. E o hyperscaler estará cuidando disso tudo. É importante a gente ter em mente que todos nós somos responsáveis pelo nosso uso sustentável destes recursos. Quando a gente está dentro do nosso datacenter – e é algo que a gente dentro da green4T tem isso muito forte, como o uso do DCIM, aonde eu consigo acompanhar todos os itens de dentro de um datacenter, como a parte de temperatura, clima, todos os itens de configuração que estão compondo a nossa solução, a gente consegue trabalhar de forma a extrair o máximo disso de uma forma mais “verde”, digamos assim. A gente consegue melhorar o uso desses recursos. Quando a gente olha para a cloud, e eu acho que que é superimportante fazer o que algumas empresas estão fazendo de solicitar aos hyperscalers as informações em relação a sua pegada de carbono. A gente consegue fazer isso hoje dentro da green4T, porque nós temos o DCIM e temos como acompanhar essas métricas dentro do portal.
Porém, quando a gente está falando de um hiperscalers, a gente não tem as mesmas informações. Mas é interessante a gente observar isso tudo para a hora que tiver de desenvolver algum plano ou mesmo a campanha de modo mais sustentável, compreendendo que tudo isso está ligado. E o setor de TI, obviamente, por ser um dos grandes consumidores de energia, e por conta das questões do clima, não fica de fora.
Fabiano – Bom, eu acho que deu para esclarecer um pouco sobre esse importante tema. Eu gostaria de agradecer ao Gustavo de Biasi, que é Arquiteto de Soluções da green4T, sobre “Como evitar a repatriação de workloads”. Gustavo, mais uma vez obrigado pela sua presença por compartilhar os seus conhecimentos aqui no greenTALKS.
Gustavo – Eu que agradeço, valeu mesmo!
Fabiano – Então é isso, se você gostou desse conteúdo, por favor, curta e compartilhe em suas redes sociais e também veja outros conteúdos relevantes sobre tecnologia que postamos no nosso blog, em sites, no YouTube e em nossas mídias sociais, além aqui, é claro, do Spotify. Muito obrigado a todos por ficarem co
