Modelo híbrido pode ser o mais indicado para as necessidades das organizações. Mas esse quebra-cabeça deve ser montado com atenção
Estávamos no final de 2010. A economia ia bem e o consumo a todo vapor. Foi quando um consultor amigo me indicou um cliente em apuros. Era um grande varejista que havia sofrido uma pane e estava com os sistemas de TI parados.
O veredicto anterior era trágico: o ambiente estava condenado, ou seja, o dano era tão grave que não havia recuperação. A solução seria refazer do zero. O prejuízo era assustador.
Naquela época, minha empresa, que sempre atuou na venda de hardware, estava virando a chave para se tornar uma empresa de outsourcing em serviços de TI em decorrência da crise de 2008.
Aquele desafio era a oportunidade de mostrarmos que estávamos prontos para consolidar esta nova frente de negócio. Montamos um esquema 24X7 durante duas semanas.
O esforço foi recompensado. Identificamos a origem do crash e conseguimos recuperar 95% do sistema “condenado”. Em seguida, fizemos as orientações necessárias para mudança da arquitetura e da distribuição dos sistemas.
Por termos evitado o naufrágio, ganhamos o contrato. Naquela época, o Roldão Atacadista, o cliente em questão, era uma rede pequena com nove lojas. Uma década depois, são 34 pontos de venda.
A ação emergencial que fizemos se chama, no linguajar de TI, Recuperação de Desastre, um conjunto de políticas e procedimentos para viabilizar a recuperação ou continuação da infraestrutura de tecnologia e sistemas vitais.
Quanto mais o tempo passa e a transformação digital se intensifica em todos os setores e tipos de negócio, a infraestrutura de TI se torna imprescindível para a maior parte das operações de uma empresa. Por isso, apesar dos custos envolvidos em montar uma estrutura compatível com as exigências do negócio, não é uma medida sensata não ter uma estratégia na hora da crise.
Um plano de recuperação de desastre normalmente é composto por três fases. A primeira é a Administração da Crise, seguido pelo Plano de Continuidade Operacional com as diretivas do que fazer em cada operação na ocorrência de um desastre e, por fim, a Aplicação Prática, se necessário.
A prioridade deve ser sempre reduzir ao mínimo o tempo de suspensão das operações, garantindo alguma estabilidade, e depois possibilitar uma recuperação organizada. O objetivo é restabelecer todas as aplicações e bancos de dados depois da ocorrência de alguma falha.
Os eventos podem ser desde uma escala reduzida, como um programa de computador que está falhando devido a um vírus, e chegar até uma calamidade, como a parada total do sistema, um ataque de hackers ou o roubo de dados confidenciais, situações para acionar o botão de pânico.
Vamos por partes. É natural subdimensionar o risco de um desastre. Não compramos um carro pensando em capotar. Mas todo mundo quer estar seguro que, no caso de um capotamento, seu carro protegerá a integridade dos ocupantes.
Ao longo dos meus anos de experiência, cheguei em muitos clientes que tinham duas pessoas revezando no “CPD” – lembra dessa sigla?! – para cuidar de três PCs, um fazendo as vezes de servidor/backup, outro para armazenamento de bancos e um terceiro para gerenciar o acesso internet.
Obviamente não dá pra imaginar que uma estrutura dessas conseguisse migrar de uma vez para um super ERP. Seria como ter um carro popular e tentar trocar por um Volvo topo de linha (a marca sueca é famosa por privilegiar a segurança dos passageiros).
Com o crescimento dos serviços em nuvem houve primeiro uma resistência em não ter toda a infraestrutura on premises, ainda que a terceirização da administração de TI seja uma tentação para a área de custos.
Na medida em que o conceito de SaaS se popularizou, parece que, de repente, tudo precisa ir para a nuvem. Até a hora em que a conta chega e a empresa percebe que nem sempre compensa do ponto de vista financeiro ou de performance.
Isso quer dizer que cloud é ruim ou sempre mais caro? Não!
A meu ver, o mais indicado é criar uma infraestrutura híbrida que tenha uma parte do sistema on premises – seja num data center físico contratado ou dentro da empresa – e outra parte alocada na nuvem. E esse quebra-cabeça deve ser montado com atenção.
Uma das considerações a ser feita é que levar algum processo para nuvem implica ficar sujeito à disponibilidade de link ou conexão de internet, eventualmente com algum downtime e latência. O próprio Roldão tem sistemas que rodam em máquinas IBM robustas, com muita troca de dados. Se levarmos uma parte disso à nuvem, certamente haverá delay nesses processos.
Então é preciso preservar algumas operações locais e criar as APIs necessárias para permitir uma comunicação eficiente com o que for para nuvem.
E-mail, alguma aplicação pontual, especialmente as móveis (porque esses sistemas nasceram na nuvem), e apps com pouco processamento são bons exemplos.
E-commerce precisa ficar em casa? Não! Mas o sistema voltado para a frente dos caixas é importante. Imagina você causar fila no balcão da loja física porque algum sistema na nuvem está com latência?
Por isso, é importante haver um cloud broker para gerenciar o uso, desempenho e entrega de serviços em nuvem, além de negociar as relações entre os provedores e consumidores (a empresa, no caso).
Mesmo que o faturamento dos serviços de nuvem não seja mais em dólar como antes, o broker vai certamente encontrar o melhor custo-benefício com fornecedores para cada tipo de serviço e evitar que o ambiente na nuvem fique desnecessariamente muito grande ou tenha sua performance prejudicada.
Obviamente, a chegada do 5G, com uma velocidade muito superior à da banda larga comum, tende a modificar essa equação, já que várias considerações, como latência, por exemplo, deixam de fazer sentido. Só que até a rede 5G estar totalmente implantada e com capilaridade no país vamos percorrer um horizonte de cinco a dez anos. Basta lembrar que o Brasil ainda não fez um leilão de frequências que vão operar o 5G.
As empresas não estão erradas em considerar a nuvem. O modelo ainda tem muito espaço para crescer e se desenvolver. Portanto, nada errado em voltar os olhos “para o céu”. Mas sem tirar os pés do chão.
*Constantino Iliadis é fundador e VP da Think, empresa especialista em outsourcing de infraestrutura de TI
