Nossos Cursos

DDD, (micro)serviços e evolução de legado

Ontem, dia 02 de Outubro de 2018, participei de uma live com com o pessoal da comunidade DevelopersBr. Na ocasião falamos sobre evolução de Software, DDD e (micros)serviços. Você pode conferir o vídeo do evento aqui:

API Gateway Pattern, Backend for Front-end (BFF) – Parte 2

Introdução

Desenvolver plataformas web/mobile, que foram implementadas usando um desenho Arquitetural baseado em Serviços, está se tornando um Mantra dentro das empresas ao redor do mundo. Inicio, aqui, com um sugestão: Tenha visão analítica e corporativa, pois você terá que trabalhar sobre algumas desvantagens, diante de suas escolhas. Você e sua empresa estão prontos para assumir e colher os resultados sobre as suas escolhas?

As Empresas, estão buscando trabalhar de diversas formas, em busca de entregar a implementação e entrega (muitas vezes, “By the Book”) de Serviços/Microsserviços. Devido essa corrida, incessante, para trabalhar sobre esse tipo de estrutura em plataformas web, as empresas estão dividindo suas equipes em divisões de times; onde  há equipes de desenvolvimento especializadas em áreas específicas de negócio, desenvolvendo diversos serviços e APIs, criando um ecossistema computacional complexo, como o cenário apresentado na Parte 1 desta série sobre API Gateway.

Solução utilizando API GatewayUntitled Diagram-API w_ API Gateway

Como pode ser observado no diagrama acima, um API Gateway tem a responsabilidade de rotear, compor/agregar, traduzir protocolo, integrar servidores de segurança, cache de dados, monitorar outras funções inerentes dessa plataforma. Toda requisição dos clientes, tem que passar, a partir de agora, por uma espécie de “Portão” ou API Gateway.

A responsabilidade de um API Gateway, não é apenas rotear a requisição feita por um cliente para um determinado serviço/microsserviço e retornar o Downstream Response de volta para o cliente por meio de um Upstream Response. Existem outras funcionalidades que estão disponíveis nas plataformas/frameworks que implementam esse padrão.

Utilizar um API Gateway, cria a capacidade em uma arquitetura baseada em serviços, a aplicar composição/agregação de dados, através de requisições feitas aos serviços disponíveis no backend. Isso possibilita consumir diversos serviços do seu backend, os quais retornarão dados e estes dados serão enviados como resposta ao API Gateway.

O conjunto de informações retornadas por esses serviços de backend,  passarão por um processo de composição/agregação, ou seja, um processo que irá compor essa estrutura de dados, em uma estrutura final, bem definida e padronizada, como resposta aos clientes requisitantes deste conjunto de informação. Além disso, um API Gateway pode traduzir requisições que utilizam protocolos diferentes, como: HTTP, Web Socket, SOAP, protocolos internos do ecossistema e que não são tão amigáveis para uma UI Web.

Um API Gateway pode, ainda, fornecer uma camada de roteamento customizada para cada um dos diversos tipos de clientes (Desktop, Web, Mobile) candidatos a consumir serviços de backend.

API Gateway: Benefícios e Preocupações

Benefícios

Como se pode observar, o maior benefício do uso de um API Gateway, dentro da sua Arquitetura de Serviços e infraestrutura, é a capacidade de assumir o encapsulamento de estruturas de dados internas da aplicação (estruturas de dados internas dos diversos serviços de backend, que são consumidos pelo API Gateway), ao invés dos clientes consumirem os diversos serviços, consumindo serviço a serviço (aumento do round-trip). Com isso, essa padrão favorece os clientes, tendo um único ponto de contato com com os serviços de backend, ou seja, apenas acessam o API Gateway.

Por ser o único ponto de entrada e saída de dados da infraestrutura de serviços, um API Gateway reduz o número de round trips (número de idas a infraestrutura de serviços) entre os clientes e a infraestrutura que expõe os serviços. Isso, agrega um aspecto importante que é a simplificação de código do lado cliente.

Abaixo, seguem outros benefícios:

  • Escalabilidade;
  • Uso de Programação Reativa;
  • Descoberta de Serviços (Service Discovery);
  • Chamada de Serviços (Service Invocation);
  • Gerenciamento de falhas eventuais.

Desvantagens

Como toda escolha traz uma consequência, o famoso “trade-off”, implementar um API Gateway nos leva a outro nível de desenvolvimento, entrega e gestão de deployment de serviços. Existe o risco de um API Gateway tornar-se um gargalo (bottleneck) – Mas existem técnicas para mitigar eventuais de baixa performance.

