Impactos da descontinuação da API do e-estado
| Data de elaboração |
10/02/2022 |
|---|---|
| Responsável pelo estudo |
João Pedro Rocha Brito (Assessor) |
|
Equipe do estudo |
João Pedro Rocha Brito (Assessor) José Lucas da Silva Costa (Analista de Desenvolvimento Full-Stack) Jônatas Neves Legal (Técnico emTecnologia da Informação e Comunicação) |
| Alvo | E-estado |
| Origem |
Melhoria: Descontinuação da API do e-estado |
|
Objetivo |
Averiguar os sistemas que utilizam a API do E-Estado e monitorar os problemas de performance da API antiga para que não ocorra na nova. |
| Documentação Correlata | Sem documentação. |
|
Observações |
Sem observações. |
- API - Application Programming Interface (interface de Programação de Aplicações).
- KIBANA - Plugin de visualização de dados de fonte aberta para o Elasticsearch.
- SETIC - Superintendência Estadual de Tecnologia da Informação e Comunicação.
- SID - Sistema Integrado de Descanso.
2. Introdução
3. Desenvolvimento - Impactos da descontinuação da API do e-estado
A ação que deve ser tomada é tentar minimizar os impactos dos sistemas que utilizam o E-estado, o time de desenvolvimento utiliza o Scrum como ferramenta para a entrega de produtos, essas entregas devem contemplar as adaptações necessárias para esta melhoria. Para melhor se situar no assunto, O Scrum é uma estrutura iterativa e incremental para gerenciar o desenvolvimento de produtos. Ele define uma estratégia de desenvolvimento de produto flexível e holística, onde uma equipe de desenvolvimento trabalha em conjunto para alcançar um objetivo comum.
Atualmente o SID por exemplo, utiliza massivamente a seguinte API:
https://e-estado-api.master.local/api/movimentacoes/nomeOuCpf/
Esta API é solicitada com certa frequência e causa alguns problemas de desempenho em determinadas requisições que possua secretarias, onde a quantidade de servidores é maciça, vejamos relatório de desempenho de uma requisição no Kibana:
Fonte: SETIC-RO
Considerando que o SID mantém a média de 1000 requisições à essa rota e também considerando que este processamento acontecerá de modo monotarefa, então o tempo atual que está em média a 656 milissegundos é muito alto. Vinculado a isso a API antiga do E-estado não possui mais suporte técnico e supostamente deve ser descontinuada.
Outro fator de impacto para os sistemas do time TITÃS é a desvinculação de alguns dados do SAURON, dados esses que não são sobressalentes devido o E-estado já conter as mesmas informações. Essa desvinculação causará a demanda de manutenções, em especial o sistema SKALA, que não foi previamente preparado para se ter essa independência, cenário este que é um pouco diferente no SID pois ao perceber esse problema o time se antecipou e fez preparativos para que o SID pudesse buscar dados essenciais no SAURON e o restante no E-estado.
3.2. Complexidade de cada funcionalidade
A API a ser migrada do E-estado não possui o cenário de testes, principalmente o de carga que pode medir o desempenho da mesma, desta forma se faz necessário também os testes de API funcionais, que podem ajudar neste cenário onde está ocorrendo problemas de desempenho, principalmente se o mesmo problema vim na API nova que será migrada do E-estado.
Testes de API funcionais são equivalentes a testes de unidade para software: uma maneira de garantir que a API retorne a saída desejada para uma determinada entrada, situação esta que ainda não possui nos projetos que o TITÃS mantém. Esses testes podem ser executados em todos os ambientes, desde o computador pessoal de um desenvolvedor até ambientes de teste até o sistema de produção final.
É recomendável executá-los para verificar se a implantação não interrompe a funcionalidade. Quando a implantação funciona, os testes devem retornar os mesmos resultados em todos os lugares. Já os testes de API de carga, por outro lado, normalmente são executados em produção ou em um sistema equivalente. Isso ocorre porque as restrições não funcionais, como confiabilidade e capacidade de resposta, parecem diferentes sob várias condições do mundo real. O teste de API funciona de maneira semelhante ao teste de site, embora os testes de site possam incluir o comportamento do navegador do lado do cliente, enquanto os testes de API enviam apenas solicitações de rede.
3.3. Possíveis problemas
Quando uma API falha ou possui problemas de desempenho, essa falha reflete na SETIC. Os usuários finais e clientes provavelmente não reconhecerão que um terceiro pode ser o culpado. E dependendo da importância dessa API para um processo de transação, essa falha pode afetar seus resultados imediatamente. Encontrar problemas de desempenho apenas algumas semanas antes da data de lançamento de um sistema em produção de uma API de aplicativo, é uma ocorrência comum. Um tempo de alta resolução é preciso até frações de milissegundos. Essa precisão o torna ideal para produzir medições precisas de tempo. Cada medição medida na Performance API é um tempo de alta resolução. A API de alto desempenho faz parte da API de tempo de alta resolução. À medida que o aplicativo aumenta, ele pode enfrentar problemas de desempenho. Portanto, é melhor ter testes de carga/desempenho desde o início. A maioria das empresas de desenvolvimento de software tem equipes de teste dedicadas que realizariam testes de integração para garantir que não haja gargalos.
3.4. Valor agregado
A melhoria de desempenho em API está sendo amplamente utilizada na indústria de software para permitir a integração de múltiplas aplicações de forma eficiente. Embora os aplicativos tenham sido submetidos a muitos testes manuais e automatizados antes do lançamento, é possível que surjam problemas na produção. Neste estudo técnico, vimos os problemas comuns encontrados, seguidos pelas práticas para minimizar os problemas.
Nenhum comentário