O desafio da nuvem híbrida, um novo modelo de empresa, solução da RIVERBED

Por meio de inovadoras técnicas e algoritmos os cientistas da Riverbed criaram
soluções engenhosas que faziam aproveitar muito mais o nobre (e caro) recurso
das conexões dedicadas. Compressão, deduplicação, envio seletivo, transmissão
incremental, etc. Tudo isso era capaz de viabilizar operações remotas usando os
limitados recursos de comunicação. O mercado se beneficiou muito disso e a
Riverbed aprimorou sobremaneira sua expertise nessa sensível área do conhecimento.

Porém o mundo mudou. E como mudou. A oferta de serviços em nuvem apareceu
sedutora como o canto da sereia e pretendia arrastar milhões de usuários para
este novo paradigma de empresa, ou seja, totalmente conectada. Mas a sabedoria
do mercado é soberana. Desconfianças em relação à segurança, disponibilidade de
comunicação e homogeneidade de tempo de resposta fizeram com que a adoção
massiva de nuvens públicas ocorresse de maneira mais comedida e gradual do que
os provedores deste serviço imaginaram .

É muito vasta a oferta de serviços na nuvem. Desde a hospedagem de sistemas de
correio eletrônico corporativo, servidores para diversas aplicações na
modalidade “on-demand” (com a incrível promessa de elasticidade virtualmente
infinita na medida da necessidade), bem como um sem número de aplicações vendidas
como serviço (alugadas pelo período contratual), todas residindo em algum lugar
da Internet. A disponibilidade dessas soluções abriu novas perspectivas e
vastas alternativas para modelar a TI das empresas na cabeça dos CIOs que
estivessem dispostos a pensar sob a ótica de um novo paradigma tecnológico, mas
mais do que isso, de novos e habilitadores modelos de negócios.

As tradicionais WANs das empresas foram mais desenvolvidas e renomeadas neste
novo contexto e passaram a viabilizar nuvens privadas que se opõem às nuvens
públicas. Entenda como nuvem pública tanto a oferta de software como serviço
(SaaS) bem como o uso de recursos sob demanda (servidores) ou mesmo o uso da
Internet como meio de interligação entre seus pontos remotos (não mais por meio
de redes privadas MPLS). Este novo cenário trouxe desafios imensos aos
responsáveis por TI, pois o ambiente da Internet não tem o mesmo nível de
resposta, uniformidade, latência do que uma rede privada MPLS. Mas por outro
lado é bem mais barata.

Posturas radicais como “tudo na rede privada” ou “tudo na nuvem” não tem vez
neste novo mundo.   Por isso o termo “nuvem híbrida” ou mesmo
“empresa híbrida” ganha lugar. Atualmente é muito mais sábio escolher o tipo de
serviço que estará em cada um destes dois mundos, seja por critérios
econômicos, critérios de negócio ou mesmo por uma análise combinada destes dois
fatores. Esta visão de empresa híbrida e nuvem híbrida tem sido propalada por
diversos outros fornecedores do mercado, mesmo de outros segmentos como VMware,
EMC, HP, etc.

É fato! A ideia da nuvem híbrida era no começo vista como uma forma
conservadora da empresa entrar no mundo de cloud para depois abraçar 100% a
nuvem pública. Mas  na realidade faz mais
sentido o mundo se tornar híbrido pois cada tipo de aplicação tem suas
necessidades..

Após contextualizar tudo isso vou reproduzir abaixo a conversa que tive com Hansang
Bae que é Chief Scientist na Riverbed Technology na qual ele contou muito sobre
a empresa Riverbed, os novos produtos STEEALHEAD 9.0 e STEEALCENTRAL
APPRESPONSE 9.5 e conseguiu me dar uma ideia como eles funcionam e suas
aplicações

Flavio: estou realmente
impressionado com o conceito da “empresa híbrida”. Gostaria de saber um pouco
mais dos tipos de clientes, os recursos e soluções que eles estão planejando
usar, etc…

