Um aplicativo virtual é uma entidade projetada pelo cliente que contém artefatos padrão de mercado (que podem ser implementados em componentes de middleware corporativos) e também um conjunto de políticas que controlam o comportamento do tempo de execução de um aplicativo quando ele é implementado.

O principal recurso do IBM® Workload Deployer 3.0 (a nova marca do WebSphere® CloudBurst) é a capacidade de o cliente focar em uma visualização lógica do aplicativo corporativo e permitir que o dispositivo escolha quais componentes de middleware deverão ser implementados e como configurá-los.

Este artigo demonstra como executar a construção de um padrão de aplicativo virtual, ou seja, como avaliar os requisitos do seu aplicativo corporativo e defini-los a fim de permitir o uso do recurso Virtual Application Builder no Workload Deployer.

O cenário da tarefa: construção do padrão de aplicativo virtual

Digamos que sua organização possui alguns aplicativos em produção e outros aplicativos em desenvolvimento. O processo típico da equipe de TI é calcular os requisitos de hardware e software e os requisitos de arquivo para cada aplicativo, seguido pelo processo entediante de preparação, instalação e configuração do hardware e do software. Em seguida, é a fase na qual você tenta configurar o monitoramento e o failover, além de configurar uma forma para coletar e monitorar logs. Você acaba escrevendo scripts customizados para cada aplicativo para facilitar da próxima vez e desenvolve uma grande coleção distinta de hardwares/softwares/aplicativos e scripts, entre outros.

Suponha que seja possível padronizar as necessidades dos aplicativos e que você possui espaço suficiente para aumentar rapidamente o número de aplicativos não só na produção, mas também em desenvolvimento e teste, você aceitaria? É aí que entra o Workload Deployer. Digamos que um aplicativo típico possui alguns códigos implementados em um servidor de aplicativo J2EE com alguns dados em um banco de dados relacional e existe uma maneira fácil e rápida de configurar a criação de log, o monitoramento e o failover, entre outros. Isso não seria muito conveniente? Sim, é exatamente isso que o Workload Deployer oferece no padrão de aplicativos da Web. Quando o Workload Deployer é implementado no seu datacenter, é possível implementar aplicativos e configurar o monitoramento, o ajuste de escala e a criação de log de forma padronizada e rápida.

Os artefatos típicos de um aplicativo virtual baseado em um padrão de aplicativo da Web incluem:

• Archive Corporativo (EAR) J2EE ou Web Application Archive (WAR) J2EE para implementação em um servidor de aplicativos.
• Script para a criação de esquemas/tabelas/linhas do banco de dados para inicialização de um banco de dados.
• Lista de usuários e grupos como um arquivo LDIF (Formato de Troca de Dados LDAP).

O Workload Deployer permite que você projete um aplicativo virtual, faça o upload desses artefatos, especifique políticas relacionadas à criação de log, monitoramento, ajuste de escala e implemente o aplicativo virtual na sua nuvem privada de forma rápida.

Voltar para parte superior

A forma rápida de criar um aplicativo virtual

Ou é possível usar o Virtual Application Builder no IBM Workload Deployer 3.0 para criar um aplicativo virtual.

Por exemplo, você cria um novo aplicativo virtual, arrasta e solta o componente do aplicativo corporativo e um componente do banco de dados e vincula os dois componentes. Você faz o upload de um Archive Web (WAR) ou um Archive Corporativo (EAR) baseado em JEE que contém seus artefatos de código e de um esquema do banco de dados que descreve a estrutura de tabela esperada pelo código. O IBM Workload Deployer reconhece esse aplicativo como algo que pode ser implementado usando o padrão de aplicativo da Web de forma otimizada, por isso o termo "aplicativo virtual".

Uma das principais diferenças entre o conceito de sistema virtual existente e o antigo Cloudburst WebSphere é que você não decide ou precisa saber exatamente quantas máquinas virtuais serão iniciadas nos hypervisors para construir o sistema em execução. Delegue essa responsabilidade para o Workload Deployer, que analisa os componentes, os links entre eles e as políticas associadas para calcular o melhor ajuste em termos de números de máquinas virtuais e o que realmente é executado em cada máquina virtual.