Os desenvolvedores são os responsáveis por atualizar um API Gateway, em função de expor os endpoints dos serviços que serão mapeados e roteados – tem que ter bastante atenção e responsabilidade sobre a atualização dessa infraestrutura. Esse tipo de arquitetura de solução, exige que se tenha um processo de devops amadurecido, pois a gestão de atualização desse tipo de infraestrutura, deve acontecer de forma fácil e que possibilite executar um  rollback sem muita dor de cabeça e, também, seja o mais leve possível, de forma a gerar o mínimo de impacto, ou até nenhum impacto, aos clientes que estão consumindo os serviços.

Apesar das desvantagens, perceba que (na minha visão), as dores de NÃO se ter um API Gateway se potencializa a medida que a quantidade de serviços/microsserviços cresce e estes, são disponibilizados em sua infraestrutura de backend que, em aplicações sérias de mercado, faz muito sentido o uso do API Gateway Pattern.

Algumas ferramentas de mercado

Atenção (*)

As ferramentas, marcadas com um asterisco e citadas na seção acima, pertencem à categoria API Managemer, e, portanto, possuem um API Gateway e elementos adicionais como: gestão sobre publicação de APIs, portal do desenvolvedor, dentre outras. API Manager não é tema deste artigo, entretanto, gostaria de salientar que um API Management, pode atuar como um API Gateway, embora o contrário não é verdade. Isso agora fica como assunto para uma nova série no futuro.

Em um próximo artigo, vou mostrar como podemos implementar uma API Gateway, utilizando um framework open-source e concretizar a solução apresentada no post de hoje.

Conclusão

Tendo em vista os aspectos observados neste post, implementar uma Arquitetura baseada em serviços, exige uma série de conhecimentos de engenharia de software e conhecimento para analisar a capacidade computacional, o que nos leva à outros níveis de infraestrutura, monitoramento, gestão de deployment de serviços e aumenta a quantidade de round trips dentro da estrutura de uma plataforma web. O API Gateway Pattern, tem a capacidade de melhorar a comunicação e padronização entre o cliente e o servidor de serviços de backend; implementando o conceito de composição/agregação de serviço, entregando resiliência por meio de recursos que trabalham tolerância a falhas, torna-se o ponto central de monitoramento, autenticação/autorização, ou seja, existem muitos benefícios alcançados quando se faz uso desse padrão, o que torna acietável os pontos de desvantagens e, os conhecendo antecipadamente, pode-se realizar o planejamento adequado para controlá-los.

Referências:

O que achou? Deixe um comentário e compartilhe sua experiência em seus projetos!

Está interessado em desenvolver Arquitetura de Serviço em seus projetos ou melhorar o desenho de sua arquitetura?

A Emerging Code pode te ajudar. Entre em contato conosco, teremos prazer em realizar mentoria em seus projetos!

API Gateway Pattern, Backend for Front-end (BFF) – Parte 1

Introdução

Estamos vivendo em uma Era Digital onde muitas empresas (isso inclui, também, clientes onde atuei), estão buscando aplicar o estilo arquitetural de Microsserviços, visando alavancar a estratégia de negócio. Mas a Hype NÃO vai resolver os seus problemas, sem conhecer e entender como aplicar técnicas de engenharia de software e conceitos computacionais!

Foi observado através dos cursos que a emerging code tem ministrado e, também, através da realização de consultorias de arquitetura de software e soluções, que existe um cenário um tanto descompassado do ponto de vista da aplicação das técnicas de engenharia de software, com pouco conhecimento relacionados a quais Atributos de Qualidade devem ser (como engenheiros de software temos esse dever de conhecê-los) analisados e levados em consideração em projeto de software e quais premissas computacionais não podem ser ignoradas em nenhuma das fases do desenvolvimento de um projeto.

Abaixo é apresentado um diagrama da ISO/IEC 25010, onde são listados Atributos de Qualidade a serem levados em consideração, quando se está modelando um projeto de software:

Quality Characterisctics of ISO 25010

Ainda relacionado aos atributos de qualidade citados acima, é importante levar em consideração o Teorema CAP, muito relevante do ponto de vista de entender os Trade-Offs que temos que lidar, devido as escolhas necessárias para resolver um problema do negócio da companhia.

Apesar de toda a carência encontrada relacionadas ao entendimento e conhecimento das técnicas de engenharia de software, observada nos projetos que tenho particpado; os cenários que os clientes que atendo atuam, me deu a oportunidade de entender as razões pelas quais as equipes de desenvolvimento dessas empresas, estão em busca do Santo Graal da Indústria de Software: Microsserviços!