Hansang: nós temos um grande cliente
da área financeira, com presença global com mais de 360 pontos espalhados no
mundo. O CEO mora nos EUA, o CFO mora em São Paulo, o COO mora na Irlanda e um
dos mais importantes líderes na área de negócios mora em Singapura. Hoje eles
usam nosso produto SteealHead para fazer as aplicações rodarem mais rapidamente
em 160 localidades. As outras localidades ou não tem tanta relevância ou estão
bem perto de onde atuam (a otimização seria apenas um “luxo”). Eles migraram do
Lotus Notes para Office 365. Durante o tempo que conviveram juntos o Lotus
Notes teve melhoria de desempenho. Mas o maior desafio foi, ao usar o Office
365. Isso porque que sentido tem o acesso do usuário vir para o Datacenter dos
EUA para ter acesso aos seus e-mails e recursos do Office 365? Cada escritório
remoto tem conexões simples e baratas com a Internet. Porque fazer com que o
tráfego circulasse pela VPN da empresa até os EUA para de lá sair para o Office
365 nos servidores da Microsoft? O CTO logo percebeu que precisaria do
SteealHead em todas as localidades remotas. Dessa forma o Steealhead saberia
analisar o tráfego, perceberia que se tratava de acesso Office 365 e desviaria
para o acesso direto a nuvem e não via VPN e ao Datacenter da empresa.

Flavio: mas como esta ocorre esta seleção?
Como este desvio é feito uma vez que é função dos roteadores comutar e
encaminhar pacotes de dados?

Hansang: os roteadores não têm a
inteligência de analisar, conhecer e tratar a camada da aplicação. Eles apenas conhecem
e sabem tratar endereços IP. Nós sabemos a diferença. No pacote sendo trafegado
sabemos também seu IP, mas detectamos se é originário de MSN (usado pela rede
de jogos da Microsoft) ou de acesso MSDN (rede usada pelos desenvolvedores para
suporte, consulta a base de conhecimento, download de ferramentas, etc.). Ao
saber que tipo de aplicação é podemos tratar de acordo, desviar o tráfego,
otimizar… Não dá para otimizar algo que você não sabe o que está fazendo. Se
é um tráfego não crucial pode ser desviado pela Internet enquanto o mais
crítico trafegar pela rede MPLS privativa. Veja que no exemplo da Microsoft
(MSN e MSDN) ambos acessam o mesmo destino final (Microsoft), mas os
desenvolvedores têm prioridade sobre o uso da rede MSN. Podemos fazer isso. Garantimos
a qualidade do serviço (QoS) e por consequência o comportamento daquele
tráfego. Podemos fazer isso tudo.

Flavio: Na apresentação anterior eu
vi que há aplicações conhecidas pelo SteealHead e que SAP, por exemplo, ainda
não é suportado (mas será). Não há algum tipo de benefício no uso de SAP com o
SteealHead ou existe e o nível de melhoria é menos relevante?

Hansang: SAP vem sendo vendido como
uma aplicação “on-premisse” (usada na rede interna), implantada pelos
consultores nos servidores da empresa com alto grau de customização em cada
implantação. No modelo SaaS (Software as a Service) isso não acontece. Veja o
caso do SalesForce que é 100% modelo SaaS e todos os dados trafegam via http.
Nós somos muito fortes na otimização deste tipo de tráfego. SAP está ampliando
sua oferta para a versão do produto SaaS e dessa forma teremos como realizar
grandes otimizações nesta área também.

Flavio: só para ficar mais claro,
antes da Riverbed otimizar aplicações como você está falando seu produto era
muito conhecido como um otimizador de tráfego em WAN. Algo genérico. É isso?

Hansang: isso mesmo. Você conhece o
compactador Winzip, certo? O que nós fazíamos antes era basicamente fazer um
“Winzip na linha”. A cada pacote trafegado íamos comprimindo, enviando pelo
meio de comunicação e descompactando na outra ponta em tempo real. Dependendo
do tipo de pacote podemos obter de 30% a 40% de redução no volume de tráfego.
Dados com texto podem comprimir mais, algo como 90% ou mais. Imagens não são
comprimidas. Na média consideremos 50%. Mas nós criamos uma forma completamente
diferente de pensar a operação pensando também na latência existente nas linhas
de comunicação (tempo entre enviar uma informação e obter uma reposta).

Flavio: então não se trata apenas de
compressão. O que mais acontece?