Com um sistema virtual, selecione quantos componentes de middleware forem necessários. Com aplicativos virtuais, você não precisa se preocupar com isso, pois você simplesmente especifica políticas para controlar itens como o aspecto de escalabilidade do seu aplicativo quando o aplicativo é projetado.

Voltar para parte superior

Construção do padrão de aplicativo virtual com o IWD

O que significa desenvolver um padrão de aplicativo virtual? Significa simplesmente avaliar os requisitos dos seus aplicativos corporativos e definir esses requisitos no IBM Workload Deployer. A parte difícil do processo é entender os requisitos dos seus aplicativos corporativos, mas quando isso é feito, a definição dos requisitos no Workload Deployer é tão simples quanto algumas operações de arrastar e soltar usando a ferramenta Virtual Application Builder.

Nesta seção, iremos explorar a ferramenta Virtual Application Builder e estudar os seguintes itens:

• Criação de um padrão de aplicativo virtual.
• Configuração dos componentes.
• Configuração dos links entre os componentes.

Histórico da ferramenta Virtual Application Builder

A ferramenta Virtual Application Builder é uma ferramenta gráfica integrada que permite o desenvolvimento gráfico de aplicativos virtuais. A ferramenta é composta de três seções primárias que trabalham juntas como um ambiente coeso para o desenvolvimento gráfico do seu aplicativo virtual:

• Ativos (ou paleta): Contém todos os componentes disponíveis que podem ser usados para desenvolver o seu aplicativo virtual. Os componentes são agrupados logicamente (por exemplo, o grupo Database Components contém todos os componentes de banco de dados).
• Tela: Esse é o local no qual o aplicativo virtual será desenvolvido graficamente.
• Folha de propriedades: Cada componente possui uma folha de propriedades. A folha de propriedades contém as propriedades de um determinado componente, link ou política que pode ser configurado.

A figura 1 mostra a interface com o usuário da ferramenta Virtual Application Builder.

Agora vamos aprender como desenvolver um padrão de aplicativo virtual.

Criação de um padrão de aplicativo virtual

Agora que você possui um entendimento básico da ferramenta Virtual Application Builder, chegou a hora de começar a criar um padrão de aplicativo virtual. Mas antes, é preciso entender que um aplicativo virtual é uma estrutura genérica que permite o desenvolvimento de diferentes tipos de padrões de carga de trabalho. O exemplo de padrão de aplicativo virtual neste artigo possui os seguintes requisitos:

• 1 dependência em um servidor de aplicativos para hospedar o aplicativo corporativo.
• 1 dependência em um banco de dados para persistir dados.
• 1 dependência em um registro do usuário para autenticação.

A primeira etapa do processo é acessar o painel Virtual Application Pattern localizado em Pattern > Virtual Applications. Essa visualização lista todos os padrões de aplicativo virtual que você está autorizado a visualizar. Clique no ícone de sinal de adição verde para exibir o painel de criação de aplicativo virtual. Esse painel permite a criação de um aplicativo virtual do zero ou início a partir de um modelo existente. Selecione Blank application e clique em Start Building para acessar a ferramenta Virtual Application Builder, conforme mostrado na figura 2.

O aplicativo corporativo de amostra possui três requisitos de middleware: servidor de aplicativos, banco de dados e registro do usuário. Para satisfazer esses requisitos, é necessário arrastar os componentes da paleta e soltá-los na tela, conforme mostrado na figura 3:

• O requisito de servidor de aplicativos será satisfeito pelo componente Enterprise Application (WebSphere Application Server) localizado abaixo da subseção Application Components.
• O requisito de banco de dados será satisfeito pelo componente Database (DB2®>) localizado abaixo da subseção Database Components.
• O requisito de registro do usuário será satisfeito pelo componente User Registry (Tivoli Directory Server) localizado abaixo da subseção User Registry Components.

Depois que todos os componentes dependentes forem colocados na tela, você estará pronto para prosseguir para a próxima etapa que irá estabelecer os links entre os componentes. Os links fazem muitas coisas e as funções mais importantes deles são:

• Abrir portas na máquina virtual para permitir o tráfego de entrada e saída da VM. Todas as portas ficam bloqueadas exceto quando são especificamente abertas usando um link.
• Definir propriedades adicionais.

Neste caso, o aplicativo possui um requisito para se comunicar com o banco de dados e com o registro do usuário, mas o registro do usuário não possui um requisito para se comunicar com o banco de dados e vice-versa. Para estabelecer um link, clique na bola azul na borda do componente de origem, mantenha o mouse pressionado e arraste o link para o componente de destino. A figura 4 mostra os dois links definidos para este cenário.

Nesse momento você estabeleceu a estrutura do aplicativo virtual. A próxima etapa, antes da implementação, é configurar as propriedades de cada componente e de cada link. Cada componente e cada link possui um conjunto exclusivo de propriedades (opcionais e obrigatórias) que são configuradas pelo usuário.

Não é difícil, pois basta definir uma regra sobre a ordem da configuração, mas recomendamos que inicie pela configuração do componente Enterprise Application. Você verá porque quando for configurar as propriedades do link.

Configuração dos componentes

1. Configure o componente Enterprise Application fazendo o upload do seu aplicativo corporativo (Figura 5).
   
   Figura 5. Configuração das propriedades do componente Enterprise Application
   
   
   
2. Configure o componente Database especificando o nome e o tamanho do banco de dados. Se seu aplicativo contemplar o preenchimento do banco de dados, faça o upload de um arquivo de esquema. Uma informação importante que merece ser mencionada é que o ciclo de vida do banco de dados segue o mesmo ciclo de vida do aplicativo virtual ao qual o banco de dados pertence: se o aplicativo virtual for finalizado, o banco de dados e todas as suas informações de estado também serão finalizados.
3. Configure o componente User Registry fazendo o upload do arquivo LDIF e especificando os filtros de usuário e de grupo.

Configuração dos links

Cada link representa um caminho de comunicação ou uma associação entre os componentes. Assim como ocorre com os componentes, as propriedades de cada link são exclusivas.

1. Configure o link do banco de dados entre os componentes Enterprise Application e Database. Clique no link para exibir suas propriedades. Além de abrir um canal de comunicação, esse link permite o mapeamento dos nomes JNDI da origem de dados do seu aplicativo corporativo. Um exemplo disso é mostrado na figura 6.
   
   Figura 6. Configuração do link do Enterprise Application ao Database
   
   
   

   Durante a implementação, o nome JNDI especificado será vinculado ao nome criado pelo WebSphere Application Server para oferecer suporte ao componente Database.

2. Configure um link entre os componentes Enterprise Application e User Registry. Esse link permite o mapeamento das funções definidas no seu aplicativo corporativo com usuários e grupos concretos definidos no componente User Registry. A Figura 7 mostra esse mapeamento.
   
   Figura 7. Configuração do link do Enterprise Application ao User Registry
   
   
   

   Caso não tenha notado, observe que a propriedade Resource reference of Data Source do componente Database e a propriedade Role Name do componente User Registry possuem opções pré-configuradas derivadas do seu aplicativo corporativo. Quando você inclui um link no seu aplicativo virtual, o Workload Deployer inspeciona os descritores de implementação do aplicativo virtual em busca de informações relevantes. Para referências JNDI, ele inspeciona o arquivo web.xml. Para funções de segurança, ele inspeciona o arquivo application.xml. Um exemplo disso pode ser visto na figura 8.

   
   
   Figura 8. Pontos de inspeção application.xml e web.xml
   
   
   
3. Salve seu aplicativo virtual (figura 9):
   
   Figura 9. Salvar seu aplicativo virtual
   
   
   

E isso é tudo! A seguir, abordaremos a implementação e o monitoramento do seu aplicativo virtual.

Voltar para parte superior

Implementação do seu aplicativo

Aqui é onde a diversão começa! Quando o aplicativo estiver modelado no Virtual Application Builder, você estará pronto para implementar o aplicativo vAppArticle. É muito fácil! Para implementar seu aplicativo virtual:

1. Clique em Patterns > Virtual Application e, em seguida, clique em vAppArticle. Um exemplo disso é mostrado na figura 10.
   
   Figura 10. Localização do aplicativo virtual
   
   
   