Com o mercado de T.I aquecido e a concorrência, cada vez mais se aperfeiçoando e se fortalecendo com o advento de novos termos, para explicar velhos conceitos, com a diversidade de ferramentas e a necessidade de escalar o negócio de uma companhia, leva à uma tomada de decisão estratégica urgente, e o termo Microsserviços, traduz toda essa necessidade de alta escalabilidade, tanto em termos técnicos e tecnológicos, quanto de negócio. Implementar Microsserviços, hoje, é quase um Mantra dentro das empresas, e em quase todos os projetos de software que tenho tido contato, nos últimos 3 anos.

Implementar o conceito de serviços e microsserviços em um projeto, nos leva a uma série de benefícios (fáceis de serem vendidos e comprados), mas também temos um aumento das preocupações (Dificeis de serem faladas, mas necessárias para saber tomas a decisão certa para o projeto), uma delas recai sobre a Composição dos Serviços! E a partir deste ponto, uma outra chuva de questionamentos começam a aparecer dentro do time de engenheiros, os quais terão a responsabilidade de encontrar uma solução para resolver essa necessidade técnica e que afeta, diretamente, o negócio.

SOA Pattern: Composite UI Front-end

Desenvolver a capacidade de Composição de Serviços, nos exige o conhecimento de técnicas e padrões, os quais podemos encontrar nos Padrões SOA e, aplicar como solução de um sistema computacional, uma delas é a UI Composition ou Composite UI Front-end.

Problema

Vamos tentar imaginar uma situação onde é necessário desenvolver uma plataforma de comércio Online. Nessa plataforma, possibilitará aumentar a escalabilidade e a conversão de usuários. Para isso, será necessário desenvolver serviços, em formato de Api REST, com o objetivo que o time WEB e o time Mobile possam consumir essas mesmas APIs, conforme apresentado na imagem abaixo:

Untitled Diagram

A imagem acima trata de um cenário bem comum em aplicações web e que estão buscando impelmentar serviços web. As aplicações Web e Mobile tem a capacidade de requisitar informações “diretamente” (Omiti o servidor de autenticação e autorização, por questões didáticas) as APIs. Outro ponto que pode ser observado, na arquitetura acima, é a responsabilidade que, as aplicações Web e Mobile, assumem do ponto de vista de composição de dados (Composite UI Front-end). Uma arquitetura interessante e bem comum de ser encontrada, não acha? Funciona bem na maioria dos casos. Mas infelizmente, no mundo real, essa arquitetura não oferece um desenho arquitetural que facilite a alta escalabilidade de uma plataforma web, tendo em consideração as perspectivas abaixo:

  • Dificuldade em fornecer Roteamento;
  • Composição realizada na UI;
  • Autenticação/Autorização executada separadamente, em cada uma das APIs;
  • Dificuldade em implementar Resiliência através da UI;
  • Baixa Tolerância a falha;
  • Rastreabilidade distribuída em cada um dos serviços;
  • Responsabilidade do monitoramento é delegado aos serviços;
  • Dificuldade de garantir o Rate Limit;
  • Dificuldade de implementação de programação reativa.

Conclusão

Implementar uma arquitetura orientada a serviços, segue um caminho que vai além de criar uma API e publica-la em um servidor com capacidade de escala horizontal ou vertival. Inferir um Microsserviço, dentro de um serviço, é uma tarefa ainda mais desafiador, tendo em vista a necessidade de medir as métricas do monitoramento de um serviço e entender as necessidades estratégicas de uma parte específica do negócio de uma companhia.

Portanto, desenhar uma arquitetura de solução, seja para atender a uma migração de sistemas legados ou mesmo para trabalhar em um projeto Green Field (começando do zero e usando tecnologias atuais), nos exige um conhecimento muito especializado em engenharia de software e padrões de serviços e infraestrutura.

Em um próximo artigo, vou mostrar como podemos solucionar o problema exposto aqui.

O que achou? Deixe um comentário e compartilhe sua experiência em seus projetos!

Referências:

Está interessado em desenvolver Arquitetura de Serviço em seus projetos ou melhorar o desenho de sua arquitetura?

A Emerging Code pode te ajudar. Entre em contato conosco, teremos prazer em realizar mentoria em seus projetos!

Software Architecture in Practice: O que é Arquitetura de Software? (Parte 1)

Sistemas são construídos para satisfazer objetivos das organizações. Por sua vez, a arquitetura de software é a ponte entre esses objetivos (abstração) e o sistema resultante (concreto). Esse caminho do abstrato para o concreto pode ser complexo, a boa notícia é que ele é passivo de design, análise, documentação e implementação, através de técnicas que suportam a compreensão do negócio e seus objetivos.

O que é e o que não é Arquitetura de Software

Existem muitas definições para arquitetura de software. Uma simples busca na internet nos traz facilmente um massivo número delas. Analisemos uma que nos agrada: A arquitetura de software é um conjunto de estruturas necessárias para racionalizar um sistema, compreendidas por elementos de software, as relações entre eles e suas propriedades. Observemos algumas implicações dessa definição:

Arquitetura é um conjunto de estrutura de software

Sistemas de software são composto por muitas estruturas, e uma única estrutura por si só não pode reivindicar o status de arquitetura. Sendo assim, existem três categorias de estruturas arquiteturais:

  1. estrutura de decomposição modular: Módulos são rotulados com específicas responsabilidades computacionais e são a base das atribuições do trabalho de programação. Além disso, são estruturas estáticas cujo foco é a divisão de funcionalidades do sistema para implementação por parte dos times.
  2. estrutura de Componentes-e-conectores (C&C): Estruturas dinâmicas cujo o foco é a interação entre elementos em tempo de execução para realizar funções do sistema.
  3. estrutura de alocação: Descreve o mapeamento da estrutura de software para descrever sua entrega nos diversos ambientes a nível organizacional, de desenvolvimento, de instalação e execução.

Embora o software inclua um grande fornecimento de estruturas, nem todas são arquiteturais. Por exemplo, o conjunto de linhas de um código-fonte que contém a letra “z”, ordenadas pelo tamanho da mais curta para a mais longa, é uma estrutura de software; mas isso não é nada interessante e muito menos é uma estrutura arquitetural. Ou seja:

Uma estrutura é arquitetural se suportar a racionalização sobre o sistema e suas propriedades. Isso inclui funcionalidades alcançadas pelo sistema, a tolerância mediante a falha, a dificuldade para realizar mudanças específicas, a responsividade às requisições de usuários etc.

Arquitetura é uma abstração

Arquitetura de software antes de tudo é uma abstração de um sistema que seleciona certos detalhes e suprime outros. Em sistemas modernos, elementos interagem com outros intermediados por interfaces que divide os detalhes desses elementos em partes públicas e privadas.

Arquitetura está preocupada com esse lado público da divisão; os detalhes privados dos elementos — detalhes que tendem a ser implementações internas — não são arquiteturais. Esta abstração é essencial para domar a complexidade de um sistema . Afinal, não queremos e nem podemos lidar com todas as complexidades o tempo todo.

Todo sistema possui uma Arquitetura

Numa visão mais trivial, o sistema por sí só é um elemento singular — uma incompreensível e provavelmente uma manifestação arquitetural não usual, mesmo assim uma arquitetura.

Apesar de todo sistema ter uma arquitetura, isso não significa que ela é conhecida por alguém. Talvez seus criadores tenham partido, não possua documentação alguma, o código-fonte tenha sido perdido, restando apenas os binários de execução.


Isso revela a diferença entre a arquitetura do sistema e a representação desta arquitetura. Uma vez que uma arquitetura existe independente de sua descrição ou especificação, isso reforça a importância da documentação da arquitetura e da reconstrução da arquitetura.

Arquitetura inclui comportamento

O comportamento de cada elemento é parte da arquitetura na medida que um comportamento pode ser usado para pensar sobre o sistema. Este comportamento corporificado demonstra como elementos interagem com outros e qual, claramente, faz parte de nossa definição arquitetural.

Isso explica porque caixas e linhas desenhadas num papel por si só não são de fato arquitetura. Ao olhar para o nome das caixas (database, GUI, execução, etc), um leitor pode evocar imagens de funcionalidades e comportamentos desses elementos.

Mas isso não significa que o exato comportamento de cada elemento precisa ser documentado em todas as circunstâncias, e sim que a extensão de um comportamento que pode influenciar o sistema pode ser considerada e documentada como arquitetura de software.

Nem toda Arquitetura é uma boa Arquitetura

Uma arquitetura pode permitir ou impedir um sistema de alcançar seus requisitos comportamentais, de qualidade e de ciclo de vida. Supondo que não aceitamos teste e erro como a melhor maneira de escolher uma arquitetura para um sistema, isso levanta a importância do design de arquitetura e avaliação de arquitetura.

Concluindo

Nesse primeiro artigo introduzimos uma definição de Arquitetura de Software e ressaltamos alguns conceitos importantes como “estrutura arquitetural” e suas categorias. Além disso, refletimos sobre o caráter abstrato de uma arquitetura de software; o porquê todo sistema possui uma arquitetura; que arquiteturas de software podem incluir comportamento; e que nem toda arquitetura é uma boa arquitetura.

Espero que você tenha gostado e que continue acompanhando os próximos posts dessa série. Até a próxima…


Este é o primeiro artigo de uma série no qual exponho um resumo dos principais conceitos contidos no livro “Software Architecture in Practice” (Bass, Clements e Kazman, 2013–3rd ed.) da SEI SERIES IN SOFTWARE ENGINEERING.