O desempenho da interface com o usuário é muito importante para aplicativos da web, pois é a parte do aplicativo da web (e da nuvem também) com a qual o usuário, que é o cliente, interage. Se a experiência do usuário for ruim, os usuários irão reclamar e os clientes se recusarão a comprar o produto.

Como engenheiro de desempenho do IBM SmartCloud Enterprise, desenvolvi uma estrutura de automação completa para desempenho de interface com o usuário que fornece medições profissionais, incluindo:

• Métricas de desempenho baseadas na página
• Estatísticas de monitoramento e captura necessárias
• Simulação e controle de largura de banda de rede
• Controle de funcionalidade baseada em diversos parâmetros

Embora a maioria desses problemas já tenha sido resolvida por softwares de monitoramento de desempenho baseados na web, ainda há dois grandes desafios que precisam de atenção:

• Desafio nº 1: Como é possível definir e obter automaticamente as informações detalhadas de desempenho para algumas solicitações especiais?
• Desafio nº 2: Como é possível calcular o desempenho preciso da página a partir de experiências do usuário final?

Como exemplo para o Desafio nº 1, há três solicitações RPC na página de painel de controle do IBM Cloud: getInstances, getAvailableImages e getAvailableStorage. Essas são as solicitações mais importantes, que podem prejudicar o desempenho da página. É necessário avaliar e reportar diariamente ou semanalmente as métricas de desempenho dessas solicitações.

Considere isso como um requisito geral: você irá precisar de um módulo automatizado que pode detectar e focar qualquer solicitação especial (como esses RPCs), além de capturar ou calcular os detalhes sobre o desempenho. Isso inclui itens como:

• Solicitações Client begin
• Solicitações Client done
• Respostas Server begin
• Respostas Server done
• Respostas Client begin
• Respostas Client done

É difícil encontrar um mecanismo ou ferramenta existente de terceiros que possa ser usado diretamente para lidar de maneira automática com esse nível de monitoramento de desempenho, por isso, eu considero isso um desafio.

Por que eu lançaria o Desafio nº 2? Porque as soluções gerais sempre fornecem o tempo para o carregamento total como a resposta da página, e o tempo não pode ser dividido. Porém, às vezes, você não se importa com o tempo de carregamento total, é preferível poder medir o desempenho a partir de uma solicitação inicial definida por você até uma solicitação de término também definida por você. Há métricas significativas e úteis para desenvolvedores da web que estão ajustando o desempenho, se eles quiserem se concentrar em cálculo de intervalo para obtenção de melhorias contínuas de código e de desempenho em ciclos de vida de regressão.

Posteriormente neste artigo, vamos analisar com mais detalhes como essa estrutura responde aos desafios de capturas de tipo de métrica automatizada e de capturas de tempo de intervalo, mas primeiro vamos examinar a estrutura, a integração do Fiddler e, mais tarde, discutiremos como a estrutura interage com um ambiente na nuvem e como pode ser instalada no IBM Cloud.

A estrutura de automação e o Fiddler

Vamos analisar a visão geral da estrutura de automação a partir do nível de arquitetura (Figura 1).

Fora do módulo rosa As Proxy/Agent está o protótipo da estrutura que foi implementada. Ele pode ser considerado o principal de toda a estrutura.

Agora, vamos analisar o que há dentro do Fiddler As Proxy/Agent. Para entender melhor os detalhes do lado do Fiddler, consulte a Figura 2.

Isso aborda as interações com a parte principal da estrutura e, também, a substituição de regra do Fiddler. Há uma explicação mais detalhada posteriormente. Por enquanto, vamos examinar o Fiddler e sua integração com a estrutura.

• Fiddler é um proxy de depuração na web que registra todo tráfego HTTP e HTTPS entre seu computador e a Internet.
• O Fiddler permite que você inspecione todo o tráfego HTTP/HTTPS, defina pontos de interrupção e "brinque" com dados de entrada e de saída.
• O Fiddler registra as solicitações e as respostas, para que seja possível ver o que está funcionando e o que não está.