2. Na lateral direita do painel, clique em Deploy the virtual application into the cloud para iniciar a implementação, conforme mostrado na figura 11.
   
   Figura 11. Implementação do aplicativo virtual
   
   
   Clique para visualizar a imagem ampliada.
   
3. Após clicar em Deploy the virtual application into the cloud, você tem a opção de selecionar o grupo de nuvens, conforme mostrado na figura 12.
   
   Figura 12. Destino de implementação do aplicativo virtual
   
   
   

   No Workload Deployer, os aplicativos virtuais somente suportam grupos de nuvens como o destino de implementação. Eles não suportam perfis de ambiente como um destino de implementação.

   A caixa de diálogo na figura 12 também fornece a opção Advanced para configurar um acesso SSH seguro nas VMs implementadas. É possível fazer o upload da sua própria chave pública ou deixar o Workload Deployer gerar uma chave pública/privada para você. As VMs implementadas não permitem o acesso com usuário/senha. É necessário o acesso com uma chave privada/do usuário. Se o acesso SSH seguro não for configurado, não será possível acessar diretamente as VMs. Você poderá incluir ou alterar essa chave no console do aplicativo virtual depois que o aplicativo for implementado. Clique em OK.

4. O Workload Deployer inicia a implementação do aplicativo virtual. Pouco tempo depois, dependendo da sua configuração de rede, o aplicativo virtual é implementado e está pronto para ser usado.

   O Workload Deployer converte a implementação do aplicativo em ações específicas da infraestrutura. Ele inicia as implementações das VMs necessárias e configura o middleware e o aplicativo.

5. Para verificar o status da sua implementação, clique em Instances > Virtual Application e, em seguida, clique no aplicativo vAppArticle , conforme mostrado na figura 13.
   
   Figura 13. Instância do aplicativo virtual
   
   
   

   A implementação do aplicativo virtual oculta os detalhes específicos da infraestrutura e do middleware. Por exemplo, ela não requer a especificação do número de VMs ou a especificação da versão do WebSphere Application Server. Isso ajuda o desenvolvedor de aplicativos a focar no desenvolvimento do aplicativo e deixar os detalhes da infraestrutura e do middleware para o IBM Workload Deployer.

   A figura 14 mostra o status da implementação do aplicativo virtual.

   
   
   Figura 14. Status da implementação do aplicativo virtual
   
   
   Clique para visualizar a imagem ampliada.
   
   

   À medida que o aplicativo virtual é implementado, o VM Status muda do estado Launching para o estado Running. Quando a VM é totalmente instanciada, o agente específico do Workload Deployer que reside na VM inicia a ação para configurar a VM para a função que ela irá desempenhar nessa implementação do aplicativo.

   A função da VM indica a constituição do middleware que a VM específica terá. Por exemplo, a função de uma VM pode ser WebSphere Application Server, DB2 ou TDS. À medida que o agente do IBM Workload Deployer configura a VM para uma função específica, o Role Status da VM específica muda e, por fim, fica verde quando a função é totalmente configurada. Quando todas as funções estão corretamente configuradas e com status verde, o aplicativo virtual está pronto para ser acessado.

6. Quando o aplicativo virtual estiver implementado, ele poderá ser acessado diretamente clicando no hiperlink ENDPOINT da VM WAS, conforme mostrado na figura 15.
   
   Figura 15. Acesso ao seu aplicativo corporativo
   
   
   Clique para visualizar a imagem ampliada.
   
   

   A URL de terminal das VMs do banco de dados e do registro do usuário indica informações específicas de acesso a esse middleware. Por exemplo, a URL de terminal do banco de dados fornece informações de conexão para acesso ao banco de dados usando um cliente DB2.

Voltar para parte superior

Monitoramento do seu aplicativo

Depois que o aplicativo virtual for implementado, o IBM Workload Deployer permite monitorar e gerenciar a implementação do aplicativo virtual a partir do Virtual Application Console. Ele também fornece recursos para a execução de operações específicas nas máquinas virtuais implementadas e para a visualização de logs específicos do sistema operacional, do middleware e do agente do Workload Deployer a partir desse único painel centralizado.