Hansang: imagine um usuário querendo
abrir um arquivo que se encontra em um servidor da sede da empresa a milhares
de quilômetros de distância e ele está em uma filial, em um hotel ou mesmo em
Starbucks. Uma interação nesse caso leva algumas centenas de milissegundos
(alguns décimos de segundo – 0.3, 0.4, 0.5…). Ele vai clicar no arquivo para
transferir seu conteúdo. Por limitações das leis da física, a transferência
nunca ocorrerá a mais que 70% da velocidade da luz. Mas antes de começar a
transferência muita coisa tem que acontecer.

Flavio: e isso atrasa a operação de
abertura do arquivo?

Hansang: veja o que acontece. Nos
bastidores após ele clicar o sistema operacional tem que perguntar “você é um
arquivo ou um diretório (pasta)?”.  Vem a
resposta, “sou um arquivo”. Em seguida “eu posso abrir este arquivo agora?”,
resposta “sim você pode”. “Alguém mais está com este arquivo aberto?”, resposta
“não tem ninguém usando este arquivo”. “eu tenho direito de ler este arquivo?”,
reposta “sim você tem”. “Posso abrir este arquivo?”, “sim você pode”.  “Posso obter o primeiro bloco de dados deste
arquivo?”, “sim você pode”… Este diálogo é um resumo do processo que pode ter
mais de 20 passos até que algo seja efetivamente trazido para a tela do usuário.
Cada passo levando alguns décimos de segundo, no final para começar a abrir o
arquivo muitos segundos terão se passado. É muito tempo. Todo e qualquer
arquivo para ser aberto remotamente passa por isso.  

Flavio: mas como se resolve isso?

Hansang: a Riverbed entendeu este
processo. Como nosso produto roda nas duas pontas a solicitação de abertura do
arquivo é enviada de uma ponta para a outra. Localmente todas as perguntas e
respostas são feitas e respondidas de forma instantânea (acesso local) e no
final apenas a transferência dos dados ocorre entre as localidades. É uma
abordagem diferente para otimização. Qual é a “viagem” mais rápida que um dado
pode realizar? É a viagem que não precisa fazer (tempo zero). Poupamos um tempo
imenso não fazendo muitas perguntas remotamente. Este é um exemplo de conceito
mais amplo de otimização bem além da simples compressão de dados na
transferência (que também acontece). A percepção de agilidade para o usuário
será muito maior. Em vez de levar 10 segundos entre clicar no arquivo e recebê-lo,
demorará perto de 1 segundo. Isso porque nós pudemos estudar e compreender como
a aplicação funciona. É a diferença entre “o dia e a noite”. Este é o problema
que nós equacionamos e resolvemos com o SteealHead.

Flavio: vamos falar mais do conceito
da “empresa híbrida”. Qual é o desafio?

Hansang: eu fui o responsável pela
rede do Citigroup por mais de 30 anos. Centenas de milhares de usuários, 105
países, dezenas de milhares de localidades. Apenas para citar um exemplo, no
México entre 4 e 6 mil localidades. Deu para ver como é imensa essa rede.
Imagine que um cliente com 5 ou 6 usuários (distintas localidades) precisa se
comunicar com alguns milhares destes pontos. Imagine a quantidade de conexões
ponto a ponto que seriam necessárias e quanto dinheiro seria gasto nestes
circuitos!  E se nós pudéssemos usar um
provedor de Internet via cabo do tipo Time Warner, Wox Cable, Verizon,
AT&T… links de comunicação baratos que pudessem ser usados no lugar de
circuitos dedicados e caros. Nós fizemos na época um estudo e descobrimos que
faríamos uma economia de mais de 3 milhões de dólares no primeiro ano!! Do
ponto de vista econômico, OK, mas como eu vou resolver problemas técnicos,
identificar e diagnosticar problemas de conexão? Não dá para chamar o “Helpdesk
da Internet”. Como posso garantir o desempenho? E se estiver acontecendo uma
transmissão em tempo real de um jogo da Copa do Mundo ou um desfile de
lançamento da Victoria’s Secret? Estes eventos têm capacidade de derrubar
conexões ou reduzir muito o fluxo de dados em certas regiões derrubando a rede e
a colocando de joelhos por causa de quantidade de pessoas assistindo ao evento
ao vivo pela Internet.

Flavio: Se você estiver competindo
com algum desses eventos online de grandes proporções, como vou garantir que meus
escritórios remotos vão conseguir usar os recursos de que precisam??

