Integre Aplicativos em um Dispositivo na Nuvem: 18 práticas

Melhores práticas para auxiliar a instalação de um aplicativo configurado adequadamente em um dispositivo na nuvem

Mais proprietários de aplicativos desejam que seus aplicativos sejam hospedados em um ambiente de nuvem, o que pode ser desafio se o aplicativo for complexo ou for estritamente dependente do ambiente de execução. Um cenário comum para a implementação de aplicativos na nuvem consiste em um software fora da nuvem que desejamos integrar com um software que já está sendo executado na nuvem — para fazer isso, há diversos recursos que precisam ser planejados (se você ainda está ajustando o aplicativo em questão) ou integrados (se o aplicativo já existe). Neste artigo, os autores oferecem 18 melhores práticas para assegurar que seus aplicativos possam ser integrados facilmente com outro produto em nuvem, que possam ser integrados com outro dispositivo em nuvem, ou que possam ser hospedados como um dispositivo independente na nuvem.

Sheetal Jharia, Staff Software Engineer, IBM

Sheetal Jharia é Staff Software Engineer (e IBM Cloud OS Development Lead) na IBM-ISL, e atualmente trabalha no desenvolvimento do IBM Systems Director VMControl, um produto crítico no portfólio em nuvem da IBM. Ela possui oito anos de experiência em TI e tem bacharelado e mestrado em Engenharia Elétrica e de Sistemas de Comunicação pela IIT Madras, na Índia.



Ashish Billore, Development Manager, IBM

Ashish Billore é IBM Cloud OS Development Manager nos IBM India Labs. Gerencia a equipe de desenvolvimento do IBM Systems Director VMControl e é responsável pelo desenvolvimento de componentes reutilizáveis para desenvolver infraestruturas em nuvem. Ele projeta e desenvolve aplicativos usando tecnologias como Java, Eclipse, OSGi e serviços da Web. Também contribui com diversas correções na plataforma de software livre Eclipse e apresentou artigos em conferências de QSE e tecnologia IBM. É bacharel em Engenharia Eletrônica e de Comunicação e é pós-graduado em Tecnologia da Informação.



10/Ago/2012

Este artigo fornece algumas melhores práticas para projetar e empacotar um aplicativo para consumo na nuvem para que ele possa ser:

  • Integrado com outro produto em nuvem para que o outro produto possa aproveitar seus recursos
  • Integrado com outro dispositivo já hospedado na nuvem.
  • Hospedado como um dispositivo independente na nuvem.

Se qualquer um desses cenários for de interesse, leia sobre algumas experiências que transformamos em melhores práticas para atingir um desses objetivos.

Em primeiro lugar, leio um pouco mais sobre esses cenários.

Três cenários

Novamente, os cenários que propomos envolvem a integração de um aplicativo em um produto em nuvem existente, a implementação de um aplicativo como parte de um pacote geral de dispositivos na nuvem, ou a integração do aplicativo em um dispositivo em nuvem existente.

Integre seu aplicativo com outro produto em nuvem

A necessidade é que você está aprimorando o aplicativo em nuvem existente com os recursos do seu aplicativo. O objetivo é fazer isso de forma integrada.

Com frequência, quando há uma necessidade de incluir novos recursos em um produto existente, isso envolve o design e o desenvolvimento da nova funcionalidade do zero; a alternativa é obter um produto disponível (neste caso, não habilitado para a nuvem) e integrar seus recursos com o produto em nuvem. Neste cenário, é necessário fazer com que seu aplicativo "conecte-se" adequadamente com o produto em nuvem existente.

Adicione seu aplicativo a outro dispositivo já hospedado na nuvem

Um dispositivo em nuvem consiste em software e aplicativos pré-instalados e pré-configurados; ele também pode ser usado às vezes como um servidor autocontido. Quando você está planejando adicionar mais um aplicativo a um pacote de dispositivos em nuvem existente para aprimorar sua funcionalidade, certifique-se de que seu aplicativo interaja corretamente tanto com os outros aplicativos dentro do pacote quando com os arquivos de configuração e as dependências de recursos do dispositivo.