Para acessar o Virtual Application Console, clique em Instances > Virtual Applications e, em seguida, clique em vAppArticle. No painel direito, clique em More details and advanced options conforme mostrado na figura 16. O Virtual Application Console abrirá em uma nova janela do navegador.

O Virtual Application Console possui quatro guias:

• Virtual Machine Monitoring: Essa visualização exibe as estatísticas em tempo real da máquina virtual no formato gráfico. Por exemplo, se o aplicativo implementado estiver consumindo muita CPU, essa visualização irá mostrar um alto uso da CPU para a máquina virtual específica.
• Middleware Monitoring: Essa visualização exibe as estatísticas de monitoramento do middleware em tempo real no formato gráfico. Por exemplo, durante os horários de pico do uso do aplicativo, é possível controlar a contagem de solicitações do seu aplicativo.
• Operation: Essa visualização fornece a capacidade de executar operações específicas do middleware nas VMs de destino. Por exemplo, você deseja atualizar seu aplicativo instalado com uma nova versão, mas não deseja finalizar toda a implementação. A guia Operation permite que o usuário atualize o aplicativo e execute outras operações necessárias.
• Logging: Essa visualização fornece uma interface com o usuário centralizada com uma coleção de logs específicos do sistema operacional, do middleware e do agente do Workload Deployer para cada VM. Ter todos os logs ao alcance é muito útil para depurar falhas de forma simultânea em subsistemas diferentes de VMs diferentes.

As capturas de tela de exemplo das guias Operation e Logging são mostradas nas figuras 17 e 18.

Voltar para parte superior

Bonificação: Configure seu próprio padrão de banco de dados

Apesar de não ser verdadeiro para todas as configurações, na maior parte dos casos o banco de dados é uma entidade separada do seu aplicativo, com um ciclo de vida próprio e gerenciado por uma equipe totalmente diferente com um conjunto exclusivo de qualificações. O Workload Deployer reconhece esse requisito e permite que o banco de dados seja criado e gerenciado como uma entidade separada. O seu aplicativo virtual pode então se conectar a esse banco de dados existente em vez de criar um banco de dados próprio.

Nesta seção, iremos configurar o padrão de banco de dados do Workload Deployer (chamado vAppDB) e aumentar o aplicativo virtual para usar o componente Existing Database a fim de utilizar o banco de dados que foi criado. O foco deste artigo é examinar os padrões do aplicativo da Web, não os padrões do banco de dados, mas este é um recurso de suporte importante do Workload Deployer. Na prática, este artigo demonstra como ativar um modelo de Banco de dados como serviço.

Configuração e implementação do padrão de banco de dados vAppDB

1. Navegue até Patterns > Database Patterns e clique no ícone de sinal de adição verde. O painel Database Pattern é exibido. Neste painel, é possível definir o nome e o tamanho do banco de dados e fazer o upload de qualquer arquivo de esquema de suporte, conforme mostrado na figura 19.
   
   Figura 19. Painel de criação Database Pattern
   
   
   
2. Depois de definir todas as propriedades do banco de dados, clique em Save e implemente o banco de dados, destacando-o e clicando em Deploy . Esse processo pode demorar um pouco dependendo da sua rede. Para monitorar o status da implementação do banco de dados, navegue até Instances > Databases e destaque o seu banco de dados para exibir suas informações. Após a conclusão da implementação, observe as informações dos campos Host, Port, User e Password, conforme mostrado na figura 20.
   
   Figura 20. Informações da instância do banco de dados (Host e Port)
   
   
   

   Essa informação é usada ao aumentar o aplicativo virtual com o componente Existing Database.

Aumento com o componente Existing Database

Geralmente é necessário se conectar ao middleware existente ou ao sistema corporativo legado na organização ou externamente. O Workload Deployer também aborda esse caso. Ele fornece a flexibilidade para acessar e continuar a explorar sistemas que estão fora da sua nuvem privada. O Workload Deployer possui componentes que permitem a conexão com os bancos de dados, registros do usuário, CICS e IMS existentes, entre outros.

