O valor de padrões em desenvolvimento de software, de arquitetura e de operações tem sido registrado extensivamente ao longo dos anos. Os exemplos incluem Discussão de padrão de arquitetura em TOGAF, do The Open Group, e a discussão sobre Padrões em todos os níveis, no contexto de padrões de tempo de execução. Neste artigo, você aprenderá sobre um novo tipo de padrões chamado receitas. É possível usar receitas para avaliar aplicativos candidatos à migração ou à implementação na nuvem. Esses aplicativos podem ser executados de forma exclusiva na nuvem ou em um modelo híbrido, em que alguns componentes são executados em outras plataformas de nuvem ou em ambientes tradicionais. As receitas simplificam o tempo e o esforço para analisar seus aplicativos e determinar como melhor implementar o aplicativo em suas plataformas de nuvem IaaS ou PaaS. Usando os três blocos de construção básicos descritos abaixo, é possível avaliar cada aplicativo para definir o que é necessário e como melhor alinhar seu aplicativo a sistemas e serviços em nuvem. Além do mais, é possível estender os padrões básicos com duas camadas de serviços adicionais: serviços do ecossistema específico da receita e serviços do ecossistema geral

Receita

O padrão principal, ou receita, fornece insights sobre como construir seu aplicativo ou componente a partir de um conjunto de tempos de execução e serviços. Não é texto padrão (isso sugere uma combinação específica de serviços específicos), mas sim um conjunto de instruções sobre como combinar tipos de serviços gerais. Um modelo é mais como uma pizza congelada ou copo de macarrão instantâneo embalado do que uma receita. Três tipos gerais de receitas são explorados neste artigo, cada um dos quais tem subtipos específicos. Você aprenderá os diferentes tipos de receitas e os tipos de serviços que suportam cada tipo de receita. Primeiro, você precisa conhecer três conceitos relacionados aos tipos de sistemas que podem ser construídos na nuvem. Você verá por que isso é importante quando a primeira receita for definida. Os tipos de sistemas são:

Sistemas de registro – Um sistema de registro é aquele no qual você registra informações sobre objetos ou eventos do mundo real. Se em seu aplicativo você tiver dados complexos sobre pessoas, eventos e coisas em um armazenamento persistente, então, você estará provavelmente construindo um sistema de registro.
Sistemas de engajamento – Um sistema de engajamento é aquele no qual você interage principalmente com pessoas em vez de outros sistemas. Se seu aplicativo for projetado para acessar dados existentes ou no máximo permitir mudanças simples em dados existentes, você provavelmente está construindo um sistema de engajamento.
Sistemas de insight – Um sistema de insight é provavelmente o mais difícil de entender dos tipos de sistemas. Se seu sistema existir para responder perguntas sobre o passado ou para tentar prever o futuro de alguma maneira, então, provavelmente, você está construindo um sistema de insight.

Isso é importante porque cada um desses três tipos de sistemas corresponde a uma combinação específica de tempos de execuções e serviços que são exclusivos desse tipo. Ou seja, essas são nossas primeiras receitas. Mas uma receita consiste em um conjunto principal de ingredientes. Por exemplo, um sistema de registro geralmente requer um banco de dados para atender seus requisitos funcionais específicos e não funcionais. A variação pode ser feita nos ingredientes adicionais que você ajusta a um problema específico que ocorrer, de forma bem semelhante a uma receita culinária que o instrui a "temperar a gosto". Na verdade, a receita mais simples é para um sistema de registro. Após revisar dezenas de exemplos de sistemas de registro que foram documentados no developerWorks ou que construímos pelo IBM® Bluemix Garage, chegamos a conclusão que a receita é: Sistema de registro = Tempo de execução + Origem de dados + (Gateway) opcional [caption id="attachment_113811" align="aligncenter" width="620"]

Figura 1. Exemplos de origens de dados[/caption]

O que tudo isso significa?