Hospede seu aplicativo como um dispositivo em nuvem independente

Uma maneira de levar seu aplicativo à nuvem é dentro do seu próprio dispositivo em nuvem, principalmente se não for preciso integrá-lo com outro aplicativo em nuvem.

Antes de continuar, ajuda compreender o que queremos dizer com "dispositivo, "aplicativo" e "máquina virtual":

  • Dispositivo virtual: Uma solução de software pré-desenvolvida composta por uma ou mais máquinas virtuais que é empacotada, mantida, atualizada e gerenciada como uma unidade. Os desenvolvedores criam dispositivos virtuais desenvolvendo pilhas de aplicativos autocontidas e otimizadas que são customizadas para sua carga de trabalho e integradas com o sistema operacional escolhido; os dispositivos podem ser mais seguros e confiáveis que o software tradicional; um aplicativo pode ser disponibilizado simplesmente copiando um conjunto de arquivos e ligando o dispositivo virtual.
  • Aplicativo: Um aplicativo ativado para a nuvem; ele executa uma função ou uma variedade de funções. Ele é um componente da pilha de aplicativos dentro do dispositivo.
  • Máquina virtual: Um contêiner de software estritamente isolado criado para ser executado em plataformas virtualizadas. Ela contém quatro recursos virtualizados principais: CPU, RAM, armazenamento e rede.

Neste artigo, a palavra "produto" é usada com o sentido de "aplicativo" ou "dispositivo" dependendo do contexto.

Agora vamos observar as melhores práticas para ajudar a concretizar esses cenários.


Prática 1: Ofereça suporte à instalação silenciosa

A instalação que não exibe mensagens ou janelas durante seu andamento é chamada de instalação silenciosa. A instalação silenciosa não é uma instalação não assistida. Uma instalação não assistida é uma instalação que não requer a interação do usuário; uma instalação silenciosa (ou quieta) é uma instalação que não exibe nenhuma indicação de andamento.

É necessário oferecer suporte à instalação silenciosa em seu produto, juntamente com a instalação de GUI/interativa, para que o usuário possa escolher um dos dois métodos para instalar o produto. Para a instalação silenciosa, as entradas requeridas do usuário devem ser dadas em um arquivo de resposta que precisa ser editado apenas uma vez no começo, no início da instalação. Depois que a instalação tenha começado, os dados do usuário não devem ser necessários e o andamento/janela não deve ser exibido para o usuário.

Quando um aplicativo é integrado com outro aplicativo ou com um dispositivo, ele se torna parte de um único produto, e um instalador único é preferencial e é criado. Se seu produto não puder ser instalado silenciosamente, as informações são solicitadas ao usuário para o seu produto durante a instalação única, em um momento em que a equipe do dispositivo pode não desejar exibir/perguntar aos seus usuários. Isso não é conveniente para o usuário, e não é realmente necessário que ele conheça esses detalhes subjacentes do produto. Se a instalação silenciosa não estiver disponível, você perde a eficácia que ganhou, pois para o usuário, é como ter que instalar dois produtos diferentes.


Prática 2: Controle do uso de espaço em disco

Seus recursos de sistema devem ser regulados para baixo automaticamente para ajudar a controlar o uso de espaço em disco. Se as funções e processos no seu produto escreverem logs e dados de rastreio em um arquivo de saída (e quantos não fazem isso!), deve haver um processo para restringir esse fluxo de dados para evitar uma situação de falta de memória no servidor do dispositivo.

Crie um arquivo de propriedades que define o tamanho e o número de arquivos a serem gerados. Esses valores devem poder ser editados pelo administrador do sistema. Crie um processo para monitorar esses arquivos.

