Contacte-nos para um orçamento FinMV personalizado à medida das suas necessidades.
O diretor técnico da sua empresa, ao planejar o lançamento de uma plataforma financeira, deverá escolher uma opção de arquitetura de projeto. Quais opções de arquitetura estão disponíveis para ele e qual é melhor escolher?
Uma arquitetura monolítica é como uma bola de neve. Você inicia um projeto e tem uma pequena bola de neve. É tão pequeno que pode ser desenvolvido e implementado por uma pequena equipe. Alguns anos se passaram e agora sua bola de neve se tornou tão grande que 20 desenvolvedores já estão empurrando-a. Em mais alguns anos, centenas de desenvolvedores estarão rolando sua bola de neve com uma tonelada de código, mas o lançamento de novos recursos será muito lento.
Como resultado, os proprietários começam a mudar o diretor técnico, os membros da equipe, mas só piora. Os novos membros da equipe não conhecem os detalhes históricos, por que a bola de neve é do jeito que é e não de outra. A documentação do produto fica desatualizada rapidamente.
Por que não fazer isso desde o início? Em primeiro lugar, no início de um negócio, sempre há recursos limitados, não há desenvolvedores, experiência e tempo suficientes. O manual é urgente e os programadores estão com pressa para fazê-lo da maneira mais rápida possível.
Em segundo lugar, os engenheiros técnicos pensam: "Bem, que seja uma arquitetura monolítica por enquanto, mas quando o negócio crescer, vamos refazer tudo". Infelizmente, na realidade, transferir um projeto monolítico existente para uma arquitetura de microsserviço será dezenas mais difícil do que escrever tudo do zero.
Faremos sua plataforma financeira imediatamente baseada na arquitetura de microsserviços.
A arquitetura de microsserviços pode ser comparada a lajes de calçadas. À medida que seu projeto cresce, mais telhas são adicionadas à sua passarela. Se um componente estiver desatualizado, basta substituir esse bloco por um novo.
Esta arquitetura tem muitas vantagens, mas vou citar as mais importantes:
Primeiro exemplo. A gestão de uma plataforma de empréstimo P2P com um grande número de usuários decidiu entrar nos mercados de países com uma moeda diferente. A plataforma tinha uma arquitetura monolítica e incluía apenas uma moeda - o euro, e para entrar nos mercados da Suécia (coroa sueca), Polônia (zloty polonês), República Tcheca (coroa tcheca) era necessário introduzir multimoedas.
Levou meses para que toda a equipe implementasse essa funcionalidade, e o desenvolvimento de novas funcionalidades ficou ainda mais lento. No caso de uma arquitetura de microsserviço, tudo seria muito mais fácil e rápido.
Segundo exemplo. Inicialmente, o construtor de sites foi lançado no idioma nativo e a gestão não iria expandir para outros mercados. O projeto tinha uma arquitetura monolítica e a funcionalidade cresceu rapidamente. O esquema da plataforma era uma teia complexa na qual tudo estava conectado a tudo. Um dia, a empresa decidiu lançar uma versão da plataforma em outros idiomas. A princípio, parecia que bastaria adicionar apenas arquivos de idioma e agora teremos toda a interface traduzida.
Na prática, todo o projeto teve que ser refeito. Por exemplo, os nomes de empresas e produtos no banco de dados agora devem ser armazenados não apenas em um idioma, mas em cada idioma. Era impossível duplicar informações por causa da lógica do negócio, era necessário armazenar os nomes para todos os idiomas de uma só vez. Assim, isso levou a mudanças nas interfaces do gabinete e do back office. As mudanças de interface exigiram a alteração das regras de validação de dados de entrada, modelos de carta devido a diferentes princípios de terminações em diferentes idiomas, alteração de testes etc.
Como tudo estava conectado a tudo, foi tomada a decisão de migrar para uma arquitetura de microsserviços juntamente com o lançamento de novas linguagens. O processo de transição da arquitetura monolítica para a arquitetura de microsserviços levou mais de um ano.
Terceiro exemplo. A plataforma fintech foi feita em uma versão antiga do PHP e Laravel. Atualizar para versões mais recentes, bem como mudar o banco de dados de MariaDB para PostgreSQL, era praticamente impossível, pois toda a equipe teve que lidar apenas com o processo de migração por vários meses.
Novas versões de PHP e Laravel naquela época poderiam acelerar o projeto e o desenvolvimento, mas a arquitetura monolítica não permitia atualizar a pilha de tecnologia
.