Este cenário destaca essa capacidade ao aumentar o aplicativo virtual com o componente Existing Database. O único motivo para a escolha desse componente, em vez do componente Existing User Registry, é que ele apresenta o recurso de padrão de banco de dados. Novamente, é bom reforçar que existem outros recursos de padrão de banco de dados além dos mencionados, mas pelo menos agora você está ciente da existência desses recursos e pode investigá-los mais detalhadamente se tiver interesse neste recurso em particular.

1. Abra o seu aplicativo virtual na ferramenta Virtual Application Builder. Exclua o componente Database (essa ação também excluirá o link associado), inclua o componente Existing Database (DB2) e restabeleça o link, conforme mostrado na figura 21.
   
   Figura 21. Remoção e restauração do componente Database
   
   
   
2. Configure o componente Existing Database. Use as informações dos campos host, port, username e password anotadas durante as etapas de criação e implementação do vAppDB para configurar este componente.
3. Reconfigure a folha de propriedades do link visto que essas informações não existem para o link recém-criado. Um exemplo disso é mostrado na figura 22.
   
   Figura 22. Folha de propriedades do Existing Database
   
   
   

Além de salvar suas atualizações, você concluiu a configuração de um banco de dados que será gerenciado como uma entidade separada. O aplicativo virtual foi fortalecido para usar um componente Existing Database em vez de um componente Database.

Voltar para parte superior

Serviços compartilhados (cache e proxy)

Serviços compartilhados são serviços que são compartilhados por uma ou mais instâncias do aplicativo virtual. Atualmente, existem dois serviços compartilhados:

• Armazenamento em cache como serviço.
• Proxy como serviço.

A configuração e a inicialização dos serviços compartilhados é uma atividade de nível administrativo. Ela é feita uma vez e pode ser usada por todas as instâncias do aplicativo virtual. Você, como usuário, não precisará se preocupar em iniciar um serviço de armazenamento em cache e de proxy para a sua implementação específica.

Os dois principais benefícios do compartilhamento desses serviços são:

• Os recursos são mais bem utilizados. Não há necessidade de ter um proxy e um armazenamento em cache separado para cada implementação do arquivo virtual.
• Suporte de failover: os serviços compartilhados são implementados com diversas VMs, então se uma VM ficar indisponível, as outras assumem a carga de trabalho enquanto a VM com falha é recriada ou reiniciada.

Ativação dos serviços compartilhados (administrador)

1. Para iniciar os serviços compartilhados, faça login como um usuário com nível administrativo. Clique em Cloud > Shared Services conforme mostrado na figura 23.
   
   Figura 23. Ativação dos serviços compartilhados
   
   
   Clique para visualizar a imagem ampliada.
   
   
2. É possível visualizar 2 serviços compartilhados: CachingService e PROXY. Os serviços são pré-configurados. Clique no ícone de implementação de cada serviço.
3. Duas informações são necessárias para a implementação de cada serviço: o número de VMs e o grupo de nuvem de destino. E é isso. Clique em Deploy e pouco tempo depois seus serviços compartilhados estarão prontos para serem usados. A figura 24 mostra um exemplo da aparência do serviço de armazenamento em cache em execução.
   
   Figura 24. Implementação do serviço de cache compartilhado
   
   
   Clique para visualizar a imagem ampliada.
   
   

Ativação dos serviços compartilhados de padrão do aplicativo da Web (usuário)

Os serviços compartilhados de proxy e de armazenamento em cache foram projetados para serem usados por aplicativos virtuais em geral. O que é demonstrado aqui é o uso dos serviços compartilhados na forma do padrão de aplicativo da Web.

O padrão de aplicativo da Web usa o serviço de armazenamento em cache para armazenar informações da sessão HTTP. Ele usa persistência na memória e não persiste o banco de dados, mas isso não deve ser um problema devido ao suporte de failover fornecido pelo serviço de armazenamento em cache. Ative o padrão do aplicativo da Web para usar o serviço de cache incluindo a Scaling Policy e, em seguida, marcando a caixa de opção Enable session caching .

O padrão do aplicativo da Web usa o serviço de proxy para rotear solicitações para o seu aplicativo virtual. Ative o uso do serviço de proxy no padrão de aplicativo da Web incluindo a Scaling Policy e a Routing Policy no componente Enterprise Application.