Hansang: A resposta simples para
isso é, você não pode! Então eu não posso fazer isso porque não posso perder o
controle. Mas aplicando o conceito de rede híbrida da Riverbed nós conseguimos
resolver porque temos o conhecimento profundo das aplicações e como elas
funcionam. Por isso que o primeiro desafio é identificar o tráfego para não ter
que pagar o preço quando a Internet estiver congestionada ou “ocupada”. Acompanhe
a seguinte analogia. Você está com um carro na estrada e segue avançando
mudando as marchas, de 1ª para 2ª, 3ª, 4ª, 5ª e entra em velocidade de
cruzeiro. Nessa hora a velocidade é máxima e é baixo o consumo de
combustível… Mas se os carros começam a diminuir ou um farol fica vermelho e
parar, você tem que sair daquela situação de equilíbrio, reduzir as marchas uma
a uma e eventualmente parar até poder começar de novo. Isso é ruim, atrasa a
viagem, consome mais recursos. E isso se repete várias vezes. Na Internet acontece
da mesma forma.

Flavio: mas existe alguma forma de
superar estas situações??

Hansang: uma de nossas técnicas
avançadas de otimização nos permite “não reduzir marchas” quando o tráfego
começa a parar e conseguimos “passar por entre os carros” que estão parando e
seguir na mesma velocidade de cruzeiro, plena velocidade. Com nossa solução
SteelHead rodando em um provedor de serviço de nuvem ou na matriz da empresa e
nos escritórios remotos conseguimos usar este “motor turbinado” para passar as
informações em plena velocidade sem ser afetado pelos congestionamentos,
permanecendo “engatado na 5ª marcha” enquanto outras pessoas (outros tráfegos)
precisam reduzir por causa do congestionamento.

Flavio: por acaso esta incrível
solução está relacionada com uma escolha muito inteligente de caminhos,
roteadores alternativos, ou algum tipo de protocolo especial que foi
desenvolvido pela Riverbed?

Hansang: um dos nossos fundadores,
Dr. Steven McCanne, um dos fundadoreas da
Riverbed e professor na Universidade de Berkeley, francamente um gênio, teve
esta ideia pesquisando o protocolo TCP/IP. Ele é muito famoso e conhecido neste
campo. Ele nos fala que o problema do TCP é que ele foi inventado nos anos 60.
É um protocolo velho. Imagine pegar um carro feito nos anos 60 e colocá-lo em
uma super estrada dos dias de hoje. Ele não vai funcionar, não vai ter o mesmo
desempenho e segurança dos carros atuais. Mas é o que fazemos mesmo nos dias de
hoje com o TCP. TCP é de fato uma tecnologia muito antiga e ultrapassada. O que
o Dr. McCanne fez foi encontrar jeitos de
superar estas limitações.

Flavio: mas como ele fez isso?

Hansang: usando essencialmente o que
existe ele percebeu que não precisava se preocupar se o mundo tudo usa o TCP/IP
de uma forma e nós usarmos de uma maneira diferente. Isso porque basta que haja
um SteealHead em cada uma das pontas que esta comunicação ponto a ponto pode
fluir de uma forma otimizada desenvolvida por ele e em alta velocidade. Este é
apenas um dos aspectos de nossa otimização. Há outros algoritmos em uso que
agregam mais velocidade e segurança.

Flavio: existe mais algum exemplo
que você pode citar?

Hansang: imagine que você mande um
documento de um ponto para outro. Que ele seja alterado, tenha algumas frases
ou palavras inseridas e alteradas e enviado de volta. Fazemos algumas coisas.
Inicialmente a compressão, isso é básico e sempre executado. Mas também criamos
uma “tabela de símbolos” sobre as frases mais comuns. Por exemplo “como está você?” atribuímos um código,
por exemplo “AA”, um símbolo.

Flavio: desculpe-me por interromper,
mas é um tipo de deduplicação?