O Fiddler inclui um subsistema eficiente de script com base em eventos e pode ser ampliado usando qualquer linguagem .NET. A Figura 3 exibe a amostra de interface com o usuário.

Com o Fiddler, é possível aproveitar ao máximo o subsistema, escrevendo um código para criar suas extensões. É possível editar seus scripts usando o menu Rules | Custom Rules.... Ao salvar o script, ele é automaticamente recompilado e carregado no Fiddler. Os scripts são escritos no Microsoft JScript.NET e incluem acesso limitado ao Fiddler Object Model.

As regras padrão do Fiddler são armazenadas em \Program Files\Fiddler2\Scripts\CustomRules.js. Todo o código secundário irá sobrescrever esse arquivo, por exemplo, se desejar adicionar colunas customizadas à interface com o usuário do Fiddler, modificar a solicitação ou a resposta da web para metas diferentes ou trabalhar com menus do Fiddler.

Veja um exemplo simples. A adição do código a OnBeforeRequest em CustomRules.js, para procurar todas as respostas da web para uma lista de cadeias de caractere e exibir a saída calculada na customcolumn:

oSession.utilDecodeResponse();

// Create a array of strings we're looking for.
var oFindStrings = new Array( "XMLHttp", "onreadystatechange", "readyState",
 "responseBody", "responseText", "responseXML", "statusText", "abort",
 "getAllResponseHeaders", "getResponseHeader", "setRequestHeader");

// For each target string, check the response to see if it's present.
var iEach=0;
oSession["ui-customcolumn"]=String.Empty;
for (iEach; iEach<oFindStrings.length; iEach++){
    if (oSession.utilFindInResponse(oFindStrings[iEach], false)>0)
      {
      oSession["ui-color"]="purple";
      oSession["ui-customcolumn"] += oFindStrings[iEach]+"; ";
    }}

Lembre-se dos requisitos: é necessária uma interface para desenvolver interações entre o Fiddler e o usuário, ou qualquer módulo (como um programa de automação). Para fazer isso, é possível usar Fiddler -ExecAction.exe, um executável de linha de comando adequado para ser chamado de arquivos em lote ou testes de unidade.

Essa é a única interface que pode ser usada para automatizar coisas, incluindo o controle e a interação com o Fiddler, uma vez que esse comando passa sua linha de comando para a função OnExecAction do FiddlerScript para processamento, assim como a caixa QuickExec do Fiddler.

Vamos supor que foi feita uma implementação no lado do Fiddler para o Desafio nº 1, para criar uma entrega de build verification test (BVT). Configure rpc como o parâmetro para ExecAction.exe , para que o Fiddler saiba o que deve acontecer se o comando for acionado. Dessa forma, fica fácil executar essa funcionalidade: basta digitar ExecAction rpc na caixa QuickExec do Fiddler.

Para chamá-la a partir de qualquer um de seus programas de automação externos, basta definir o caminho .exe nas variáveis do sistema e executar em seu console DOS. Por exemplo, no AutoIT, o código de linha única é _RunDos("ExecAction rpc").

É o mesmo processo para o Desafio nº 2. É possível usar qualquer coisa como o parâmetro (calc_cp) e chamar no AutoIT com _RunDos("ExecAction calc_cp").

Voltar para parte superior

Mais informações sobre o desafio

Há tipos diferentes de solicitações para um aplicativo da web geral, como imagens, js, css, chamadas de aplicativo etc. Se for possível obter mais informações e métricas de desempenho para cada solicitação classificada, você poderá realizar o ajuste do desempenho, quando for necessário.

Para o IBM Cloud, há três solicitações de chamada de procedimento remoto (getInstances, getAvailableImages, getAvailableStorage) na página de painel de controle que devem ser observadas.

