İhtiyaçlarınıza göre uyarlanmış kişiselleştirilmiş bir FinMV teklifi için bizimle iletişime geçin.
Şirketinizin teknik direktörü, bir finansal platformun lansmanını planlarken bir proje mimarisi seçeneği seçmek zorunda kalacaktır. Kullanabileceği mimari seçenekler nelerdir ve hangisini seçmek daha iyidir?
Monolitik bir mimari kartopu gibidir. Bir projeye başlıyorsunuz ve küçük bir kartopunuz var. O kadar küçüktür ki küçük bir ekip tarafından geliştirilip yuvarlanabilir. Birkaç yıl geçti ve şimdi kartopunuz o kadar büyük oldu ki 20 geliştirici şimdiden onu zorluyor. Birkaç yıl içinde, yüzlerce geliştirici bir ton kodla kartopunuzu yuvarlayacak, ancak yeni özelliklerin kullanıma sunulması çok yavaş olacak.
Sonuç olarak, sahipler teknik direktörü, ekip üyelerini değiştirmeye başlar, ancak daha da kötüleşir. Yeni ekip üyeleri, tarihi detayları bilmiyorlar, kartopunun neden başka bir şekilde değil de böyle olduğunu bilmiyorlar. Ürün belgeleri hızla güncelliğini yitirir.
Bunu neden en baştan yapmıyorsunuz? İlk olarak, bir işletmenin en başında her zaman kaynaklar sınırlıdır, yeterli geliştirici, uzmanlık ve zaman yoktur. Kılavuz zorluyor ve programcılar bunu mümkün olan en hızlı şekilde yapmak için acele ediyor.
İkinci olarak, teknik mühendisler şöyle düşünüyor: "Şu an için monolitik bir mimari olmasına izin verin, ancak iş büyüdüğünde, her şeyi yeniden yapacağız". Ne yazık ki, gerçekte, mevcut bir monolitik projeyi bir mikro hizmet mimarisine aktarmak, her şeyi sıfırdan yazmaktan onlarca kat daha zor olacaktır.
Finansal platformunuzu hemen mikro hizmet mimarisine dayalı hale getireceğiz.
Mikro hizmet mimarisi, patikalardaki kaldırım levhalarıyla karşılaştırılabilir. Projeniz büyüdükçe, yürüyüş yolunuza daha fazla karo eklenir. Bir bileşen eskiyse, bu kutucuğu yenisiyle değiştirmek yeterlidir.
Bu mimarinin birçok avantajı vardır, ancak en önemlilerini sıralayacağım:
İlk örnek. Çok sayıda kullanıcısı olan bir P2P kredi platformunun yönetimi, farklı bir para birimiyle ülke pazarlarına girmeye karar verdi. Platform yekpare bir mimariye sahipti ve yalnızca bir para birimini içeriyordu - euro ve İsveç (İsveç kronu), Polonya (Polonya zlotisi), Çek Cumhuriyeti (Çek tacı) pazarlarına girmek için çoklu para birimini tanıtmak gerekiyordu.
Tüm ekibin bu işlevi uygulaması aylar aldı ve yeni işlevlerin geliştirilmesi daha da yavaşladı. Mikro hizmet mimarisi söz konusu olduğunda her şey çok daha kolay ve hızlı olurdu.
İkinci örnek. Başlangıçta, site oluşturucu ana dilde başlatıldı ve yönetim başka pazarlara açılmayacaktı. Proje yekpare bir mimariye sahipti ve işlevsellik hızla büyüdü. Platformun şeması, her şeyin her şeyle bağlantılı olduğu karmaşık bir ağdı. Bir gün işletme, platformun başka dillerde bir sürümünü yayınlamaya karar verdi. İlk başta sadece dil dosyalarını eklemek yeterli gibi görünüyordu ve şimdi tüm arayüzü tercüme ettireceğiz.
Uygulamada, tüm projenin yeniden yapılması gerekiyordu. Örneğin veri tabanındaki firma ve ürün isimleri artık sadece bir dilde değil, her dilde saklanmalıdır. İş mantığı nedeniyle bilgileri çoğaltmak imkansızdı, tüm dillerin adlarını bir kerede saklamak gerekiyordu. Buna göre, bu, kabine ve arka ofisin arayüzlerinde değişikliklere yol açtı. Arayüz değişiklikleri, gelen verileri doğrulamak için kuralların değiştirilmesini, farklı dillerdeki farklı sonlandırma ilkeleri nedeniyle harf şablonlarını, değişen testleri vb. gerektirdi.
Her şey her şeyle bağlantılı olduğundan, yeni dillerin kullanıma sunulmasıyla birlikte bir mikro hizmet mimarisine geçiş kararı alındı. Monolitik mimariden mikro hizmet mimarisine geçiş süreci bir yıldan fazla sürdü.
Üçüncü örnek. Fintech platformu, PHP ve Laravel'in eski bir sürümünde yapılmıştır. Daha yeni sürümlere geçmek ve veritabanını MariaDB'den PostgreSQL'e değiştirmek neredeyse imkansızdı çünkü tüm ekip birkaç ay boyunca yalnızca geçiş süreciyle uğraşmak zorunda kaldı.
O zamanlar PHP ve Laravel'in yeni sürümleri projeyi ve daha fazla geliştirmeyi hızlandırabilirdi, ancak monolitik mimari teknoloji yığınının güncellenmesine izin vermedi
.