Hansang: isso mesmo. Criamos um “dicionário
de deduplicação”. Quando você manda aquele documento de volta, nós já
aprendemos como aquele documento se parece, criamos os símbolos. Ao fazer as
modificações e mandá-lo de volta, em nosso mundo otimizado apenas as partes que
foram alteradas é que serão mandadas de volta, E como também usamos aquelas
tabelas de símbolos aproximadamente 95% do documento não precisará ser
transmitido de volta. O SteealHead ao receber o que foi transmitido saberá
substituir os “símbolos” por “como está
você?” ou “o projeto está a caminho”…
Nosso protocolo otimizado, compressão simples, tabelas de símbolos e
transmissão só do que foi alterado, isso tudo nos permite acelerar bastante a
comunicação. E não se esqueça daquela otimização do diálogo entre a parte local
e remota feita toda de uma vez só, eliminando toda a latência, as inúmeras
perguntas e respostas… No final, com tudo isso a experiência do usuário é
muito melhorada. A diferença é como se fosse “o dia e a noite”!

Flavio: mas isso tudo não acaba
trocando segurança por velocidade?

Hansang: não, de forma alguma. Pelo
contrário. Na verdade nós aprimoramos a segurança porque os dados que fluem
entre os pontos A e B são codificados (deduplicação), comprimidos e por fim
encriptados com chave de 256 bits. Tanto que o governo dos EUA é um de nossos
maiores clientes. Mesmo na área militar há utilização de nossa tecnologia.
Assim fica claro que segurança é nossa maior preocupação.

Flavio: o que me parece interessante
é que você nos contou como tudo acontece para um documento. Mas imaginemos isso
acontecendo com centenas ou milhares de arquivos. A diferença pode ser brutal.

Hansang: eu vou te dar um exemplo,
um caso bem importante. Pense na migração de um SharePoint da rede local da
empresa para o mesmo serviço na nuvem da Microsoft, a solução de SharePoint do
Office 365. A empresa ativa na nuvem Microsoft Azure o serviço e começa a migração
de seus milhares de documentos. O SharePoint é um imenso repositório de
arquivos. Imagine mover tudo isso para a nuvem. Se a empresa usa nossa solução
SteealHead ela vai se beneficiar da compressão, codificação, nosso protocolo
otimizado, etc. Mas o que acontece se um usuário modificar documentos no meio
da migração? Não é realista falar para os usuários não tocarem nos documentos
durante o processo, pois esta pode demorar duas horas ou dois dias dependendo
da quantidade de arquivos. Isso não pode ser assim, os usuários teriam sua
rotina de trabalho interrompida e prejudicada. Com a nossa solução nada disso
importa para o usuário, pois se algo mudar, apenas aquilo que mudou e apenas a
parte que mudou será enviada de novo para o novo sistema na nuvem. 99% dos
documentos não precisarão ser retransmitidos.

Flavio: então este tipo de migração
é algo comum?

Hansang: sim, bastante e como temos
nossa tecnologia presente nos Datacenters, por exemplo, da Microsoft e da
Amazon se o cliente adotar nossa solução SteealHead, não apenas a migração é
muito simplificada como o uso no dia a dia. Se ele usava o Office 365 ou
SharePoint na rede local ou WAN privada, com latência muito baixa (menor que 5
ms), ao passar para a nuvem ele não saberá onde estarão os seus dados. Em
Atlanta, Mexico City, São Paulo, Singapura… a Microsoft que vai alocar aquele
recurso em algum lugar do mundo (mais de 70 Datacenters ao redor do mundo). O
cliente não tem muito controle sobre isso. Mas ao adotar a nuvem, para manter o
nível de desempenho que ele estava acostumado (rede local ou WAN privada) ele vai
precisar de nossa solução, seja para a migração, para manter o desempenho
máximo no uso do recurso na nuvem ou mesmo para fazer algum tipo de
“Troubleshooting” e resolver alguma situação pontual. O SteealHead tem também
essa capacidade de auditoria e ajudar na identificação e solução de problemas.

Flavio: então deve haver muitos e
muitos appliances Riverbed SteealHed nos Datacenters da Microsoft ou outros provedores
de nuvem para que os clientes possam se beneficiar deste recurso.