Um tempo de execução é a primeira peça do IBM® Bluemix, o que pode significar um Cloud Foundry Instant Runtime (como o Liberty Buildpack), um Docker Container ou uma VM que possa hospedar seu código do aplicativo. Uma origem de dados é o próximo componente. Poderia ser qualquer uma das opções de SQL no Bluemix (como o DB2 as a Service ou o PostgreSQL by Compose Service) ou qualquer uma das opções NoSQL, como o IBM® Cloudant® ou o Redis by Compose. O gateway é a parte que pode ser mais difícil de entender. Alguns (mas não todos) sistemas de registro dependem de diversos tipos de origens de dados, alguns dos quais podem estar atrás de firewalls corporativos. Então, um gateway poderia incluir um serviço como Gerenciamento de API ou até mesmo o gateway seguro para obter acesso àquelas origens de dados. De forma semelhante, os sistemas de registro também podem ter gateways de front-end. Se seu tempo de execução for construído como um serviço assíncrono, você precisará de um gateway como o serviço Message Hub ou IBM® MQLight para permitir que outros sistemas se comuniquem com ele. Um sistema de insight compartilha uma coisa com um sistema de registro, uma origem de dados. A origem de dados é frequentemente o único ponto em comum. Veja, a seguir, a receita para um sistema de insight:

Sistema de insight = Origem de dados + (opcional) Visualização + (opcional) Ferramenta de análise de dados + (opcional) Movimentação de dados

Vale a pena examinar os dois novos tipos de serviços introduzidos. Uma ferramenta de análise de dados é um serviço que ajuda a executar análise especializada de seus dados. Exemplos de uma ferramenta de análise de dados incluem o IBM® BigInsights® for Apache Hadoop, o Apache Spark ou até mesmo o IBM® DashDB™. Uma visualização é um tipo de serviço que ajuda seu usuário a ver os resultados de sua análise. Poderia ser em formato de texto, como um relatório do Embeddable Reports. Ou poderia ser em uma ferramenta visual, como o IOT Real-Time Insights. Por fim, você poderá precisar mover dados para dentro e para fora de diferentes origens de dados em um sistema de insight, esse é o trabalho de uma ferramenta de movimentação de dados como o IBM® DataWorks. Com um sistema de engajamento, você sempre terá um tempo de execução e, frequentemente, um gateway, mas poderá ter uma origem de dados, ou não. Se seu sistema de engajamento estiver armazenando dados em cache localmente, você poderá ter uma origem de dados para agir como um cache, mas você não deverá estar armazenando qualquer dado de forma permanente em um sistema de engajamento - esse é o trabalho de um sistema de registro. Portanto, a receita mais simples para o sistema de engajamento é:

Sistema de engajamento = Tempo de execução + [Origem de dados como cache] + [Gateway]

Neste exemplo, parece que tudo é opcional! Isso não ajuda muito. A real diferenciação aparece na próxima camada, quando você considerar as receitas mais específicas que usam serviços do ecossistema específico da receita. [caption id="attachment_113812" align="aligncenter" width="620"]

Figura 2. Tipos de receitas lógicas[/caption]

Ecossistema específico da receita

A próxima camada é composta por serviços no ecossistema específico da receita que inclui os sistemas ou serviços usados por uma ou mais receitas específicas para que funcionem plenamente em um ambiente de teste ou de produção, além da receita base. As receitas são fornecidas frequentemente em subtipos específicos que ajudam a decidir quais serviços principais e serviços do ecossistema específico da receita são necessários: Os sistemas de interação são divididos em sistemas da web de interação e sistemas móveis de interação:

Um sistema da web de interação possivelmente usaria serviços do ecossistema específico da receita, como armazenamento em cache da sessão e conexão única;
Um sistema móvel de interação poderia usar serviços específicos da receita, como notificação por push, garantia de qualidade móvel e segurança de dispositivo móvel.

Também vemos frequentemente sistemas de registro de Internet of Things que enviam e recebem mensagens por meio do gateway IOT. Frequentemente, isso é combinado a um sistema de engajamento que permite aos usuários interagir com as informações armazenadas na origem de dados por esse sistema de registro. Por fim, os sistemas de insight podem ser divididos em sistemas de insight históricos e sistemas de insight em tempo real

Os sistemas de insight históricos usam técnicas como dinamização de tabela, disponível no DashDB;
Os sistemas de insight em tempo real podem usar técnicas como análise de dados de fluxo ou Apache Spark.

Os sistemas ou serviços nessa camada podem ser divididos em dois grupos. Eles incluem sistemas ou serviços para:

Possibilitar sucesso operacional. Isso inclui serviços como monitoramento, balanceamento de carga e armazenamento em cache. Por exemplo, ao selecionar serviços de nuvem para uma receita de system of interaction (SOI) da web, você poderá descobrir que armazenamento em cache, balanceamento de carga ou ajuste de escala automático é necessário;
Interaja com o aplicativo para suportar requisitos funcionais. operações. As interações podem usar diversos protocolos (SOAP, REST, JDBC etc). A disponibilidade desses sistemas ou serviços varia por ambiente (Dev, QA, Prod) e, em alguns casos, eles são representados por APIs publicadas ou serviços virtuais.

