Conteúdo


Desenvolvendo aplicativos rapidamente (parte 1): uma visão geral dos microsserviços

Comments

[Roland Barcia (IBM Distinguished Engineer/CTO) e Kyle Brown (IBM Distinguished Engineer/CTO) colaboraram com o Rick nesta publicação. – Ed.]

Esta é a primeira parte de uma série em sete partes sobre como direcionar sua equipe para a melhor decisão de adoção de plataformas de nuvem em longo prazo.

Como adotar uma plataforma de nuvem envolve um compromisso significativo e implica na confirmação que vem de trabalhos anteriores em um ou mais produtos minimamente viáveis, o principal objetivo desta série é levá-lo à etapa de definir um projeto piloto adequado baseado em nuvem para sua equipe.

Esta é uma orientação sobre o que a série aborda:

Mobilidade e localização na experiência do usuário

Desde o final do ano passado, uma maioria global agora acessa a Internet principalmente por meio de um dispositivo móvel.

Muitas vezes, as implicações comerciais da tendência são discutidas com histórias que podem servir de lição sobre como a Uber e a Airbnb inovaram drasticamente seus respectivos mercados.

Empresas estabelecidas em todos os mercados estão cientes de que, em breve, serão oferecidas a seus clientes experiências de usuário inovadoras e que mudarão suas expectativas. Atualmente, inovar o relacionamento com os clientes rapidamente por meio de aplicativos é um lugar-comum do planejamento comercial.

Já não é mais suficiente concentrar-se principalmente nos serviços móveis: seus clientes podem tolerar por algum tempo uma excelente versão para dispositivos móveis de seu website existente, mas você precisa se perguntar por quanto tempo pode mantê-los esperando por recursos que ampliem o contexto de suas vidas monótonas. Se a implementação de suas ideias levar meses, como acontece frequentemente com um aplicativo monolítico que requer trabalho coordenado entre muitas equipes diferentes, sua inovação poderá facilmente tornar-se uma oferta semelhante à da concorrência. Um concorrente mais ágil estará sempre tentando passar à frente dos demais.

É desconfortavelmente óbvio que as equipes de desenvolvimento precisam acelerar o modo como entregam novos benefícios aos usuários. Como ninguém pode prever o comportamento dos usuários, até mesmo o programa de DevOps mais bem-sucedido precisa estar pronto para falhar no campo da experiência real do usuário. Projetar novamente, substituir e ampliar rapidamente partes da experiência do usuário são uma grande prioridade com base na análise de dados claros de uso.

Por isso, um modelo de microsserviços de desenvolvimento de aplicativos baseados em nuvem é tão poderoso. Ele permite que uma pequena equipe diversa controle todo o ciclo (conceito, desenvolvimento, implementação e monitoramento) de cada componente de um aplicativo, proporcionando a flexibilidade necessária para iterar de forma precisa uma parte da experiência do usuário com baixo desempenho, conforme refletido por dados coletados do monitoramento do que os usuários em si estão fazendo. O processo de DevOps torna-se uma interação dinâmica, praticamente uma conversa, com os usuários em campo.

Começando de onde você se encontra

Falhar rapidamente e iterar imediatamente: esses são os requisitos de DevOps para a entrega competitiva de aplicativos na era de serviços móveis. Eles pressupõem arquiteturas de aplicativos que desacoplam serviços um dos outros em um ciclo contínuo de desenvolvimento e entrega, ao mesmo tempo em que garantem interações de bom desempenho com os usuários.

Embora uma startup tenha a vantagem de construir novos aplicativos nativos da nuvem (usando uma abordagem de microsserviços juntamente com ferramentas e práticas de DevOps), muitas vezes, as empresas estabelecidas precisam começar refatorando um aplicativo monolítico existente.

Vamos analisar um exemplo específico.

Neste caso, um varejista on-line queria transformar um aplicativo monolítico em microsserviços para saber mais sobre os clientes e atualizar e inserir novos recursos rapidamente.