A solicitaçãogetInstance é projetada para obter as informações detalhadas necessárias para todas as instâncias (na verdade, máquinas virtuais) no usuário atual e, em seguida, retornar um objeto texto/json. A Figura 4 mostra a aparência disso.

A Figura 5 mostra parte das métricas brutas traduzidas do json na Figura 4.

Para esta solicitação, há somente 12 instâncias carregadas na conta de cliente atual e há 15.544 bytes recebidos (cabeçalhos: 274; corpo: 15270). Imagine que, com o aumento do número de instâncias, as informações retornadas aumentarão de forma geométrica, e a questão será o grau de escalabilidade da solicitação:

• E se o cliente possuir 1.000 instâncias?
• É escalável acomodar a maior quantidade de instâncias disponíveis em uma conta de cliente?
• Ocorre um gargalo quando o retorno é muito grande?
• Qual é o impacto de algo como isso acontecendo nos parâmetros de desempenho?

Para responder a essas perguntas e evitar possíveis problemas, em primeiro lugar, é necessário manter a solicitação getInstances mensurável e rastreável em um ciclo de vida de teste de regressão. Será necessário obter o máximo possível de métricas detalhadas e mantê-las em um formato de comparação entre objetos iguais.

E quanto ao Desafio nº 2? Qual é a importância do tempo do intervalo para o ajuste de desempenho da interface com o usuário?

Esse requisito aborda como calcular a resposta precisa da página. Em geral, é possível usar ferramentas para capturar o tempo de carregamento completo de uma página, mas, às vezes, essas métricas não são necessárias, mas sim a medição da resposta de uma solicitação especificada até outra.

Isso normalmente acontece se um desenvolvedor da web quiser obter o feedback ou ter uma estimativa com relação à efetividade de uma mudança no código. No IBM Cloud, por exemplo, quando um desenvolvedor envia o código para obter uma melhoria de desempenho da página de painel de controle e, além disso, aplica um padrão de carregamento lento para o carregamento da página, ele precisa obter métricas sobre o tempo de resposta da página, encerrando com alguma solicitação específica, para fornecer um reflexo preciso da experiência do usuário final e de como foi a atualização do código (como mostra a Figura 6).

Uma chamada de getInstances bem-sucedida resulta na exibição da tabela de instâncias no nível da interface com o usuário. A partir da perspectiva de experiência do usuário, é necessário obter o tempo exato de duração, após a tabela de instâncias ficar visível. Portanto, para uma medição de desempenho precisa, é necessário excluir, na mesma página, o conjunto de solicitações após getInstances.

Agora, vamos analisar o desempenho da estrutura em um ambiente na nuvem.

Voltar para parte superior

A estrutura na nuvem

A estrutura trabalha com o desempenho da interface com o usuário para qualquer aplicativo geral da web:

• Do lado do Fiddler, independentemente de navegador, não haverá limitação com relação a qual navegador é usado para executar a camada frontal da nuvem.
• Do lado do driver, é possível usar a mesma linguagem usada nesta estrutura AutoIT, ou apenas escrever seu próprio driver usando qualquer linguagem com a qual você esteja familiarizado. Por exemplo, é possível usar a estrutura WatiN com as programações .Net ou Selenium em Java™ .

Observe novamente a Figura 2. É possível ver os retângulos que especificam o fluxo do código. O retângulo à esquerda refere-se aos requisitos do Desafio nº 1. No desenvolvimento do lado do Fiddler, a questão é como sobrescrever o Fiddler CustomRules.js na estrutura Fiddler sem possuir documentos suportados suficientes. Sobrescreva a regra para:

• Obter todas as sessões.
• Passar por cada sessão.
• Localizar o destino por condição.
• Alocar um novo array de sessão para armazenar a sessão de destino.
• Gravar uma sessão nos arquivos.