Hansang: certamente e nossos
clientes podem fazer mais. Podem também contar com o serviço complementar da
empresa Akamai que é nossa parceira. Imagine uma coisa, o cliente pode “subir”
um serviço SteealHead em seus servidores na nuvem e a partir de seu escritório
central acessá-lo diretamente. Mas se ele usar a rede da Akamai ele tem
facilidades com o licenciamento. Basta ele acessar um portal da empresa,
fornecer uma chave de ativação que o SteealHead já estará licenciado e pronto
para operação. Mas além disso a Akamai vai replicar esta configuração em
diversos locais do mundo onde for necessário e de forma automática. Você não
tem que se preocupar em iniciar o SteealHead em vários lugares do mundo. A
eficiência operacional que a Akamai traz é de grande benefício para o cliente
sobretudo para aquele com grande distribuição geográfica. Caso contrário a empresa
deveria analisar quais processos usam recursos na nuvem da Amazon e fazer a
conexão por um específico SteealHead, quem usa recurso de nuvem na Microsoft
Azure e fazer a conexão por outro SteealHead. Ele terá que gerenciar isso tudo
sozinho. Usando a rede da Akamai a empresa não tem que fazer nada além de
licenciar o produto. Todo o direcionamento para o serviço certo será feito
automaticamente.

Flavio: mas como fica o modelo
comercial neste caso. A Riverbed não estaria perdendo receita dessa forma
deixando com a Akamai essa função?

Hansang: na verdade o contrário
acontece. O cliente terá que contratar o serviço da Akamai para usar a sua rede
e sistema de replicação de conteúdo. Mas para ele ter os benefícios ponto a
ponto que já conversamos ele precisa ter um Steealhead em cada localidade
remota que se comunica com seu par na rede da Akamai. Todos ficam felizes, o
cliente que terá um serviço fantástico e otimização de suas aplicações e tanto
Riverbed como Akamai que vendem os seus serviços. É uma situação ganha-ganha-ganha,
todos ganham.

Flavio: eu imagino que neste
cenário, quando o cliente faz uma “prova de conceito” (POC), ele vê os
benefícios rapidamente e fica difícil para ele desligar aquela solução.

Hansang: é exatamente isso que
acontece. Nós levamos o SteealHead e o ligamos. Ele já percebe os benefícios.
Depois desligamos e ele sente a diferença. A prova de conceito está rapidamente
concluída e com benefícios facilmente percebidos.

Flavio: o que deve acontecer daqui
para a frente? Quais são as evoluções que podemos esperar nos serviços e
produtos oferecidos pela Riverbed?

Hansang: já estamos trabalhando e
entregando os próximos passos. Trata-se de aumentar cada vez mais a
visibilidade por parte do cliente tudo sobre seus meios de comunicação,
acompanhar mais de perto se o SLA do provedor de serviço está mesmo sendo
cumprido e com muita informação auxiliar no processo de “Troubleshooting”, seja
ele o provedor do link, SalesForce, Office 365, não se importando onde os
usuários estejam e apenas usando todos os recursos da forma mais eficiente
possível. Tudo está indo para a nuvem e por isso este nível de precisão e de
informação é muito importante.

Flavio: é por este motivo que o
produto SteealCentral AppResponse é tão importante?

Hansang: exatamente porque esta é a
parte da solução que provê máxima visibilidade. Imagine que existe o SteealHead
na localidade remota e também na nuvem. O SteealCentral usa as informações do
SteealHead para consolidar e visibilizar tudo que o usuário precisa para ter a
operação mais coordenada e otimizada possível e monitorar o grau de experiência
bem de perto. Tem como saber em cada passo da comunicação quanto de tempo foi
gasto em cada etapa. No Datacenter o Steealhead pode, por exemplo, acompanhar o
desempenho do SalesForce e assim poder saber se algum evento relacionado com
desempenho está no serviço do próprio Salesforce e acionar o caminho certo para
resolver. Inclusive vemos este tipo de solução como algo que é algo novo para
nós. Alguém pode não querer nossa solução de otimização, mas pode precisar
monitorar e obter as informações sobre os serviços que estão usando na nuvem e
realizar “Troubleshooting”. Eu lembro que ao usar serviços na nuvem nós nunca
sabemos quão longe estarão os recursos que vamos utilizar. Por isso ter a
visibilidade é muito importante e eventualmente perceber a necessidade (ou não)
da otimização que também podemos proporcionar. Este é um ponto importante!

Flavio: eu quero agradecer a
oportunidade. Pude esclarecer muitos pontos e muitas ideias!

Essa foi a conversa com Hansang Bae, muito informativa e esclarecedora. Em
futuros textos vamos explorar um pouco mais as alternativas de solução da
Riverbed.