Se o tamanho ou número do arquivo de saída exceder o limite mencionado no arquivo de propriedades, uma das seguintes etapas pode ser executada:

  • Arquivos antigos podem ser excluídos e substituídos por novos.
  • O sysadmin pode ser alertado sobre a situação.
  • Novos dados podem parar de serem gravados no arquivo de log.

Também é necessário fornecer uma opção configurável e programática (durante a execução) para fazer o seguinte:

  • Redirecionar os logs para qualquer local desejado: em um ambiente de dispositivo, o sysadmin pode desejar ter todos os logs em um lugar pela facilidade de monitorar e coletar os logs. Tenha uma opção em seu produto para escolher o local onde os logs são armazenados.
  • Nomear e renomear os logs: juntamente com o local onde os logs devem ser mantidos, o seu nome de arquivo deve ser especificado pelo usuário de acordo com seu próprio padrão e conveniência. Para oferecer mais flexibilidade, a capacidade de renomear os arquivos de log também deve ser suportada, tendo em mente que seu produto pode fazer parte de um dispositivo grande e avançado no futuro.
  • Integre os logs a qualquer outro log fornecendo a opção de fluxos de saída de log: este recurso avançado significa ter a flexibilidade de integrar seus logs com outros logs, desde que o fluxo de saída adequado seja permitido pelo ambiente do dispositivo.

Prática 3: As configurações devem poder ser alteradas pela API ou CLI

Deve ser possível acessar e manipular todas as definições de configuração por meio de APIs ou uma interface da linha de comandos. Graças ao loose coupling, à leveza e à interoperabilidade oferecidas pelos serviços da Web REST, eles são muito populares e provavelmente são os mais comuns que você encontrará. Se qualquer processo requerer a alteração manual de algum arquivo de propriedades ou qualquer outro arquivo, deve ser feita uma adaptação para que essas alterações possam ser feitas pela CLI ou API.

Se a conclusão de uma definição ou configuração específica for requerida durante a instalação do dispositivo ou como parte do funcionamento geral do dispositivo, use essas CLIs ou APIS para fazer isso. O design deve ser tal que o dispositivo não precisa compreender o design interno do seu aplicativo para efetuar alterações nas configurações — deve ser possível simplesmente usar a CLI para fazê-lo.

Além disso, sempre que essas configurações ou definições forem alteradas, idealmente elas devem entrar em vigor durante a execução sem ter que reiniciar o aplicativo; dessa maneira, isso não irá atrapalhar o funcionamento de todo o dispositivo.


Prática 4: As informações de rastreio e log devem ser coletáveis via API/CLI

Quando um problema é relatado no produto, é importante que sejam coletados logs do produto para diagnosticá-lo completamente. Tenha mecanismos de linha de comando (ou qualquer outro) estabelecidos para executar operações de diagnóstico seletivas ou isoladas; operações que não afetarão o dispositivo inteiro. Isso inclui a capacidade de coletar informações de log/rastreio que possam ser usadas diretamente pelo sysadmin.


Prática 5: Suporte à alta disponibilidade é uma vantagem muito grande

A maioria dos dispositivos da IBM tenta oferecer suporte à alta disponibilidade; os clientes exigem isso. Se seu produto não oferecer suporte à alta disponibilidade, as capacidades de alta disponibilidade gerais do dispositivo se tornam menos eficazes. É uma boa ideia fazer um design com suporte à alta disponibilidade para seu produto no início do desenvolvimento, ou deixar espaço para fazer isso no futuro.


Prática 6: Forneça recursos de ciclo de vida

Qualquer processo, encadeamento ou daemon que esteja sendo executado como parte do seu aplicativo deve ter seu próprio recurso de ciclo de vida. Ele deve servir estados comuns como iniciar, suspenso e parar, além de ter uma provisão para controlar esses estados pelo próprio produto usando a CLI ou APIs.


Prática 7: Todas as configurações devem ser reconfiguráveis