A seguir, encontram-se amostras parciais de código sobre como processar a chamada RPC getInstances:

     var oSessions: Fiddler.Session[] = FiddlerObject.UI.GetAllSessions();
     var iSessions : Session[] = new Session[1];

     //[getInstances]for each session perform filtering:
     //if session's url equals '/cloud/enterprise/auth/cloud-rpc' && its request
       body contains 'getInstances' : save the session to RPC_getInstance_id.zip
     for (var x = 0; x < oSessions.Length; x++)
     {

          if( (oSessions[x].PathAndQuery=="/cloud/enterprise/auth/cloud-rpc") &&
              (oSessions[x].utilFindInRequest("getInstances",true)>-1)     )
          {
               iSessions[0]=oSessions[x];
               Utilities.WriteSessionArchive(
                 "RPC_getInstances_"+oSessions[x].id+".saz",iSessions,"",true);
               FiddlerObject.StatusText = "Success dump the GetInstance PRC archive
                 to RPC_getInstances_"+oSessions[x].id+".saz";
               break;

          }

     }

O processamento de getAvailableImages e getAvailableStorage é realizado da mesma forma. Escrever a versão correspondente usando essa listagem como modelo é muito simples.

Observe novamente a Figura 2. É possível ver os retângulos que especificam o fluxo do código. O retângulo à direita refere-se aos requisitos do Desafio nº 2. Sobrescreva a regra para:

• Obter todas as sessões.
• Passar por cada sessão.
• Localizar a solicitação de destino inicial por condição.
• Obter o tempo de clientBeginRequest e o ID de sessão.
• Alocar uma lista de cadeias de caractere com size=3 e armazenar as informações nesse primeiro item.
• Localizar a solicitação de destino final por condição.
• Obter o tempo de clientDoneResponse e o ID de sessão.
• Armazenar essas informações em seu segundo item.
• Calcular o tempo de duração.
• Gravar as informações em seu último item.
• Gravar a lista de cadeias de caractere em duration.txt.

Veja as amostras de código sobre como calcular o tempo de intervalo preciso para a página de painel de controle do IBM Cloud:

//[cpbegin]for each session performs filtering:
//if sessions's url equals '/cloud/enterprise/user/control?csrftoken=':
  record the ClientBeginRequest timestamp
for (var x = 0; x < o_calc_cp_allSessions.Length; x++)
{
   if( o_calc_cp_allSessions[x].PathAndQuery.Contains
     ("/cloud/enterprise/user/control?csrftoken="))
   {
      var cp_begin:String = o_calc_cp_allSessions[x].Timers.ClientBeginRequest;
      cp_b = new Date(o_calc_cp_allSessions[x].Timers.ClientBeginRequest);
      cp_array[0] = "Sid,"+o_calc_cp_allSessions[x].id+",ClientBeginRequest,"+cp_begin;
      FiddlerObject.StatusText = "the session indicating cp start is
       successfully found, with Sid: "+o_calc_cp_allSessions[x].id;
      Break;
   }
}

//[cpend]for each session perform filtering:
//if sessions's url equals '/cloud/enterprise/auth/cloud-rpc' &&
  its request body contains 'getInstances' : record the ClientDoneResponse timestamp
for (var x = 0; x < o_calc_cp_allSessions.Length; x++)
{
   if( (o_calc_cp_allSessions[x].PathAndQuery=="/cloud/enterprise/auth/cloud-rpc")
    && (o_calc_cp_allSessions[x].utilFindInRequest("getInstances",true)>-1)
     )
   {
      var cp_end:String = o_calc_cp_allSessions[x].Timers.ClientDoneResponse;
      cp_e = new Date(o_calc_cp_allSessions[x].Timers.ClientDoneResponse);
      cp_array[1] = "Sid,"+o_calc_cp_allSessions[x].id+",ClientDoneResponse,"+cp_end;
      FiddlerObject.StatusText = "the session indicating cp end is successfully
       found, with Sid: "+o_calc_cp_allSessions[x].id;
      break;
   }

}
//try calc the duration
if(cp_b != null && cp_e !=null)
{
   var timePast : double = (cp_e - cp_b)/1000.00
   cp_array[2] = "Timepast,"+timePast;
   FiddlerObject.StatusText = "the time duration for cp is calculated
    successfully: "+timePast;
}

