COMPUTERWORLD - O portal voz do mercado de TI e Comunicação

Por Richard Stone, da Compuware, de Londres *

Com o aumento da popularidade da cloud computing como uma alternativa poderosa ao modelo tradicional de serviços de TI, os problemas com gerenciamento de desempenho de aplicativos (APM – application performance management) estão ficando novamente em primeiro plano.

A dura realidade é que, seja você uma empresa criando sua própria nuvem privada ou um provedor de serviços oferecendo serviços de nuvem pública, um desempenho pobre irá imediatamente desgastar a confiança do cliente, reduzir a adoção pelo usuário final e impactar a receita da companhia.

Isto ocorre porque ambos os aplicativos – internos e externos -, precisam ser gerenciados em um modelo integrado, de ponta a ponta, através de qualquer tipo de infraestrutura de nuvem que estejam hospedados, e não apenas no data center físico. Mais especificamente, a computação em nuvem irá nos forçar a redefinir o que constitui exatamente um acordo de nível de serviço (SLA – service level agreement) nesse novo mundo da TI.

O desafio

Em sua forma mais simples, a cloud computing é uma maneira de melhorar o acesso à informação para funcionários, parceiros ou clientes. A informação da nuvem deve ser acessível de qualquer lugar, em qualquer hora ou em qualquer dispositivo. Isto, é claro, exige que os aplicativos baseados na nuvem que estejam sendo utilizados sejam gerenciados de maneira eficaz. O principal desafio com a nuvem é que os aplicativos são hospedados fora do controle das quatro paredes do data center tradicional.

Assim, os gerentes de TI deparam com um novo problema: como oferecer um SLA se há uma falha técnica em um aplicativo da nuvem que está fora do alcance de sua empresa – e, portanto, fora do seu controle –, e ninguém sabe onde o problema está situado ou como resolvê-lo?

Os provedores de serviços na nuvem são geralmente relutantes em se comprometer com SLAs específicos. Para aqueles que o fazem, existe uma grande inconsistência em relação ao que constituem suas promessas aos clientes. O site de compras norte-americano Amazon, por exemplo, cita a disponibilidade em termos de interrupções, períodos de cinco minutos ou mais durante o ano de serviço no qual a Amazon EC2 esteve na condição de “região indisponível”.

Outros preferem citar estatísticas mais gerais, como “múltiplas conexões de Internet com gigabit redundante” e “maior que 99,95% da disponibilidade de serviços”.  Quando departamentos internos de TI comparam isso com cerca de 95 minutos por mês de inatividade que eles experimentam para o servidor Exchange comum, a reação inicial é que não há necessidade de se preocupar com a disponibilidade de desempenho da nuvem.

Pontos críticos

Entretanto, essa suposição ignora dois importantes pontos críticos. Primeiro, tão importante quanto a disponibilidade, é se um serviço é rápido o suficiente. Segundo, o provedor de serviços é apenas uma parte de uma cadeia de entrega de aplicativos cada vez mais complexa. Da perspectiva do usuário final, um desempenho pobre ou a indisponibilidade de um aplicativo parecem a mesma coisa, independentemente de onde o problema realmente está na cadeia de entrega de aplicativos.

Um cenário pior é o caso do “todas as luzes estão verdes” no data center, embora alguns (não todos) clientes reclamem de problemas de desempenho. Sem informações detalhadas sobre falhas no domínio através de toda a cadeia de entrega, é virtualmente impossível isolar e resolver problemas de desempenho e disponibilidade em questão de tempo, antes que eles comecem a impactar os usuários.

Para complicar ainda mais, a localização geográfica, o desempenho do “Last mile” (ISP) e até a hora do dia podem também causar um impacto dramático no desempenho geral de um aplicativo baseado em nuvem. Nossos testes mostram que, quanto mais longe geograficamente o usuário estiver do aplicativo, mais devagar será o desempenho – que pode ter uma diminuição de até seis segundos no tempo de resposta, em algumas situações. Em muitos casos, o desempenho também é impactado pela conexão ISP, ou a chamada “last mile”.

O desempenho dos provedores de serviços na nuvem não é constante, mas pode mudar largamente ao longo do dia, porque o provedor de serviços está lidando com uma carga variável de outros usuários em sua infraestrutura. Isto desafia a noção de que a nuvem provê “elasticidade rápida”, ou seja, que amplas variações em carregamento podem ser acomodadas sem impactar significativamente o desempenho dos aplicativos individuais.

Na verdade, os provedores de serviços na nuvem têm que viver de acordo com as mesmas regras de economia como todo mundo. Eles não possuem bancos de servidores à disposição para cooperar com esses picos de demanda. Consequentemente, mesmo que os aplicativos operem em suas próprias instâncias no provedor de serviços, seu desempenho é afetado pelo que seus vizinhos estão fazendo.

Pacotes

Fred Smith, o fundador do FedEx, disse uma vez: “Informações sobre o pacote são tão importantes quanto o pacote em si”. Ele quis dizer que não é suficiente prover uma declaração geral de qualidade de serviço.

Você deve ser capaz de apresentar informações sobre o serviço específico que você oferece a um cliente específico em um momento específico, não importando onde o pacote está.  O mesmo pode ser aplicado com os aplicativos baseados em nuvem, ou “sem fronteiras”, que devem ser monitorados e gerenciados, independente de atributos físicos, virtuais ou da nuvem.

Ferramentas tradicionais de gerenciamento de desempenho de aplicativos em empresas não estão aptas à tarefa de gerenciar essa nova geração de aplicativos porque elas apenas oferecem visões estreitas e centradas na tecnologia sobre o desempenho de componentes ou processos específicos.

A única maneira de realmente resolver os problemas de desempenho e disponibilidade é por meio de uma visão holística do desempenho dos aplicativos, que inclua toda a cadeia de entrega de aplicativos. Sem isso, qualquer esperança de oferecer um SLA para a nuvem irá cair rapidamente por água abaixo.

* Richard Stone é gerente de Soluções de Cloud Computing da Compuware e fica baseado em Londres