Randy Shoup, VP de Engenharia da Stitch Fix, falou no QCon New York 2017 sobre gerenciamento de dados e persistência isolada em aplicativos baseados em Microservices . Contou como sua equipe aplica técnicas de machine learning em cada uma das parte do negócio, citando exemplos relacionados a vendas, gerenciamento de estoque e recomendações de estilo.
As recomendações personalizadas são geradas ao se processar o estoque em um sistema de machine learning, gerando recomendações algorítmicas. Estas recomendações algorítmicas são então curadas por humanos, estilistas localizados em todo o país, para obter recomendações personalizadas.
As arquiteturas de microserviços estão sempre evoluindo. Organizações como eBay, Twitter, e Amazon passaram todas por algumas iterações de arquitetura para fazer a transição de aplicações monolíticas a uma arquitetura baseada em microserviços
Além de terem um único objetivo, uma interface bem definida - serem modulares e independentes - microserviços também devem gerenciar a persistência isolada. Shoup discute abordagens como o microserviço ter seu próprio repositório de dados ou usar serviços de persistência para obter persistência no microserviço. Na primeira abordagem, guarda-se os dados em sua própria instância de banco de dados, que pertence e é operada pela equipe do serviço. Na opção de usar serviço de persistência, guarda-se os dados num esquema separado no banco de dados, operado como serviço por outra equipe ou por um terceiro provedor. Os dados devem ser isolados de qualquer outros consumidores do serviço.
Eventos são itens primários em uma arquitetura de microserviços. São uma representação do mundo real e têm aplicações em áreas como finanças. Eventos são uma parte crítica da interface do serviço, que deve incluir todos os eventos que o serviço produz e todos os que o serviço consome.
Extrair microserviços de um banco de dados monolítico compartilhado inclui os seguintes passos:
- Criar um serviço: dentro dos limites do serviço devem estar, além do próprio serviço, o banco de dados que é utilizado.
- Começar a utilizar o serviço: desacople as aplicações do banco de dados compartilhado usando para isso o serviço recém criado.
- Mover os dados para uma base privada: depois mova os dados do banco de dados compartilhado para um novo banco de dados, privado. Não haverá impacto nas aplicações do usuário porque elas não dependem mais do banco de dados diretamente.
- Repetir: siga o mesmo processo para outras funções de negócio na aplicação que terão seus próprios microserviços.
Shoup também discute as técnicas de microserviços para casos de uso que envolvem dados compartilhados, joins e transações:
Dados compartilhados: crie um serviço que será o Sistema único de Registro (SuR) e que controlará todo dado. Qualquer outra cópia de dado tem somente permissão para leitura e é considerada cache sem autoridade. Para acessar os dados compartilhados, há três opções: pesquisa síncrona (um serviço chama outro serviço para obter dados), evento assíncrono com cache, ou uma biblioteca de metadados compartilhada.
Joins: dividir os dados entre serviços distintos torna os joins muito difíceis. Pode-se fazer joins de dados no mundo dos microserviços usando os joins na aplicação do cliente ou criando "Materialized Views" acompanhando eventos de dois serviços e mantendo um join não normalizado dos dois conjuntos de dados na memória local.
Transações: o gerenciamento de transações é fácil em bancos de dados monolíticos mas muito difícil na arquitetura de microserviços porque os dados estão distribuídos entre os vários serviços. Pode-se implementar transações como workflows com um mecanismo de rollback rodando as operações feitas em ordem reversa. Muitos sistemas atuais, como processamento de pagamentos ou aprovação de despesas, já fazem isso. Estes workflows também são bons candidatos a usar Funções como Serviços (Serverless architecture).