var   myByteArray:byte[]  = System.Text.Encoding.UTF8.GetBytes
 (cp_array[0]+"\n"+cp_array[1]+"\n"+cp_array[2]);

//write array to file by leveraging the built-in api.
Utilities.WriteArrayToFile(CONFIG.GetPath("Captures") +
 "duration_cp.txt",myByteArray);

No desenvolvimento do lado do driver, é necessário entender onde o código a ser alterado precisa se adaptar ao novo website. No IBM Cloud, há seis páginas incluídas para navegação na web, portanto, é necessário procurar no código e substituir as identidades da página pelas identidades esperadas em sua nuvem. Por exemplo, a Figura 7 é uma dessas amostras de página do IBM Cloud para Account. Substitua a identidade Account por sua entrada.

Para aplicar a estrutura à nova nuvem, é necessário entender o script do Fiddler, além do código do lado do driver. Consultando as amostras nas páginas na nuvem, você deverá entender facilmente como adaptá-las para criar suas próprias soluções.

Voltar para parte superior

Configurando a estrutura no IBM Cloud

É fácil configurar e usar a estrutura, pois é uma solução completa de ponta a ponta. A Figura 8 mostra uma visão geral:

Para iniciar:

• Para a instalação de software, você precisa do AutoIT e do Fiddler instalados em sua máquina.
• Como pré-requisito de configuração, execute SystVarDependencyCheck.exe para atualizar automaticamente seu sistema, para executar a solução. Adicione o caminho dos executáveis do Fiddler e o caminho dos dados padrão do Fiddler. Faça isso apenas uma vez para o primeiro usuário.
• Uma visão geral sobre os binários do lado do servidor:
  • Manager.exe é o controlador run2run.
  • UIIE_Fiddler_Shot_1.0.exe é o driver de execução de linha de base.
  • baseline.properties é a única interface necessária para o usuário, e que pode ser editada para fins customizados.
• O CustomRules.js de origem do lado do Fiddler não aparece na Figura 7, esse javascript é a interface para interagir com o Fiddler por codificação. É necessário apenas copiar o arquivo atualizado da estrutura em seu Fiddler local, como uma substituição.

Agora, deixe-me explicar como usar a estrutura nos seguintes cenários. Armazene esses arquivos em seu computador: UIIE_Fiddler_Shot_1.0.exe, Manager.exe e baseline.properties. Edite o baseline.properties, pois essa é a única interface usada para customizar a execução.

Para obter uma compreensão mais clara, veja as entradas do arquivo de propriedades:

• URL: o website na nuvem.
• ServerAddress: o IP da máquina do aplicativo da web.
• User: o ID do usuário do cliente que você está usando para login.
• PASSWORD: a senha do usuário.
• CacheClean: o sinalizador ou chave para controle de cache do navegador.
• SuccessCapacity: número esperado de linhas de base bem-sucedidas em uma sessão run2run.
• TotalExitCapacity: o valor para run2run para sair, no qual o número acumulado de linha de base executa de maneira semelhante nessa sessão run2run.
• BWEnable: o sinalizador ou chave para ativação da simulação de largura de banda.
• BWIN: a taxa de download via TCP/IP em uma execução de linha de base de ativação de largura de banda.
• BWOUT: a taxa de upload via TCP/IP em uma execução de linha de base de ativação de largura de banda.
• Comment: quaisquer comentários que você deseja adicionar à saída da linha de base em execução.

Cenário: execução de linha de base

