quarta-feira, 19 de novembro de 2014

PRTG – acompanhando a infraestrutura crítica (sem custo) e com novos sensores

Há algumas semanas publiquei o teste  da versão mais atual da ferramenta PRTG, um recurso essencial para auxiliar a manter a infraestrutura de TI sob estreita vigilância. Mas percebi que características técnicas à parte, sobraram algumas dúvidas em relação aos benefícios que este tipo de solução traz de fato para as empresas. É oportuno discutir mais um pouco estes conceitos e ao mesmo tempo noticiar a nova versão gratuito da ferramenta que traz interessante benefício adicional.

Os recursos de TI hoje são críticos para as empresas. Há ramos de atividades que a TI é parte do negócio. Não é apenas um apoio operacional. É bem mais do que isso. Por isso ser capaz de identificar, resolver problemas rapidamente e ser capaz de se antecipar na prevenção de situações críticas é de extrema relevância. Vital para a saúde do negócio.

Quem gerencia TI precisa dispor de informação de qualidade para poder tomar as corretas decisões. Caso contrário eventos que venham causar alguma pane ou comprometimento na infraestrutura não serão facilmente percebidos ou localizados. Acompanhar indicadores especialmente selecionados permite os profissionais de TI a atuar de forma bem proativa ajudando-os a descobrir problemas e evitá-los antes mesmo de terem acontecido.

Podemos comparar a uma UTI de hospital. Existe um “painel de controle” no qual há sensores de muitos tipos acompanhando várias funções vitais. No caso do hospital são monitorados batimento cardíaco, pressão arterial, nível de oxigenação, taxa de açúcar no sangue, etc. Se os médicos percebem uma queda da pressão com rápida recuperação, isso tem um significado. Se a pressão está lenta e continuamente caindo isso tem outra interpretação e vai exigir sérias medidas. No ambiente de TI acontecem as mesmas coisas.

Usando uma ferramenta como o PRTG podem ser escolhidos os pontos críticos de monitoração e problemas podem ser antecipados e administrados. Nem sempre uma grande pane é a responsável pela interrupção dos serviços vitais na empresa. Há situações muito simples e ao mesmo tempo muito comuns, como por exemplo o incremento do uso de poder de processamento em um servidor crítico. Este é o desafio. Ser capaz de enxergar isso a tempo e atuar de maneira proativa.

O valor da ferramenta PRTG para os negócios é permitir apontar problemas reais que já aconteceram e que necessitam de atenção urgente e imediata. Também viabiliza acompanhar de perto o que pode vir a ser fator de comprometimento futuro. Isso tudo garante a continuidade da operação dos recursos de TI sem impactar os processos de negócio. Uma interrupção mesmo que breve pode custar caríssimo para as empresas. São muitos os pontos que requerem acompanhamento visando detectar possíveis falhas. O talento natural do PRTG é exatamente este. O olhar incansavelmente para todos os pontos críticos e ajudar a evitar prejuízos para as empresas que podem advir do comprometimento da parada de processos críticos para o negócio.


figura 01 – console principal do PRTG (clique para ampliar)

Testando antes de adquirir - versão gratuita e novos sensores

A empresa Paessler disponibiliza gratuitamente uma versão do PRTG que contempla a totalidade de recursos e funcionalidades presentes na solução. Não tem data de validade ou expiração. Isso é ótimo! Porém existe uma limitação que é o número de sensores. Lembro que o conceito de sensor é “cada informação monitorada” pelo PRTG. Estes dez sensores permitem que o produto seja testado em sua plenitude e até mesmo ser usado em produção em cenários menos abrangentes. Se a empresa implantar esta versão, testar nesta configuração e precisar ampliar o número de sensores o produto pode ser adquirido, inserida a chave definitiva de ativação. Assim o número limite de sensores passa a ser a quantidade contratada (100, 500, 1000, 5000, etc.).

Mas a Paessler percebeu que para tornar ainda mais fácil o processo de testes de seu produto seria interessante ampliar o número de sensores da versão gratuita. E assim ela o fez, ampliou de 10 para 30 sensores (triplicando a quantidade original). E essa mudança veio junto com a inclusão de alguns novos tipos de sensores que proporcionam aos usuários novas opções de monitoramento. Por exemplo, pode ser monitorado todo o processo de e-mail de uma organização, incluindo Microsoft Exchange, POP3, SMTP e IMAP.

"As redes de TI das empresas estão mais complexas e distribuídas", considera Dirk Paessler, fundador e CEO da Paessler AG. "A ampliação de sensores irá se adequar melhor ao escopo das redes modernas e permitir que nossos usuários da versão gratuita verifiquem detalhadamente as potencialidades do PRTG Network Monitor"

Com o aumento do número de sensores na versão gratuita do PRTG Network Monitor, os usuários podem controlar presença na rede, a largura de banda, sistemas de armazenamento, firewalls, etc. - e ainda destinar sensores para aplicações empresariais dedicadas. Estão disponíveis cerca de 200 tipos de sensores, incluindo opções para o Windows WMI, Linux / Unix / OS X, VoIP / QoS, servidores de banco de dados SQL e muito mais.

Monitoramento do Exchange e de e-mails
A versão gratuita do PRTG Network Monitor oferece sensores baseados no PowerShell do Exchange para monitoramento de backups, bancos de dados e filas de e-mail, juntamente com uma gama de sensores WMI.  Sensores adicionais pré-definidos suportam o monitoramento de servidores POP3, SMTP e IMAP.

Visto que o e-mail é uma das funções mais importantes para a maioria das empresas, a Paessler oferece vários recursos para monitorar o ciclo de envio e recebimento. Os sensores de tempo de resposta (Email Round Trip) permitem aos usuários comprovar se os e-mails foram enviados e recebidos. Monitorando um servidor Exchange, eles também podem verificar o tempo necessário para o ciclo envio/recepção.

Usuários que hoje estão testando a solução gratuita ou mesmo usando em regime de produção o PRTG podem ampliar a capacidade de sensores. Para isso basta utilizar o recurso “AUTO-UPDATE”, realizar a atualização do produto que o novo limite de sensores (30) entrará automaticamente em operação. Novos usuários ao fazerem o download já receberão a versão gratuita.



figura 02 – interface WEB  do PRTG (clique para ampliar)

terça-feira, 11 de novembro de 2014

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

Nos últimos 10 anos a empresa Riverbed se notabilizou por sua capacidade de entregar soluções para otimizar o tráfego de informações em ambiente de redes remotas (WAN).  Diversas arquiteturas, principalmente MPLS se tornaram muito populares por sua eficácia e nível de serviço, mas não pelo custo que normalmente é elevado. Era um tempo no qual o termo “nuvem” não era usado da forma como entendemos hoje em dia e a preocupação das corporações era interligar ponto a ponto os seus escritórios remotos, filiais, unidades fabris, etc.


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


Entrevista com Hansang Bae – Chief Scientist – Riverbed Technology





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.