Свържете се с нас за персонализирана оферта за FinMV, съобразена с вашите нужди.
Техническият директор на вашата компания, когато планира стартирането на финансова платформа, ще трябва да избере опция за архитектура на проекта. Какви опции за архитектура са на разположение за него и коя е по-добре да избере?
Монолитната архитектура е като снежна топка. Започвате проект и имате малка снежна топка. Толкова е малък, че може да бъде разработен и търкален от малък екип. Минаха няколко години и сега вашата снежна топка стана толкова огромна, че 20 разработчици вече я настояват. След още няколко години стотици разработчици ще въртят снежната ви топка с много код, но пускането на нови функции ще стане много бавно.
В резултат на това собствениците започват да сменят техническия директор, членовете на екипа, но само се влошава. Новите членове на отбора не знаят историческите подробности, защо снежната топка е такава, каквато е, а не друга. Документацията на продукта бързо става остаряла.
Защо не го направите от самото начало? Първо, в самото начало на бизнеса винаги има ресурсите са ограничени, няма достатъчно разработчици, опит и време. Ръководството е настоятелно, а програмистите бързат да го направят по възможно най-бързия начин.
Второ, техническите инженери си мислят: "Е, нека засега да е монолитна архитектура, но когато бизнесът се разрасне, тогава ще преработим всичко". За съжаление, в действителност прехвърлянето на съществуващ монолитен проект към архитектура на микросервизи ще бъде десетки пъти по-трудно от писането на всичко от нулата.
Ние ще направим вашата финансова платформа незабавно базирана на микросервизна архитектура.
Микросервизната архитектура може да се сравни с тротоарните плочи на пешеходните пътеки. С разрастването на вашия проект към пътеката ви се добавят още плочки. Ако даден компонент е остарял, достатъчно е да замените тази плочка с нова.
Тази архитектура има много предимства, но ще назова най-важните:
Първи пример. Управлението на P2P платформа за кредитиране с голям брой потребители реши да навлезе на пазарите на държави с различна валута. Платформата имаше монолитна архитектура и включваше само една валута – еврото, а за навлизане на пазарите на Швеция (шведски крони), Полша (полска злота), Чехия (чешка крона) беше необходимо да се въведе мултивалута.
Отне месеци на целия екип, за да приложи тази функционалност, а разработването на нова функционалност се забави още повече. В случай на микросервизна архитектура всичко би било много по-лесно и по-бързо.
Втори пример. Първоначално конструкторът на сайтове беше пуснат на родния език и управлението нямаше намерение да се разширява на други пазари. Проектът имаше монолитна архитектура и функционалността нараства бързо. Схемата на платформата беше сложна мрежа, в която всичко беше свързано с всичко. Един ден бизнесът решава да пусне версия на платформата на други езици. Първоначално изглеждаше, че ще бъде достатъчно да добавим само езикови файлове и сега ще имаме преведен целия интерфейс.
На практика целият проект трябваше да бъде преработен. Например, имената на компании и продукти в базата данни вече трябва да се съхраняват не само на един език, но и на всеки език. Беше невъзможно да се дублира информация поради бизнес логиката, беше необходимо да се съхраняват имената за всички езици наведнъж. Съответно това доведе до промени в интерфейсите на кабинета и бек офиса. Промените в интерфейса изискваха промяна на правилата за валидиране на входящи данни, шаблони за писма поради различни принципи на окончания на различни езици, промяна на тестове и др.
Тъй като всичко беше свързано с всичко, беше взето решението да се премине към микросервизна архитектура заедно с пускането на нови езици. Процесът на преход от монолитна към микросервисна архитектура отне повече от година.
Трети пример. Платформата за финтех е направена на стара версия на PHP и Laravel. Надстройката до по-нови версии, както и промяната на базата данни от MariaDB към PostgreSQL, беше практически невъзможно, тъй като целият екип трябваше да се справя само с процеса на миграция в продължение на няколко месеца.
Новите версии на PHP и Laravel по това време можеха да ускорят проекта и по-нататъшното развитие, но монолитната архитектура не позволяваше актуализиране на технологичния стек
.