Agora, vamos analisar o primeiro cenário: configuração, execução e resultados para uma execução de linha de base. A captura e o monitoramento das métricas de desempenho baseadas na página, das métricas de desempenho de uso de recursos e das métricas de desempenho de uso da rede são integrados e implementados no lado do driver, UIIE_Fiddler_Shot_1.0.exe. Portanto, não há a necessidade de configurar baseline.properties ao capturar essas métricas. Essas métricas sempre serão obtidas, desde que você acione uma execução de linha de base. A Figura 9 é uma captura de tela de uma amostra de execução de linha de base.

Use a pasta da amostra de linha de base com, por exemplo, o nome "Base_AllRequests_09-06-2011-07-42-59_N" onde está o seguinte diretório sys_metrics, contendo os quatro arquivos gerados automaticamente:

• cpu.tsv contém informações sobre o uso da cpu.
• ping.log registra as métricas de latência de rede.
• tracert.log contém as informações da rota de rastreamento de IP.
• baseline.properties é uma cópia das configurações para essa execução de linha de base.

Para os requisitos do Desafio nº 1, os diretórios RPC_getAvailableImages_SID, RPC_getInstances_SID e RPC_getAvailableStorage_SID são entregas de BVT, em termos das três solicitações RPC de destino. SID é o número do índice entre todas as solicitações nessa execução de linha de base.

O arquivo duration_cp.txt refere-se aos requisitos do Desafio nº 2. Ele contém o desempenho de página preciso para a página de painel de controle no IBM Cloud. O arquivo segue este formato, com três linhas:

Sid,233,ClientBeginRequest,9/6/2011 7:49:14 AM
Sid,285,ClientDoneResponse,9/6/2011 7:49:29 AM
Timepast,14.672

O arquivo _index.html e o diretório bruto contêm as métricas brutas para todas as solicitações durante a navegação de todo o website. Tudo que é possível obter, incluindo o desempenho, mas não se limitando a ele.

Os arquivos Screen_*_.jpg são as capturas de tela de cada página. Essa informação pode ser útil para ajudar a reproduzir os cenários, incluindo a solução de problemas para exceções, se houver necessidade.

Cenário: execução de linha de base com controle de funcionalidade: largura de banda e simulação

Para o próximo cenário, vamos analisar a configuração e execução de uma linha de base com controle de funcionalidade: controle e simulação de largura de banda. Você verá as linhas de código:

BWEnable=false
BWIN=400Kbit/s
BWOUT=384Kbit/s

Aqui, BWEnable é a chave de simulação ou controle de largura de banda. Se estiver definido como true, a linha de base permitirá a simulação de largura de banda. Quando definida como false, a funcionalidade é desativada.

O parâmetro BWIN é usado para definir a velocidade de download via TCP/IP.

O parâmetro BWOUT é usado para definir a velocidade de upload via TCP/IP.

Cenário: execução de linha de base com controle de funcionalidade: controle de cache

Há uma variação nesse cenário: configuração e execução de uma linha de base com controle de funcionalidade: controle de cache. O código para esse cenário é semelhante ao que se segue: CacheClean=false.

Aqui, CacheClean é o sinalizador para controlar o cache do navegador. Se estiver definido como true, o cache do navegador será limpo antes de cada linha de base. Quando definido como false, o navegador manterá o cache para cada execução de linha de base.

Cenário: diversas execuções de linha de base

No cenário final: configuração e execução de uma sessão run2run (diversas execuções de linha de base), você verá este código:

SuccessCapacity=7
TotalExitCapacity=14

As diversas execuções de linha de base são o mesmo que execuções repetidas de linha de base. Isso é basicamente exigido para o ajuste de desempenho, uma vez que os usuários desejam mais amostragens de repetições, enquanto uma linha de base não é suficiente.

Para realizar essa tarefa, é necessário usar um binário, independentemente da linha de base: seu nome é Manager.exe e seu código são seus parâmetros. SuccessCapacity é o valor de quantas execuções de linha de base bem-sucedidas são esperadas nessa ativação. TotalExitCapacity é o valor máximo, no qual a tarefa principal é forçada a sair quando a execução acumulada excede, independentemente do número esperado de sucessos nessa ativação.

