New to site?


Login

Lost password? (X)

Already have an account?


Signup

(X)

[O Design CANVAS de Microsserviços]

05
mar 2018

O Design CANVAS de Microsserviços

O desenvolvimento dos microsserviços muitas vezes acontece de maneira orgânica. Emerge do caldeirão borbulhante de aplicações monolíticas que foram criadas para preencher uma necessidade imediata. Com o desejo de melhorar a velocidade de entrega, que impulsiona a adoção de microsserviços, desenvolvedores geralmente adotam uma abordagem de “primeiro o código, perguntas depois” e reafirmam seu caminho para um resultado útil.
Isso é bom. Mas, é ótimo?

Para responder, precisamos fazer uma outra pergunta: quais as considerações que devem ser feitas antes de desenvolver um microsserviço? Como o arquiteto de softwares Simon Brown gosta de dizer: “Um grande projeto de interface é burro, mas nenhum projeto é ainda mais burro”.
Tomando emprestado a abordagem de lean canvas, gostaria de apresentar a tela de projeto dos microsserviços. Esta é uma ferramenta que deve ajudá-lo a identificar os atributos mais importantes do seu serviço antes de construí-lo. É uma abordagem com visão externa, que serve para acoplar sua interface a partir de sua implementação subjacente.

• Você pode começar preenchendo uma “Descrição” de seu serviço na caixa inferior.
• A partir daqui, deve ser preenchida a caixa “Tarefas do Consumidor”, documentando o que seus consumidores precisam executar e os trabalhos que devem ser habilitados por seu serviço.
• Enumerar os usuários do serviço, juntamente com as tarefas que eles precisam realizar, ajuda a cristalizar a finalidade do serviço e fornece os materiais necessários para projetar sua interface.
Esta informação deve ajudá-lo a preencher a caixa “Interface”. Aqui, as tarefas do consumidor podem ser divididas em interações específicas com a interface do serviço. A classificação dessa seção de acordo com os padrões – de consultas, comandos e eventos – ajudará a moldar a implementação do serviço subjacente e, em última instância, ajudará a direcionar o design da sua API.
Além das tarefas e das interações para o serviço, devemos considerar seus aspectos não funcionais. Você pode usar a caixa “Qualidades” para identificar propriedades como disponibilidade, níveis de desempenho, abordagens de extensibilidade e segurança. Isso ajudará a melhorar a compreensão dos consumidores e também influenciará sua implementação. Em conjunto, as tarefas, a interface e as qualidades definem a “superfície” do serviço – crucial para o design do sistema, pois captura as informações mais importantes para outras partes interessadas no sistema.
Sob a superfície, ainda existem algumas considerações importantes. As caixas “Lógica (ou ”Regras”) e “Dados” fornecem um lugar para os designers documentarem informações-chave nessas áreas. Resista à tentação de ir muito fundo nesta fase. Não é necessário planejar o sistema interno completo, mas você pode querer observar os itens considerados exclusivos e necessários para dar suporte às propriedades da superfície.
Finalmente, o quesito “Dependências” deve ser listado para chamar as tarefas requisitadas. Para microsserviços de atividades pesadas, é natural exigir interações com mais funções orientadas aos dados. No entanto, no espírito da arquitetura de microsserviço, o objetivo é minimizar essas dependências.
Vejamos algumas telas de exemplo. Primeiro é uma tela para o serviço de gerenciamento de pagamentos centrado no cliente:

Observe que este serviço parece ser direto em suas interações e relativamente autossuficiente com seus dados. De uma perspectiva não funcional, não é uma missão crítica e não exige o nível mais alto de integridade transacional. Portanto, sua implementação pode ser bastante simples.
Em seguida, é uma tela para o serviço de Autorização de Pagamentos:

Existem algumas considerações mais complexas para este exemplo. Em primeiro lugar, espera-se que seja de alto volume e baixa latência. Isso tem um impacto definitivo na engenharia do serviço, incluindo a necessidade de um cache complexo de informações de autorização. Em segundo lugar, uma vez que suas interações envolvem o movimento do dinheiro, a integridade transacional e a auditoria são primordiais.
Por fim, existem algumas interações de eventos que significam que as interfaces irão além das RESTful APIs. De fato, ver essas diferenças não funcionais deixa claro porque foi uma boa decisão de design dividir as funções de autorização e gerenciamento da solução de pagamento em serviços separados. A interação entre a exibição do sistema e a visão do serviço será útil na definição dos limites do serviço
Espero que esta tela de design de microsserviço possa ser uma ferramenta útil para aqueles que se embarcam nesta jornada. Ela vincula o design da API e, dessa perspectiva, o trabalho dos meus colegas na API Academy. Confira a metodologia de design API de Mike Amundsen como próximo passo, especialmente o potencial da ALPS como forma de definir a semântica de um serviço. Além disso, a ferramenta Rapido de Ronnie Mitra para ver como você pode esboçar um design de API de forma similarmente intuitiva. E os padrões de Erik Wilde para extensibilidade robusta irão ajudá-lo a eliminar qualidades e definir mais microsserviços evolutivos.

Para saber mais sobre esses tópicos e interagir diretamente com os membros da API Academy, junte-se a nós no APICON 2018!

Escrito por membros do API Academy

 

O Mike Amundsen é um dos maiores consultores de APIs do mundo, e é um dos mais de 25 palestrantes que estarão no APICON 2018!

 

Garanta já o seu lugar, clique aqui.

 

 


Leave A Comment

Leave A Comment