Como a navegação pelo catálogo on-line apresentava problemas comerciais que precisavam de solução urgente, a transformação do aplicativo geral começou por ela:

Tarefa piloto: determinar e implementar um melhor gerenciamento do catálogo

O aplicativo atual não ajudava os clientes a localizar dados dos produtos facilmente e impedia que a empresa expusesse dados para outros sites.

Como uma prova de conceito da abordagem de microsserviços, a equipe construiu um único microsserviço para o catálogo da empresa usando as etapas a seguir:

  • Estabelecer um novo modelo contínuo de desenvolvimento/integração para realizar o trabalho.
  • Importar dados para uma pesquisa elástica para obter novas maneiras de pesquisar seus dados e identificar novos dados.
  • Vincular o website existente à nova pesquisa.

Nesse ponto, o catálogo ainda estava integrado aos componentes de pedido existentes, que executavam a lógica de negócios principal e que eram muito complexos para serem divididos sem trabalho adicional. No entanto, com um piloto bem-sucedido, a equipe ficou convencida do valor dos microsserviços e decidiu expandir o escopo da transformação do aplicativo.

Tarefa 2: saber mais sobre o cliente

Para saber mais sobre o cliente, a equipe criou um microsserviço de conta decifrando como mudar o foco da empresa do inventário para os clientes.

Ao determinar que a experiência do cliente poderia ser enriquecida ao longo do tempo com base em análise de dados, marketing e dados cognitivos, a opção de usar um banco de dados não estruturado se tornou óbvia. Sendo assim, ela projetou um novo modelo de cliente e usou um banco de dados NOSQL (como Mongo DB ou o Cloudant) para gerenciar os dados não estruturados.

Tarefa 3: inovar a experiência do usuário

A equipe construiu um novo aplicativo móvel nativo e criou um novo front-end para acesso móvel e à Web. Embora o catálogo dependa do código de pedidos existente, a experiência geral do usuário foi visivelmente aprimorada.

Tarefa 4: atualizar o acesso ao microsserviço de pedidos

A equipe criou novas APIs de pedidos para dispositivos móveis e as integrou às transações existentes. A empresa decidiu criar um microsserviço adaptador para chamar o sistema de pedidos existente nas instalações. O adaptador também foi usado para integração a novos métodos e sistemas de pagamento.

Próxima tarefa: criar um novo recurso de leilão

Na nova arquitetura flexível, a equipe planeja incluir essa inovação em fases futuras.

Fazendo as perguntas certas

Ao pensar sobre o exemplo, considere estas perguntas:

  • O que seus clientes desejam agora e no futuro?
  • Os usuários de dispositivos móveis estão satisfeitos com as experiências que seus aplicativos estão fornecendo?
  • Em termos de entregar o que os usuários desejam, como os processos e práticas de DevOps de sua organização de TI estão ajudando ou atrapalhando?
  • Considerando o que está atrapalhando seus DevOps e supondo-se que você tenha um aplicativo monolítico que precisa ser modernizado, você sabe exatamente o que precisa fazer primeiro?
  • Quais experimentos com plataformas de nuvem os membros individuais de sua equipe de desenvolvimento de aplicativos devem estar realizando?
  • Qual é um bom projeto piloto a ser usado na avaliação de uma abordagem de microsserviços e de plataformas de nuvem para sua implementação?

A próxima publicação se aprofundará mais na criação da arquitetura de um aplicativo em um modelo de microsserviços.

O que fazer a partir daqui:

[Roland Barcia (IBM Distinguished Engineer/CTO) e Kyle Brown (IBM Distinguished Engineer/CTO) colaboraram com o Rick nesta publicação. – Ed.]

Rick Osowski
Senior Solution Architect


Recursos para download


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Big data e análise de dados
ArticleID=1051500
ArticleTitle=Desenvolvendo aplicativos rapidamente (parte 1): uma visão geral dos microsserviços
publish-date=07102017