Isso é tudo o que deve ser feito para configurar a funcionalidade básica. A figura 25 mostra um exemplo desses serviços ativados.

A próxima etapa é a última etapa para a implementação do seu aplicativo virtual com as novas configurações. A única diferença real que você notará é que agora o aplicativo é acessado usando o nome do host virtual. Nos bastidores, há muitas coisas acontecendo: o acesso ao aplicativo com o nome do host virtual é primeiramente roteado através do serviço de proxy. Além disso, as informações da sessão HTTP persistem no serviço de cache e não localmente na sua VM.

Uma última informação que merece ser mencionada e que completa este cenário, mas que está fora do escopo deste artigo: é necessário configurar os balanceadores de carga IP para rotear as solicitações de entrada do seu host virtual para os endereços IP da VM do serviço de proxy.

Voltar para parte superior

Conclusão

A criação, a implementação e o gerenciamento de bancos de dados e aplicativos virtuais são tarefas essenciais na computação em nuvem e o Workload Deployer é uma solução pronta para uso que realiza essas tarefas de forma fácil.

Recursos

Aprender

• No artigo Domine o poder da nuvem com o IBM Workload Deployer V3, aprenda sobre as melhorias centradas em aplicativos do IBM Workload Deployer em relação ao seu predecessor, o WebSphere CloudBurst.
  
  
• O divulgador do WebSphere Dustin Amrhein geralmente discute sobre o IBM Workload Deployer no seu blog A view from the clouds: Cloud computing for the WebSphere developer.
  
  
• O artigo de blog com três partes, IBM Workload Deployer: Application-centric cloud platform, fornece diversas informações sobre o IWD.
  
  
• Visite o site do IBM Workload Deployer. A biblioteca de documentos contém webcasts, Redbooks e White Papers sobre o Workload Deployer.
  
  
• 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 criando os seus projetos de implementação de nuvem.
  
  
• Nos Recursos do WebSphere, descubra e compartilhe conhecimentos e experiências sobre o IBM Workload Deployer.
  
  
• Próximas etapas: Descubra como acessar o IBM SmartCloud Enterprise.
  
  
• Para obter conteúdo e recursos para desenvolvedores técnicos em computação em nuvem, consulte Cloud computing: Fundamentals.
  
  
• Siga o developerWorks no Twitter.
  
  

Obter produtos e tecnologias

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

Discutir

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

Sobre os autores

Davanum Srinivas é engenheiro de software senior da equipe do IBM Workload Deployer. Na sua função atual, ele lidera uma equipe que trabalha nos aspectos de armazenamento do IBM Workload Deployer. Anteriormente, ele atuou como arquiteto de release da equipe do IBM Workload Deployer e participou do desenvolvimento do WebSphere Web Services.

Amit Acharya é engenheiro de software consultivo na organização IBM Cloud Initiatives Development. Ele lidera o planejamento estratégico de qualidade e a execução do produto no espaço de nuvem privada. Além disso, também ajudou na execução do programa beta de Plataforma como Serviço. Ele possui muita experiência no desenvolvimento de aplicativos corporativos e em soluções de middleware com foco orientado ao cliente. Ele é autor do IBM Redbooks na área de arquitetura orientada a serviços e contribuiu ativamente para o portfólio de patentes IBM. Possui formação em engenharia elétrica e de computação pela Universidade Purdue.

Brian Stelzer é engenheiro de software e chefe da equipe do IBM Workload Deployer. Em sua posição atual, ele fornece treinamento e soluções de arquitetura para ambientes baseados em nuvem, com foco em IBM Workload Deployer, WebSphere Application Server e tecnologias com base em VMware. Anteriormente, ele projetou soluções de migração para o WebSphere Application Server e o WebSphere Application Server Community Edition.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• O cenário da tarefa: construção do padrão de aplicativo virtual
• A forma rápida de criar um aplicativo virtual
• Construção do padrão de aplicativo virtual com o IWD
• Implementação do seu aplicativo
• Monitoramento do seu aplicativo
• Bonificação: Configure seu próprio padrão de banco de dados
• Serviços compartilhados (cache e proxy)
• Conclusão
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

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

---

Saiba mais