Qualquer configuração assumida durante o pré-carregamento deve ter a opção de ser reconfigurada na criação do dispositivo. Ela também deve poder ser reconfigurada de acordo com a solicitação do cliente.

Seu produto pode funcionar sob certas configurações como um indivíduo — por exemplo, endereço IP, configurações de porta ou configurações de rede — mas quando ele é integrado com outro produto, esses parâmetros podem precisar de alterações devido ao ambiente de trabalho do cliente ou do requisito do produto geral. Qualquer configuração desse tipo deve poder ser reconfigurada e alterada durante a integração do produto, criação do dispositivo ou tempo de implementação do cliente.


Prática 8: Seja capaz de ativar e desativar o aplicativo no dispositivo

Este recurso é opcional, mas importante. É uma grande vantagem se seu aplicativo puder ser ativado ou desativado usando uma linha de comando, API ou GUI de tal forma que os arquivos relacionados ao produto ainda residam no disco, mas não consumam CPU ou recursos de memória do sistema em que está hospedado. Dessa forma, é possível integrar seu produto com outro produto e usá-lo quando necessário, simplesmente ligando-o ou desligando-o. Na nuvem, um dispositivo pode desligar certos serviços que ele fornece desativando o recurso correspondente, até mesmo enquanto continua a hospedar o produto inicial.


Prática 9: Seja capaz de aplicar correções no dispositivo

Se houver uma atualização ou correção disponível para seu produto, é necessário poder aplicá-la no ambiente integrado do dispositivo. Uma vez que seu produto esteja integrado com outro produto, sua equipe não precisará parar de trabalhar no aprimoramento dele: só é necessário definir uma correção de atualização na fase de design.

Já que seu aplicativo pode ser integrado com outros dispositivos em nuvem no futuro, ele precisa oferecer suporte à aplicação de correções dentro de um ambiente integrado.

Além disso, seu aplicativo deve ter atualizações e correções empacotadas para que elas possam ser incluídas ou integradas com outras atualizações do dispositivo. E ele deve ser capaz de passar pelo processo de atualização/correção sem ter que reiniciar o aplicativo.

A inclusão de uma provisão que permita que você desfaça a atualização ou correção aplicada também é útil, caso se descubra que a alteração é incompatível com o resto do dispositivo.


Prática 10: Comandos que devem funcionar em qualquer shell

Tente assegurar que todos os comandos não estejam restritos a um shell específico. Os comandos de CLI relacionados ao seu aplicativo (pelo menos os mais importantes) não devem ser restritos para funcionarem apenas em uma determinado shell. O dispositivo no qual o seu produto é integrado pode ser executado em um shell diferente daquele que você escolher. Nesse caso, não será possível executar os comandos de CLI, simplesmente porque o shell é diferente.


Prática 11: As funções de chave de licença devem ser acionadas quando a chave é instalada

Funções que são suportadas por uma chave de licença devem ser conectadas à GUI ou CLI do dispositivo comum e acionadas quando a chave de licença for instalada. Se qualquer uma das funções do seu aplicativo também oferecer suporte a chave de licença, esse recurso deve ser projetado adequadamente e integrado com a GUI comum do dispositivo desde o início, de forma que se a licença de qualquer componente do seu aplicativo for aplicada, a mesma deve ser detectada pela GUI comum que informa o usuário do dispositivo. Isso dá ao cliente uma ideia clara de quais licenças ele já está usando e quais ele precisa comprar ou se inscrever. Isso também ajuda o administrador em nuvem a manter as diversas licenças de forma eficiente. O aplicativo deve fornecer uma API para consultar informações de licenciamento e as aplicar ou atualizar sem reinicialização.


Prática 12: A atribuição de marca deve ser ativada

Este requisito é importante. Deve haver uma provisão em seu aplicativo para refazer a atribuição da sua marca (com nome de produto e número de versão) quando ele for incluído em outro produto ou dispositivo.