A partir das métricas detalhadas na entrega de BVT, é possível detectar se a solicitação crítica está induzindo uma queda de desempenho, para que as iniciativas principais possam ser realizadas e uma tarefa de criação de perfil de solicitação seja executada.

A partir das métricas precisas de desempenho de página, é possível visualizar a tendência entre objetos iguais e detectar facilmente se há um problema de desempenho no nível da página.

Voltar para parte superior

Conclusão

Este artigo forneceu informações sobre como usar o desenvolvimento secundário no Fiddler para a engenharia de desempenho de interface com o usuário de aplicativos da web. Dois desafios e seus requisitos foram detalhados:

• A resolução do Desafio nº 1 fornece uma solução geral sobre como controlar e automatizar o Fiddler para interagir totalmente com qualquer solicitação da web de destino na qual você esteja interessado. Se você for um testador ou desenvolvedor, essas informações podem ajudá-lo a, pelo menos, criar uma entrega de automação de teste de conjunto de verificação para monitoramento de desempenho de interface com o usuário. E você não está limitado a isso. É possível criar outros tipos de entrada, pois você dominou o principal recurso — como localizar/controlar/entrar em qualquer solicitação da web que deseja ser o destino de seu aplicativo da web, por meio da codificação.
• A resolução do Desafio nº 2 fornece uma solução geral sobre como calcular o desempenho da resposta, conforme exigido especialmente para qualquer página de seu aplicativo da web. Com essa técnica, você está equipado com um recurso de computação de intervalos para obter o desempenho de resposta para qualquer página usando uma solicitação de início e término como os parâmetros.

Recursos

Aprender

• Para os recursos de desenvolvedor mencionados neste artigo:
  • Fiddler developer information
  • Fiddler developer cookbook
  • MSDN JScript.Net reference
  • AutoIT developer information
  
  
• Visite o site da Nuvem IBM para obter ofertas de nuvem atuais.
  
  
• Para saber mais sobre como realizar tarefas na nuvem IBM, visite estes recursos:
  • Faça upload e download de arquivos a partir de uma instância do Windows.
  • Instalar o servidor da web IIS no Windows 2008 R2.
  • Crie uma instância da nuvem IBM com a linha de comando do Linux.
  • Crie uma instância da nuvem IBM com a linha de comando do Windows.
  • Estenda a sua rede corporativa com a nuvem IBM.
  • Aplicativos de alta disponibilidade na nuvem IBM.
  • Parametrize imagens de nuvem para instâncias customizadas dinamicamente.
  • Abordagens focadas no Windows para fornecimento na nuvem IBM.
  • Implemente produtos usando o serviço de implementação rápida.
  • Integre a política de autenticação usando um proxy.
  • Configure o Linux Logical Volume Manager.
  • Implementar uma topologia complexa usando uma ferramenta de utilitário de implementação.
  • Forneça e configure uma instância que envolve uma VLAN pública e privada.
  • Proteger o acesso à IBM Cloud para dispositivos Android.
  
  
• Nos recursos para desenvolvedores de nuvem do developerWorks, descubra e compartilhe o conhecimento e a experiência dos desenvolvedores de aplicativos e serviços que estão desenvolvendo os seus projetos de implementação de nuvem.
  
  
• Descubra como acessar o IBM SmartCloud Enterprise.
  
  

Obter produtos e tecnologias

• Consulte as imagens do produto disponíveis para IBM SmartCloud Enterprise.
  
  

Discutir

• Faça parte de um grupo de computação em nuvem no developerWorks.
  
  
• Leia todos os ótimos blogs sobre nuvem no developerWorks.
  
  
• Faça parte da comunidade do developerWorks, uma rede profissional e conjunto de ferramentas comunitárias para conectar, compartilhar e colaborar.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• A estrutura de automação e o Fiddler
• Mais informações sobre o desafio
• A estrutura na nuvem
• Configurando a estrutura no IBM Cloud
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais