Çok kiracılı sistem nasıl kurulur

Çok kiracılı sistem, birden fazla kurumun aynı yazılım çekirdeğini paylaştığı, her kurumun verisinin ve markasının yalnız kendisine kaldığı işletim modelidir. Karar, kaydın hangi kuruma ait olduğunun nerede tutulduğunda düğümlenir; sınır kaydın üstündeyse soru bir kez cevaplanır. Vipkurum çatısına katılan kurum çekirdeğin işlevlerini hazır bulur ama veriyi hazır bulmaz; ders programını, öğrenci kaydını ve sınav içeriğini kendisi girer.

Yedi kurum neden yedi ayrı kurulum istemedi

Hazır panel satın alan kurum, kullanıcısının karşısına yazılımın markasıyla çıkar. Adres yazılımın adresidir, ekranın üstündeki ad yazılımın adıdır, kurumun kendi adı bir köşede kalır. Yedi kurumun kendi alan adı ve markasıyla paylaştığı Vipkurum çekirdeğinde istenen bunun tersiydi: kurum kendi adresinden girecek, kendi markasıyla görünecek, çekirdek yine tek kalacaktı. Sistemin biçimini belirleyen şey bu marka talebiydi.

Çatıdaki yedi kurum tek tip de değil. Özel eğitim kurumu, dershane, uzaktan eğitim merkezi ve okul aynı yazılımı paylaşıyor. Her birinin kendi öğrencisi, kendi ders programı, kendi ödeme kaydı var. Ortaklık yazılımda; veride yok. Bu ayrımı baştan söylemek gerekiyor, çünkü “aynı sistemi kullanıyorlar” cümlesi çoğu zaman “aynı havuza yazıyorlar” diye anlaşılıyor.

Alternatif açıktı: yedi kurum, yedi kurulum. Her kuruma kendi kurulumu verilir, her biri kendi başına yaşar ve kimse kimsenin verisine yaklaşamaz. Bu yolun bedeli işlev tarafında birikirdi. Ders programı, sınav, öğrenci, veli, ödeme ve raporlama tek platformda toplanıyor; yedi ayrı kurulum bu işlevlerin yedi kopyası demek olurdu. Ortak yazılımda yapılan bir iş yedi yere dağılır, yedi yerde ayrı ayrı doğrulanır ve zamanla birbirinden ayrışan yedi farklı sürüme dönüşürdü.

Marka talebinin tek başına bir sistem kararı doğurduğunu görmek de önemli. Kurum, öğrencisine ve velisine hangi adı gösterdiğini pazarlama meselesi sayar; oysa bu istek doğrudan verinin ve adresin nasıl kurulacağını belirliyor. Kurumun görünürlüğünü koruma isteği burada sistemin taşıması gereken bir koşul olarak masaya geldi.

Kiracı sınırı veri modelinde nasıl yaşar

Vipkurum’da öğrenci, veli ve ödeme kaydı hiçbir koşulda kurum sınırını geçmiyor. Bir kurumun kaydı komşu kiracıya görünmüyor. Bu cümlenin ağırlığı sınırın nerede tutulduğundan geliyor: izolasyon arayüzde uygulanan bir görünürlük filtresi değil, kaydın kendisinin taşıdığı bir sınır. Sınırın nerede durduğu, sistemin hangi yüzeyinde hata yapabileceğini belirliyor.

İki kurgu arasındaki fark pratikte şuraya çıkıyor. Sınır bir filtre olsaydı, her ekranın, her listenin ve her raporun o filtreyi ayrı ayrı hatırlaması gerekirdi. Hatırlamayan tek bir yüzey sınırı o yüzeyde delerdi. Sınır kaydın kendisinde durduğunda ise soru bir kez cevaplanıyor: bu kayıt hangi kuruma ait? Cevap kaydın üzerinde olduğu için, kaydı okuyan her yer aynı cevabı buluyor.

Model ortak, kayıt ayrı. Ders programı, sınıf, şube, sınav ve ödeme kaydı tek veri modelinde duruyor. Yani yedi kurum aynı tanımları kullanıyor: “şube” her kurumda aynı şeyi anlatıyor, “sınav” her kurumda aynı yapıya sahip. Ortak olan bu tanım katmanı; kayıtların kendisi kuruma bağlı kalıyor.

Sınırın ikinci yüzü raporlamada görünüyor. Fatura, ödeme ve analiz raporları yöneticinin kendi kiracı verisi üzerinden çıkıyor. Bu, aynı sınırın rapor katmanındaki karşılığı. Raporlama çoğu sistemde sınırın en kolay gevşediği yer olur; çünkü rapor kayıtları toplayarak üretilir ve toplama işlemi sınırı en kolay atlayan işlemdir. Bir kurumun ay sonu tablosuna başka kurumun ödemesi karışsa bunu yakalayacak bir işaret olmaz; yönetici rakamı olduğu gibi kabul eder.

Sınırın bu iki yüzü aynı sorunun iki adresi. Birincisi kaydın okunduğu an, ikincisi kayıtların toplandığı an. İkisinden yalnız birini kuran bir sistem, günlük kullanımda doğru çalışıp ay sonunda yanlış rakam üretebilir.

Alan adı gelen isteği kiracıya nasıl bağlar

Vipkurum çatısındaki yedi kurum kendi adresinden giriyor: egitakademi.com, ozdilakademi.com, mergenkampus.com, edebiyatuzem.com, dekaakademi.com, turkcefm.com, statuakademi.com.tr. Kiracı izolasyonu alan adı seviyesinde kuruluyor. Kiracı kimliğini kullanıcının listeden yaptığı seçim değil, geldiği adres belirliyor.

Bu, küçük görünen ama sonucu belirleyen bir tercih. Ortak tek adres kurulup girişte kurum seçtiren bir düzen de mümkündü. O düzende kullanıcı önce platformu görür, sonra kendi kurumunu bulur. Marka talebi tam olarak bunu istemiyordu. Kurumun kullanıcısı Vipkurum adını değil kendi kurumunun adresini ve markasını görüyor; çekirdeğin tekliği kullanıcıya görünmüyor.

Adresin kiracıyı belirlemesinin ikinci sonucu, kimliğin kullanıcı davranışına bırakılmaması. Seçime dayalı bir düzende yanlış seçim mümkündür: kullanıcı listeden komşu kurumu işaretler, giriş denemesi yanlış kapıya gider ve destek tarafında “hangi kurumdan giriyorsunuz” sorusu gündelik bir soruya dönüşür. Adres tarafında böyle bir adım hiç yok; kullanıcı zaten kendi kurumunun bağlantısını kullanıyor.

Alan adının kurumda kalması aynı zamanda kurumun kendi iletişimini sürdürmesi demek. Kurum broşürüne, tabelasına ve sosyal hesabına kendi adresini yazıyor. Çatıya katılmak, bu adresin yerini platformun adresine bırakması anlamına gelmiyor. Kurumun yıllardır dolaşımda olan adresi çalışmaya devam ediyor.

Adresin burada iki işi birden yaptığını söylemek gerekiyor. Bir yandan kullanıcıya kurumun markasını gösteriyor, öbür yandan sistemin hangi kiracıya hizmet ettiğini belirliyor. Marka isteği ile izolasyon gereği çoğu kurulumda iki ayrı problem gibi ele alınır ve iki ayrı yerde çözülür. Burada ikisinin cevabı tek bir olgudan çıkıyor: isteğin geldiği adres. Sonradan bakıldığında sade görünen bu denklik, baştan kurulmadığında kendiliğinden oluşmuyor.

Marka kiracıya göre değişince web ve mobil ne yapar

Panel arayüzleri React ile, mobil taraf React Native (Expo) ile geliştirildi. İki yüzey de aynı Laravel uygulamasına bağlanıyor. Yüzey çoğalıyor, işleyiş çoğalmıyor: bir öğrencinin ders programı tarayıcıda da telefonda da aynı kayıttan okunuyor.

Kayıt katmanı da tek. MySQL ve MongoDB kayıt tutuyor, Redis önbellek taşıyor. Yüzey web de olsa mobil de olsa bu katman değişmiyor. Buradan çıkan sonuç şu: marka farklılaşması veri katmanına inmiyor. Marka kiracıya ait; ders, sınav, ödeme ve raporlama işleyişi tek uygulamada kalıyor.

Kurumun kendine ait olan şey yalnız görünürlük de değil. İçerik yönetim katmanı kurumun kendi dersini, testini, sorusunu ve sınavını oluşturmasına izin veriyor. Değerlendirme türünü de kurumun kendisi tanımlıyor; bu yüzden Avrupa ve Türkiye ölçütleri aynı altyapıda yan yana durabiliyor. İçeriğin ve markanın kiracıya göre değiştiği yayın katmanını kurarken sorduğumuz soru şu oluyor: bu tanımı kim yapacak, biz mi kurum mu? Cevap kurumsa, tanım koda değil kayda yazılır.

Bu sorunun cevabı ortak yazılımın ne kadar dayanacağını da belirliyor. Değerlendirme türü koda gömülseydi her yeni ölçüt bir geliştirme talebi olurdu ve yedi kurumun talepleri sıraya girerdi. Tanım kurumun elinde olduğunda kurumlar birbirini beklemiyor.

Yüzeyin çoğalması sınırın çoğalması anlamına da gelmiyor. Mobil uygulama aynı Laravel uygulamasına bağlandığı için okuduğu kayıt kiracı sınırını zaten üzerinde taşıyor; yüzeyin kendi başına bir cevabı olması gerekmiyor. Sınırın her yüzeyde yeniden tanımlandığı bir kurguda ise her yeni ekran aynı kuralı bir kez daha yazmak olurdu. Yeniden yazılan her kural da ilkinden ayrışma ihtimali taşır ve ayrışmanın hangi ekranda olduğu ancak biri fark ettiğinde ortaya çıkar.

Öğretmen, öğrenci, veli ve yönetici aynı ders programına nasıl bakar

İkinci sınır kurumun içinde duruyor. Öğretmen, öğrenci, veli ve kurum yöneticisi aynı ders programı kaydına bakıyor; her biri aynı kayda kendi yetkisi kadar erişiyor. Kayıt rol başına kopyalanmıyor.

Kopyalansaydı ne olurdu, somutlaştıralım. Bir dersin saati değiştiğinde değişikliğin dört kopyaya birden işlemesi gerekirdi. İşlemediği an kopyalar birbirinden ayrışır: veli bir saat görür, öğretmen başka bir saat görür ve hangisinin doğru olduğu ancak konuşarak anlaşılır. Rol farkı tek kayıt üstünde yetkiye indiğinde bu ayrışmanın zemini kalmıyor.

Aynı sınır iletişim katmanında da geçerli. Duyuru, mesaj ve bildirim kurum içinde akıyor. Bir kurumun velisine giden bildirim komşu kurumun akışına düşmüyor; kurum içinde de rolün gördüğü kadarını taşıyor.

Rol sınırının pratik karşılığı, aynı kaydın farklı kesitlerinin görünmesi. Dört rol de aynı ders programı kaydının üstünde duruyor; her biri o kaydın kendi yetkisine düşen kesitini görüyor. Kesiti belirleyen şey rol başına açılmış ayrı bir kayıt değil, aynı kayda kimin ne kadar erişebildiği. Bu yüzden bir kişinin yetkisi değiştiğinde gördüğü şey değişiyor, kaydın kendisi yerinde kalıyor.

İki sınırı ayrı ayrı adlandırmakta fayda var. Bir önceki bölümlerde anlatılan sınır kurumlar arasında, buradaki sınır kurumun içinde. Kiracıyı ayırmak yetmiyor, kiracının içini de ayırmak gerekiyor. İkisinden biri eksik kalırsa sistem ya kurumları birbirine karıştırır ya da kurum içinde herkesi her şeye bakar hâle getirir. İkinci hata daha sessizdir, çünkü hiçbir ekranda hata gibi görünmez.

Yeni kurum eklemek neden kurulum değil kayıt olur

Vipkurum’a yeni kurum eklemek yeni kurulum değil, yeni kiracı tanımı oluyor. Kurum mevcut çekirdeğin üstünde tanımlanıyor ve kendi alan adından girmeye başlıyor. Aynı işlevler tanımla birlikte kullanılabiliyor, çünkü ortak yazılım onları zaten taşıyor.

Buradaki asıl mesele iş yükünün büyüklüğü değil, işin türü. Kurulum bir projedir: başlangıcı, bitişi ve kendi takvimi olan bir iş. Tanım ise bir kayıt işlemidir. Bir kurumun çatıya katılması ikinci sınıfa girdiğinde, katılma kararı da bir yazılım projesinin takvimine bağlı olmaktan çıkıyor.

Katılan kurumun tarafından bakınca soru şu oluyor: ne veriyorum, ne alıyorum? Hazır panel dünyasında verilen şey görünürlüktür: kurum yazılımın markasıyla görünmeye başlar ve kendi adresini bırakır. Burada bu bedel ödenmiyor. Kurum kendi alan adı ve markasıyla göründüğü için çatıya girmek markayı platforma devretmek anlamına gelmiyor.

Aldığı şey ise ortak yazılımın taşıdığı işleyiş. Kurum kendi ders programını, sınavını, öğrenci ve veli kaydını, ödemesini kendi sınırının içinde tutuyor; bu kayıtları taşıyan işlevleri sıfırdan kurdurmuyor. Kurumun ilk günden itibaren kullandığı işlevler, çatıdaki diğer kurumların yıllardır kullandığı işlevlerle aynı.

Tanımın kapsamadığı şeyi de söylemek gerekiyor. Kiracı tanımı işlevleri açıyor, veriyi doldurmuyor. Kurum kendi ders programını yazmak, kendi öğrenci ve veli kaydını girmek, kendi sınav içeriğini kurmak zorunda. Çatıya katılan kurumun önündeki iş bu yüzden bir kurulum işi değil, kendi verisini kurma işi oluyor: birincisi yazılım tarafında bir proje, ikincisi kurumun kendi masasında duran bir hazırlık.

Ayrı kurulumlar mı, tek çekirdek mi: fark nerede birikir

Fark tek bir anda görünmüyor, zamanla birikiyor. Yedi kurumun ders programı, sınav, öğrenci, veli, ödeme ve raporlama işleyişi tek platformda duruyor ve orada yapılan her iş, yedi ayrı kuruluma dağılmak yerine tek yerde yaşıyor.

Veri sınırı tarafındaki fark da şurada: tek çekirdekte bir kurumun kaydı diğer kiracıya görünmüyor ve bu ayrılık fiziksel bir kopyayla değil, kaydın kiracı sınırıyla sağlanıyor. Ayrılığın kiracı sınırına dayanması, aşağıdaki tablodaki üç değişikliğin neden yeni bir kurulum doğurmadığını da açıklıyor.

Üç satırın anlattığı şey, birbirinden çok farklı üç değişikliğin aynı yerde karşılanabildiği: biri kurum katılımı, biri yeni bir araç, biri de bir kâğıt düzeninin değişmesi.

Tek çekirdek her durumda doğru cevap değil. Kiracıların işleyişi ortak yazılımın taşıyamayacağı kadar ayrışıyorsa çekirdek zorlanır; her kiracı için açılan istisna, tek kod tabanını yavaş yavaş birbirine benzemeyen parçalara böler. Vipkurum’da yedi kurumun tamamı eğitim alanında çalıştığı için bu ortaklık gerçek: ders programı, sınav ve ödeme her kurumda aynı şeyi anlatıyor. Birbiriyle ilgisiz iş alanlarını aynı çekirdeğe zorlamak bu vakanın önerdiği şey değil. Çok şubeli ve çok kurumlu yapıları tek çekirdekte toplarken ilk baktığımız şey teknoloji olmuyor; kurumların işleyişinin gerçekten örtüşüp örtüşmediği oluyor.

Çekirdeğe eklenen araç neden ayrı kurulum gerektirmez

Çatının taşıdığı şey yalnız kurumlar değil. Çekirdeğe sonradan eklenen araçlar da aynı dağıtım biçimini kullanıyor. Vipkurum çatısı altında iki araç geliştirildi: soru kırpma ve optik okuma. İkisi de ayrı birer ürün olarak kurulup dağıtılmadı.

Çekirdeğe bir kez eklenip her kuruma ayrı kurulum yapılmadan açılan soru kırpma aracında Python görüntü işleme servisi Node.js üzerinden Laravel tarafındaki içerik yönetimine bağlanıyor. Araç çekirdeğe bir servis olarak eklendi; yanına ikinci bir sistem kurulmadı. Bunun kullanıcı tarafındaki karşılığı sade: kurumun içerik hazırlayan kişisi bu işi zaten kullandığı yerden yapıyor, ikinci bir yere geçmiyor.

Her kiracının kendi verisi üstünde, ikinci bir kurulum olmadan çalışan optik okuma aracında formlar tarayıcıdan yükleniyor ve sonuçlar Laravel tarafında MySQL kaydına yazılıyor. Cevap anahtarı ile öğrencinin işaretlemesi aynı sınav kaydında buluşuyor. Araca erişim ayrı bir kurulumdan değil, sistemin kendi web yüzünden geliyor.

Ayrı birer ürün olsalardı ne değişirdi? Her kurum aracı ayrıca edinirdi ve aracın ürettiği sonucu kendi sınav kaydına taşımak için bir aktarım adımı gerekirdi. Aktarım adımı da elle yapılan her adım gibi kendi hata payını yanında getirirdi. Araç çekirdeğin bir katmanı olduğunda sonuç zaten kaydın içinde oluşuyor.

Buradan çıkan soru, çatıya kimin katılacağından çok neyin katılacağı. Bir kurum çekirdeğe kiracı olarak katılıyor, bir araç servis olarak. İkisinde de sorulan şey aynı: bu parça ortak yazılımın taşıdığı tanımların içine sığıyor mu, yoksa kendi kurulumunu mu istiyor? Cevap ilkiyse katılım bir kayıt işlemine iniyor. Cevap ikincisiyse tek çekirdek zaten yanlış sorunun cevabıdır ve o parçayı zorla içeri almak, yukarıdaki karşı durumu kendi elinle üretmek olur.