Um proprietário de dispositivo pode desejar alterar a marca das funções fornecidas pelo seu aplicativo para que elas sejam descritas com um nome que possa estar mais alinhado com o objetivo comum do dispositivo.

O número da versão também deve poder ser sobrescrito pelo dispositivo. Isso pode ser realizado de várias maneiras; uma dessas maneiras é ter um arquivo que descreve o nome do produto e o número da versão como uma variável constante que pode ser alterada pelo administrador do dispositivo (com as permissões apropriadas, naturalmente).


Prática 13: Tenha uma API que possa finalizar o programa de forma limpa

Faça provisões para uma parada imediata e limpa do aplicativo por meio de APIs. Quando há necessidade de sair de qualquer programa de modo abrupto no seu aplicativo (como em encerramentos críticos ou quando ele não está respondendo), deve haver APIs que possam finalizar de forma limpa os processos e encadeamentos dentro do seu produto sem corromper os dados ou afetar o dispositivo de forma adversa.


Prática 14: Disponibilize o backup e a restauração de dados

Crie recursos de backup e restauração de dados por meio de APIs em diversos formatos, como arquivos simples, um dump de banco de dados, etc. Desenvolva um recurso de linha de comando (uma GUI não é necessária) que possa fazer backup de todos os dados críticos relacionados ao seu aplicativo e restaurá-los quando isso for exigido.

Isso é útil toda vez que uma reinstalação do seu produto for feita no dispositivo e os dados mais antigos forem necessários para que seu produto seja capaz de executar os mesmos processos e funções que antes. Isso também é útil para aprimorar a resiliência ou alta disponibilidade do dispositivo.


Prática 15: Os aplicativos devem ser autocontidos, autossuficientes

Este é um requisito importante para que seu aplicativo possa ser incluído, excluído ou atualizado independentemente em um dispositivo. Ao tentar incluir, excluir ou atualizar seu aplicativo, é bom que o sysadmin não tenha que se debater com as dependências que o aplicativo possa ter com dados, definições, configurações ou ambientes externos.


Prática 16: A API deve poder importar e exportar dados para o aplicativo

É bom ter APIs prontas que possam consultar dados de dentro do seu aplicativo ou escrever dados do aplicativo em qualquer local. A mesma API também pode ser usada para gerenciar permissões do usuário consultando ou gravando dados. Isso facilita o processo de edição de qualquer recurso em seu aplicativo por parte da equipe do dispositivo, além de fornecer a ela mais modularidade.


Prática 17: Tenha uma maneira programática de gerenciar usuários

Tenha uma maneira programática de criar, excluir ou modificar usuários e funções e para restringir diversas opções ou funcionalidades. Para ter acesso seguro aos recursos do seu aplicativo (e também tornar as funções do dispositivo seguras), deve haver uma maneira programática de restringir e gerenciar diversos usuários e suas funções. Uma GUI deve ser uma interface inativa para criar usuários e funções e para gerenciar suas respectivas permissões.


Prática 18: Mantenha um mínimo de dependências externas estritas

Deve haver apenas loose coupling com qualquer versão ou fornecedor específico. Tente eliminar as dependências estritas de ferramentas externas a serem usadas em seu aplicativo.


Conclusão

Essas 18 práticas básicas devem ajudar você a pensar sobre alterações a serem feitas em qualquer dispositivo que você pretenda executar em uma nuvem, principalmente se você planeja adicioná-lo a um dispositivo em nuvem, não importa se ele já esteja sendo executado na nuvem ou não.

A próxima etapa consiste em ir mais a fundo em cada uma dessas práticas para ver algumas implementações reais delas, além de compreender as implicações que cada uma tem na criação de um aplicativo em nuvem eficiente, um aplicativo que possa ser facilmente integrado no ambiente em nuvem.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Cloud computing
ArticleID=829645
ArticleTitle=Integre Aplicativos em um Dispositivo na Nuvem: 18 práticas
publish-date=08102012