[ETP] Viabilidade de sistemas robustos se tornarem microsserviços
ESTUDO TÉCNICO PRELIMINAR - ETP
O time Titãs realiza as manutenções de diversos sistemas, sendo eles até este momento: SID, Skala, Comunique-se e Cegonha. Devido a um levantamento técnico se cogitou a implementação de serviços que são fracamente acoplados. Para viabilidade desse tipo de implementação, uma sugestão foi aplicar a arquitetura de microsserviços. De forma conceitual a arquitetura de microsserviços permite a entrega rápida, frequente e confiável de aplicativos grandes e complexos. No entanto, serão expostos neste estudo os aspectos positivos e negativos deste tipo de arquitetura.
2 - AS FUNCIONALIDADES NECESSÁRIAS PARA ATENDER A NECESSIDADE
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
3 - COMPLEXIDADE DE CADA FUNCIONALIDADE
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
4 - POSSÍVEIS PROBLEMAS
4.1. Problemas gerais
Um desafio com o uso dessa abordagem é decidir quando faz sentido usá-la. Ao desenvolver a primeira versão de um sistema, muitas vezes não se tem os problemas que essa abordagem resolve. Além disso, usar uma arquitetura elaborada e distribuída retardará o desenvolvimento. Isso pode ser um grande problema para a SETIC, cujo maior desafio geralmente é evoluir rapidamente o modelo de entregas de valor.
Em casos de sistemas já em operação que precisam ser migrados o problema é de maior impacto. Pois será necessário utilizar a decomposição funcional e as dependências emaranhadas podem dificultar a decomposição do sistema monolítico em um conjunto de serviços.
Idealmente, cada serviço deve ter apenas um pequeno conjunto de responsabilidades. Cada serviço faz exatamente uma coisa, geralmente excepcionalmente bem, e deve ser combinado com outros utilitários para executar tarefas complexas.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
5 - VALOR AGREGADO
A maioria dos sites de grande escala, incluindo Netflix , Amazon e eBay , evoluiu de uma arquitetura monolítica para uma arquitetura de microsserviços.
O Netflix, que é um serviço de streaming de vídeo muito popular, responsável por até 30% do tráfego da Internet, possui uma arquitetura orientada a serviços em grande escala. Eles lidam com mais de um bilhão de chamadas por dia para sua API de streaming de vídeo de mais de 800 tipos diferentes de dispositivos. Cada chamada de API resulta em uma média de seis chamadas para serviços de back-end.
Amazônia . com originalmente tinha uma arquitetura de duas camadas. Para escalar, eles migraram para uma arquitetura orientada a serviços que consiste em centenas de serviços de back-end. Vários aplicativos chamam esses serviços, incluindo os aplicativos que implementam o Amazon . com e a API de serviço da web. A Amazônia . com o aplicativo do site chama 100-150 serviços para obter os dados usados para construir uma página da web.
O site de leilões ebay . com também evoluiu de uma arquitetura monolítica para uma arquitetura orientada a serviços. A camada de aplicativo consiste em vários aplicativos independentes. Cada aplicativo implementa a lógica de negócios para uma área de função específica, como compra ou venda. Cada aplicativo usa divisões no eixo X e alguns aplicativos, como a pesquisa, usam divisões no eixo Z. Ebay . com também aplica uma combinação de dimensionamento de estilo X, Y e Z à camada de banco de dados.
Existem inúmeros outros exemplos de empresas que utilizam a arquitetura de microsserviços.
5 - CONCLUSÃO DO ESTUDO
O presente ESTUDO TÉCNICO PRELIMINAR, elaborado pelos integrantes TÉCNICOS do time TITÃS, considerando a análise dos desafios técnicos envolvidos e citados, conclui pela RECOMENDAÇÃO DA IMPLEMENTAÇÃO DA ARQUITETURA DE MODO CRITERIOSO, uma vez que foram considerados as vantagens e desvantagens em termos de eficiência, principalmente potenciais problemas que afetem a disponibilidade do serviço. Em complemento, os contratempos identificados são administráveis, pelo que RECOMENDAMOS o prosseguimento da demanda a iniciar pelo sistema CEGONHA, uma vez que, o projeto é recentemente e por isso, mais adepto à novas mudanças.