Ecossistema geral

O tipo de serviços final é composto por serviços do ecossistema geral que suporta o ciclo de vida de desenvolvimento, entrega e liberação do software. Para organizações que estão implementando em ambientes híbridos, tradicionais ou de mainframe, esse ecossistema fornece os sistemas e os serviços para diversos ambientes nos ciclos de vida de entrega do aplicativo. Por exemplo, se você implementasse seu aplicativo da web no Bluemix público, então selecionaria o BlazeMeter ou o LoadImpact para testar o desempenho do aplicativo. E se você estiver desenvolvendo um aplicativo nativo em nuvem para implementação no Bluemix público, opte por usar o pipeline de entrega do DevOps Services para construir e implementar seu aplicativo em diferentes estágios. Por outro lado, se você desenvolver aplicativos com fluxos de trabalho híbridos implementados em ambientes tradicionais nas instalações e em uma ou mais plataformas de nuvem (IaaS, PaaS), use o UrbanCode Deploy para implementações de aplicativos e fornecimento de pilha integral nas plataformas de nuvem.

Entender os recursos disponíveis

Ao usar essa abordagem, você pode desejar qualificar seu aplicativo e padrão determinando se seu aplicativo está pronto para a nuvem. Uma boa estrutura a a seguir nessa avaliação é "Nove principais regras para aplicativos de nuvem" (developerWorks, abril de 2014). Você também deve ter um entendimento de seu provedor de nuvem ou dos recursos da plataforma tradicional, principalmente dos serviços fornecidos que espera alavancar. Muitos provedores têm websites, como os serviços de nuvem da IBM. Entenda os recursos que você tem para integrar suas plataformas se tiver a intenção de operar alguns de seus aplicativos entre plataformas em um modelo híbrido. Um bom exemplo é integração de APIs e nuvem híbrida. Avalie os sistemas ou serviços oferecidos pelo provedor de nuvem, entre provedores ou hospedados nas instalações. Por exemplo, o blog "UrbanCode with Bluemix for Hybrid Cloud Deployment" demonstra um recurso comum entre pipelines de entrega para plataformas híbridas e tradicionais.

Desenvolvendo uma receita

O melhor é aplicar a receita a cada aplicativo e, em seguida, procurar ecossistemas repetidos para categorizar seus aplicativos em padrões comuns. Isso deve ser executado de forma iterativa e deve ser introduzido aos novos requisitos ou serviços somente quando necessário.

Etapa 1: desenvolver sua receita. Experimente e determine quais são os tempos de execução e serviços certos para sua receita principal;
Etapa 2: seu aplicativo precisa de serviços do ecossistema da receita para implementar funcionalidade específica da receita ou ou atender NFRs do núcleo de sua receita? Nesse caso, inclua serviços do ecossistema específico da receita;
Etapa 3: seu aplicativo precisa de serviços do ecossistema para atender os NFRs de sua solução nas áreas de sustentabilidade, desempenho, confiabilidade ou segurança? Nesse caso, inclua serviços do ecossistema geral, tais como um ou mais DevOps Services ou o Security Services.

A figura abaixo mostra um exemplo de uma receita do Bluemix. Ela inclui uma receita principal do Java Runtime, do Cloudant DB, do Secure Gateway e do CUPS para conectividade à origem de dados adicional nas instalações. Também inclui ecossistemas específicos da receita e gerais na forma de cadeia da ferramenta aberta DevOps, análise de dados de ajuste de escala automático e hub de mensagens. [caption id="attachment_113813" align="aligncenter" width="620"]

Figura 3. Receita de exemplo do Bluemix[/caption]

Conclusão

Neste artigo, você aprendeu sobre padrões de arquitetura que podem ser usados para planejar a migração de seus aplicativos nas plataformas de nuvem IaaS ou PaaS. A abordagem em camadas com três etapas fornece um meio para definir seus padrões, principal e ecossistema, que permitirão definir topologias de tempo de execução e serviços de nuvem necessários para seus aplicativos. Usando essa abordagem, você reduzirá seu tempo e esforço para planejar sua migração e reduzir a complexidade ao mover diversos aplicativos com padrões de receita similares.

Recursos para download

PDF desse conteúdo

*** Escrito em parceria com Paul Bahrs.

Kyle Brown