Linux hizmetlerini Delphi ile işletmek: Şirketler için Mimari, İşletim ve Uygulama Kılavuzu

Linux-Services ile Linux-Services Delphi işletmek isteyenler ilk olarak teknik uygulanabilirliği düşünür: Uygulama Linux için derleniyor mu? Kararlı çalışıyor mu? Bunlar önemli sorular — ancak kurumsal işletmede başarının belirleyicisi nadiren ilk başlatma, daha çok sonrasındaki gündelik işletmedir: kesintisiz güncellemeler, yeniden üretilebilir dağıtımlar, izlenebilir loglar, net sorumluluklar, temiz güvenlik varsayılanları ve mevcut Linux işletme modeline entegre olabilen bir hizmet modeli.

Delphi birçok şirkette tarihsel olarak oluşmuştur — çoğunlukla masaüstüne yakın iş yazılımları olarak, bazen de entegrasyon veya arka uç bileşeni şeklinde. Linux tabanlı servislerine geçiş (ör. REST-API’ler, otomasyon, veri hazırlama veya entegrasyonlar için) sıklıkla bir „yeni inşa“ değil, bir modernizasyon yoludur: Mantığın bazı parçaları istemciden ayrılır, arayüzler stabil hale getirilir ve işletme daha güçlü şekilde standardize edilir. Tam da bu noktada işletme boyutları üzerinde erken konuşmak faydalıdır — Go-live öncesine bırakılmamalıdır.

Bu yazı, Delphi tabanlı bir servisin Linux altında tipik olarak nasıl işletildiğini, hangi mimari kararların işletmeyi kolaylaştırdığını ve uygulamada hangi takılma noktalarının ilgili olduğunu düzenler — odak IT yöneticileri, sistem yöneticileri ve teknik proje sorumluları içindir.

Neden kuruluşlarda Linux-Services — ve Delphi neden burada önemini korur

Linux birçok veri merkezinde ve bulut ortamında sunucu iş yükleri için standarttır. Bunun nedenleri arasında şunlar sayılabilir: tek tip işletme modeli (SSH, paket yönetimi, systemd), iyi oturmuş otomasyon (Ansible, Terraform-ortamları), net güvenlik yapı taşları (SELinux/AppArmor, systemd-Sandboxing) ve geniş bir izleme ile loglama ekosistemi desteği.

Delphi burada „alışılmadık“ değil; aksine kurumda zaten kapsamlı Delphi mantığı varsa sıkça pragmatik bir bileşendir. Bu mantığı tamamen yeniden uygulamak yerine servislere dönüştürmek veya tamamlamak genellikle daha mantıklıdır — örneğin bir REST-Server olarak, arka plan işlemesi (Batch/Queue Worker) şeklinde veya ERP, DMS ve diğer sistemler arasında bir entegrasyon servisi olarak.

Önemli olan bakış açısıdır: Delphi „karşıt“ olarak değil, bir Linux işletme modelinin içinde ele alınmalıdır. Burayı doğru planlayanlar, normal bir Linux servisi gibi davranan ve iyi yönetilebilen bir bileşen elde eder.

Delphi altında Linux: Çalışma zamanı modeli, bağımlılıklar, paketleme

İşletme açısından konu daha az dil ve IDE, daha çok eserlerdir: Hangi dosyalar dağıtılıyor? Hangi sistem kütüphaneleri gerekiyor? Çalışma zamanında hangi yapılandırmalar gerekli?

Binary, Yapılandırma, Veriler: net ayrım

Bir Windows- und Linux-Services için üç alanın temiz ayrımı belirleyicidir:

• Binary/Programdosyası: derlenmiş çalıştırılabilir dosya, ideal olarak sert kodlanmış yollar olmadan ve kurulum dizininde yazma izni olmadan.
• Konfigürasyon: Binary’den ayrı tutulmalı; örn. bir dosya olarak /etc/<service>/ içinde veya systemd tarafından yönetilen ortam değişkenleri (Environment-Variablen) şeklinde. Ortam değişkenleri işletmede genellikle daha pratiktir, çünkü ortam başına (Dev/Test/Prod) daha kolay değiştirilebilirler.
• Veri/Runtime: geçici dosyalar, önbellekler, PID/Socket dosyaları – genellikle /var/lib, /var/cache veya /run altında.

Bu ayrım akademik değildir: Bu, değiştirilemez dağıtımlar (ikili dosya „değiştirilemez“), daha temiz geri alma işlemleri ve sunucular arasında daha az fark (diff-drift) sağlar.

Bağımlılıklar ve Kütüphaneler: rastgele değil, bilinçli

İşletmede ortaya çıkan birçok sorun uygulamanın kendisinden değil, sistem kütüphanelerindeki farklılıklardan kaynaklanır. Pratikte bunu erken aşamada netleştirmeniz gerekir:

• Hangi Linux dağıtımları hedef platform olacak? (ör. Debian/Ubuntu vs. RHEL/Rocky)
• Hangi sürümler BT stratejisinde onaylanmış ve bunlar nasıl yamalanacaklar?
• Yerel bağımlılıklar nasıl belgelenecek ve doğrulanacak (Build-Pipeline, Smoke-Tests)?

Sağlam bir yaklaşım, servisleri tanımlı bir build ortamında derlemek ve çalışma zamanı ortamını buna göre uyarlamaktır. Alternatif olarak container işletimi (ör. Docker/Podman) çalışma zamanını standardize etmeye yardımcı olabilir — ancak bu durumda container operasyon modelinin (Images, Registry, Security-Scanning, kaynak limitleri) düzgün şekilde kurulması gerekir.

İşletme dayanağı olarak systemd: Service-Unit, Yeniden Başlatma Stratejisi, Kaynaklar

Modern Linux ortamlarında systemd standart servis yöneticisidir: Servisleri başlatır, izler, logları toplar (journald aracılığıyla) ve basit güvenlik ile kaynak kurallarını uygulayabilir. BT işletmesi için bu merkezi öneme sahiptir, çünkü tutarlı bir kontrol modeli sağlar.

Servis Tanımı: Başlatma, Durdurma, Yeniden Başlatma

Bir systemd biriminin yanıtlaması gereken en önemli sorular:

• Nasıl başlatılır? (yol, parametreler, çalışma dizini)
• Servis ne zaman „hazır“ sayılır? (ör. hemen vs. porta/socket’e başarılı şekilde bağlanıldıktan sonra)
• Hatalarda ne olur? (RESTart-Policy, gecikme, limitler)
• Hangi kullanıcı altında çalışır servis? (root yerine en az ayrıcalık ilkesi)

Özellikle yeniden başlatma stratejisi uygulamada kritiktir. Konfigürasyon hatasında yeniden başlatma döngüsüne giren bir servis yük ve log seli üretir. Başlangıç limiti gibi limitler ve net bir hata işleme mantığı faydalıdır: Bir zorunlu parametre eksikse servis temiz bir şekilde, anlaşılır bir mesajla sonlanmalı — „yarı başlatma“ yapmamalıdır.

Kaynaklar ve Kararlılık: Bellek, CPU, Dosya tanıtıcıları

systemd kaynakları sınırlayabilir (CPU payları, bellek sınırları, açık dosya sayısı). Bu, temiz yazılımın yerini almaz, ancak uç durumlara karşı bir korumadır. İşletmeden tipik noktalar:

• Dosya tanıtıcıları: Çok sayıda eşzamanlı bağlantı (HTTP, DB, soketler) durumunda limitler önemlidir.
• Bellek: Bellek sızıntıları veya kontrolden çıkmış önbellekler, limitler etkinse daha erken görünür hale gelir.
• Zaman aşımı süreleri: Başlatma ve durdurma zaman aşımı süreleri veritabanı migrasyonları, warm-up veya kapanış fazlarıyla uyumlu olmalıdır.

Yöneticiler için sınırlar içinde kalan bir servis, zamanla hostu dengesizleştirebilecek „kontrolsüz bir süreç“e göre çok daha kolay işletilir.

Linux servislerini Delphi ile işletmek: Servis tipleri ve tipik kullanım desenleri

Der Begriff „Service“ wird im Alltag unterschiedlich verwendet. Im Linux-Kontext sind vor allem drei Muster relevant, die sich betrieblich deutlich unterscheiden.

1) Lang laufender REST-Server

Ein REST-Server (Representational State Transfer, HTTP-basierte Schnittstelle) ist häufig das erste Ziel: vorhandene Business-Logik wird über eine API bereitgestellt, um Portale, Integrationen oder Automatisierungen anzubinden. Betrieblich wichtig sind:

• Port-Bindung und Reverse Proxy (z. B. Nginx/Apache) für TLS, Routing und ggf. Rate-Limiting.
• Health-Checks (Liveness/Readiness): Kann der Dienst Anfragen annehmen? Ist die Datenbank erreichbar?
• Request-Limits: Schutz vor zu großen Payloads und ungebremstem Parallelismus.

Ein REST-Server ist nicht nur „läuft“, sondern muss unter Last stabil reagieren, nachvollziehbar loggen und bei Teilstörungen (z. B. DB kurz nicht erreichbar) definiert degradieren.

2) Worker/Daemon für Hintergrundjobs

Hintergrundverarbeitung ist oft der bessere Start als ein API-Server: Dateien importieren, Reports erzeugen, Daten abgleichen, Schnittstellen synchronisieren. Solche Worker lassen sich gut entkoppeln, wenn eine Queue eingesetzt wird (Nachrichtenwarteschlange), z. B. über Datenbanktabellen, Message Broker oder Dateisystem-Spools.

Wichtige Betriebsaspekte:

• Idempotenz (Wiederholbarkeit): Ein Job darf bei Wiederholung keinen Schaden anrichten, z. B. doppelte Buchungen.
• Dead-Letter/Fehlerablage: Fehlgeschlagene Jobs werden separat abgelegt und sind auswertbar.
• Backpressure: Bei Rückstau muss klar sein, wie der Worker drosselt oder skaliert.

3) Timer-basierte Dienste

Periodische Aufgaben (z. B. alle 5 Minuten Export) werden unter Linux oft nicht mehr klassisch über Cron gelöst, sondern über systemd-Timer. Vorteil: zentrale Verwaltung, saubere Logs, Abhängigkeiten und einheitliches Fehlerhandling. Für Unternehmen ist das attraktiv, weil Cron-Jobs häufig „unsichtbar“ wachsen und schwer auditierbar sind.

Konfiguration im Betrieb: Secrets, Umgebungen, Versionierung

In Unternehmensumgebungen ist Konfiguration selten nur „eine Ini-Datei“. Sie ist ein Governance-Thema: Wer darf ändern? Wie werden Änderungen nachvollzogen? Wie werden Geheimnisse geschützt?

Konfigurationsquellen: Datei vs. Environment

Aus Betriebssicht ist eine Mischung üblich:

• Statische Defaults im Binary (z. B. Standard-Timeouts), die selten geändert werden.
• Environment-Variablen für pro-Umgebung-Parameter (DB-Host, Ports, Feature Flags). systemd kann diese zentral verwalten.
• Konfigurationsdateien für strukturierte Einstellungen, insbesondere wenn mehrere Werte logisch zusammengehören.

Wichtig ist, dass Konfiguration validiert wird: Bei Start sollte der Service alle Pflichtwerte prüfen und verständliche Fehler ausgeben, statt später in einem unklaren Zustand zu laufen.

Secrets: Passwörter, Tokens, Zertifikate

Geheimnisse gehören nicht in Git und nicht in Klartext-Konfiguration. Praktisch bewährte Optionen sind:

• systemd-Umgebungsdateien mit restriktiven Dateirechten und getrennten Zuständigkeiten.
• Secret-Stores (z. B. Vault-Ansätze) – abhängig von Ihrer Infrastruktur.

Wenn ein Delphi-Service externe APIs nutzt, ist Token-Rotation ein echtes Betriebsthema: Der Dienst muss Tokens ohne Neustart oder mit kontrolliertem Neustart übernehmen können.

Datenbankzugriff und Persistenz: Stabilität vor Komfort

Viele Delphi-basierte Services sind datengetrieben. Damit rückt der Datenbankzugriff ins Zentrum: nicht in dem Sinne, dass SQL „schön“ ist, sondern dass Verbindungen stabil sind, Timeouts richtig gesetzt werden und Fehlerzustände beherrscht werden.

FireDAC, PostgreSQL und Co.: Verbindungspooling, Timeouts, Fehlerbilder

Ob Sie PostgreSQL, MariaDB oder SQL Server anbinden: Im Betrieb zählen vor allem diese Punkte:

• Connection-Handling: Werden Verbindungen sauber geöffnet/geschlossen? Gibt es ein Pooling-Konzept oder zumindest klare Grenzen für parallele DB-Sessions?
• Timeouts: Netzwerk-Timeouts, Query-Timeouts, Lock-Wartezeiten – und eine nachvollziehbare Reaktion, wenn ein Timeout greift.
• Transaktionen: Klare Transaktionsgrenzen, insbesondere bei Worker-Jobs, um halbfertige Datenstände zu vermeiden.
• Migrationen: Datenbankschema-Änderungen müssen zu Deployments passen (vorwärtskompatibel, Rollback-Strategie).

Für IT-Verantwortliche ist entscheidend: Ein Service darf die Datenbank nicht „überraschen“. Das heißt: Lastspitzen kontrollieren, Queries beobachten, Indizes pflegen und Fehlerfälle (Locking, Deadlocks, Netzwerkunterbrechung) als Normalfall behandeln.

Datenhaltung im Service: Caches und temporäre Dateien

Wenn ein Service mit Dateien arbeitet (Import/Export/PDF/EDI), müssen Ablagen sauber gemanagt werden: definierte Verzeichnisse, Quotas, Aufräumstrategien, und ein Plan für Reprocessing. Temporäre Dateien sollten nicht „irgendwo“ entstehen, sondern im Betriebsmodell vorgesehen sein – inklusive Rechtekonzept.

Logging, Monitoring und Troubleshooting: ohne Telemetrie kein Betrieb

In der Praxis scheitern Services selten an „Programmfehlern“, sondern an fehlender Sichtbarkeit. Ein Service, der keine verwertbaren Logs produziert, kostet Betrieb und Fachbereich Zeit – besonders bei sporadischen Fehlern.

Logging-Strategie: strukturierte Events statt Textromane

Gute Logs sind:

• korrelierbar (z. B. Correlation-ID pro Request/Job, damit sich ein Vorgang durch alle Logzeilen verfolgen lässt),
• strukturiert (Schlüssel/Wert-Informationen, die sich filtern lassen),
• sparsam (keine sensiblen Daten, keine unnötigen Payloads),
• betrieblich verwertbar (klare Fehlermeldungen, Exit-Codes, nachvollziehbare Zustände).

Unter Linux ist das Zusammenspiel mit journald/systemd hilfreich, weil Start/Stop/RESTart und Prozessausgaben zentral zusammenlaufen. Für größere Umgebungen sollte ein Log-Forwarding (z. B. in zentrale Logsysteme) eingeplant werden.

Monitoring: Metriken, Health-Endpoints, Alarmregeln

Neben Logs braucht es Metriken. Typische Metriken, die sich im Betrieb bewähren:

• Anzahl Requests/Jobs pro Zeit
• Fehlerraten pro Endpoint/Jobtyp
• Durchlaufzeiten (Latency), getrennt nach externen Abhängigkeiten (DB, Fremd-API)
• Queue-Länge bzw. Rückstau
• Ressourcen: Speicher, CPU, offene Verbindungen

Wichtig ist weniger das Tool, sondern die Disziplin: Alarmregeln müssen zur Betriebsrealität passen. Ein Alarm, der ständig auslöst, wird ignoriert. Ein Alarm, der zu spät auslöst, hilft nicht.

Güvenlik und Hardening: Yetkiler, Netzwerk, Güncellemeler

Ein Windows- und Linux-Services ist ein dauerhaft erreichbarer Prozess – damit ist er Teil der Angriffsfläche. Die gute Nachricht: Linux und systemd bieten viele Mechanismen, um Dienste zu isolieren. Die schlechte Nachricht: Diese Mechanismen wirken nur, wenn sie bewusst genutzt werden.

Least Privilege: eigener Benutzer, minimale Rechte

Ein Service sollte unter einem eigenen Systembenutzer laufen, mit minimalen Dateirechten. Schreibzugriff nur auf die tatsächlich benötigten Verzeichnisse. Das reduziert Risiken bei Fehlern oder Kompromittierung.

Netzwerk-Schnittstellen: nur das Nötigste öffnen

Eine häufige Ursache für Security-Funde ist „zu viel Netzwerk“: Dienste binden an alle Interfaces, Datenbanken sind aus zu vielen Netzen erreichbar, Admin-Endpunkte sind nicht getrennt. Sinnvoll sind klare Regeln:

• API-Ports nur intern öffnen, extern nur über Reverse Proxy/WAF.
• Trennung von Public/Private Interfaces, ggf. separate Listener.
• Outbound-Verbindungen einschränken, wenn möglich.

Patch- und Updatefähigkeit: OS und Anwendung getrennt denken

Im Betrieb müssen zwei Update-Ströme zusammenspielen: Betriebssystem-Patches und Anwendungsreleases. Planen Sie dafür:

• Wartungsfenster oder Rolling-Update-Strategie
• kompatible Konfigurationen (keine „Handarbeit“ pro Server)
• Rollback-Fähigkeit (vorherige Version lauffähig, Datenbankmigrationen abgestimmt)

Gerade bei Services, die Geschäftsdaten bewegen, ist ein sauberes Release-Management wichtiger als „schnell deployen“.

Deployment-Strategien: von „kopieren und hoffen“ zu reproduzierbaren Releases

Viele gewachsene Delphi-Landschaften kennen den manuellen Deploy: Binary kopieren, Dienst neu starten, fertig. Unter Linux fällt das spätestens dann auf die Füße, wenn mehrere Instanzen, Umgebungen oder Teams beteiligt sind.

Reproduzierbarkeit: Build-Artefakt und Version müssen zusammenpassen

Ein betrieblich sauberes Setup hat:

• Versionierte Artefakte (Binary, Konfigurationsschema, ggf. Migrationsskripte)
• einen klaren Deploy-Mechanismus (Paket, Artefakt-Repository, Container)
• Smoke-Tests nach Deploy (Health-Check, einfache API-Requests, DB-Verbindung)

Das Ziel ist nicht „DevOps als Buzzword“, sondern weniger Ausfälle durch zufällige Unterschiede.

Rollback und Datenbankmigration: das oft übersehene Paar

Rollback ist leicht, solange sich nur das Binary ändert. Sobald das Datenbankschema migriert, wird es komplex: Ein altes Binary versteht ggf. neue Tabellen/Spalten nicht. In der Praxis bewähren sich:

• vorwärtskompatible Migrationen (erst neue Strukturen hinzufügen, später alte entfernen),
• Feature Flags für neue Logik,
• geplante Migrationsfenster für harte Schnitte.

Wenn Sie eine Delphi-Anwendung modernisieren (z. B. von monolithischem Desktop zu Service + Portal), ist dieses Zusammenspiel zentral. Hier entstehen die typischen Projektrisiken – und hier lohnt Architekturdisziplin.

Migration: Windows-Service nach Linux – wie man Risiken begrenzt

In vielen Unternehmen existieren bereits Windows-Services, die Daten verarbeiten oder Integrationen übernehmen. Die Migration nach Linux ist dann kein Technologieprojekt, sondern ein Betriebs- und Risikoprojekt.

Unterschiede im Betriebsmodell

• Service-Management: Windows Service Control Manager vs. systemd
• Logging: Event Log vs. journald/Dateilogs
• Dosya sistemi ve yollar: yol kavramları, izinler, büyük/küçük harf duyarlılığı
• Ağ ve DNS: diğer standart araçlar, farklı işletme rutinleri

Bu farklılıklar yönetilebilir, ancak kontrol listesine alınmalı — aksi takdirde işletmede „görünmez“ ek iş yükü oluşur.

Kademeli geçiş yerine Big Bang

Sıklıkla pratikte işe yarayan bir strateji:

1. Servisi ayırmak: net arayüzler, belirgin veri sorumluluğu, mümkün olduğunca doğrudan UI bağımlılıklarından kaçınma.
2. Observability uygulamak: Windows- ve Linux-servisleri üzerinde şimdiden logging/metrikleri iyileştirmek, böylece sonraki karşılaştırmalar mümkün olur.
3. Paralel işletim: Linux servisini başlangıçta gölge modunda veya işlerin/isteklerin bir kısmı için çalıştırma.
4. Geçiş yapmak: kontrollü cutover, geri dönüş planı ile.

Böylece bir platform değişikliğinin aynı anda süreç değişiklikleriyle çakışma riski azalır.

Günlük arayüz işletimi: Sözleşmeler, versiyonlama, hata toleransı

Bir servis genellikle bir entegrasyon zincirinin parçasıdır. Birden fazla sistem devreye girdiğinde (ERP, DMS, CRM, portallar), işletme bir koordinasyon işi haline gelir. Burada yardımcı olan, net API sözleşmeleri ve bir versiyonlama stratejisidir.

Versiyonlama: Değişiklikleri planlanabilir kılmak

API versiyonlaması demektir ki: eski istemciler aniden bozulmamalı. Pratikte bu şu anlama gelir:

• Geriye dönük uyumu bozan değişikliklerden kaçınmak veya bunları yalnızca yeni bir versiyonla dağıtmak
• Yanıt formatlarını geriye dönük uyumlu şekilde genişletmek (eski alanları yeniden adlandırmak yerine yeni alanlar eklemek)
• Kullanımdan kaldırma süreci (deprecation) için süreler belirlemek ve kullanımın izlenmesini sağlamak

Eğer Delphi-tabanlı REST uç noktalarını işletiyorsanız, bu işletme kalite boyutlarının en önemlilerinden biridir — çünkü komşu sistemlerdeki kesintileri doğrudan engeller. (İçerik açısından burada mevcut dahili yazılara REST mimarisi, hata işleme ve versiyonlama üzerine kolayca atıfta bulunulabilir.)

Hata kültürü: „bir şeyler ters gitti“ yerine tanımlanmış yanıtlar

İşletme ve iş birimleri için önemli olan, hataların net olmasıdır: HTTP durum kodları, hata anahtarları, izlenebilir loglar ve „İstemci Hatası“ (hatalı istek) ile „Sunucu Hatası“ (serviste veya bağımlılıklarda problem) arasındaki ayrım.

BT sorumluları için kontrol listesi: Canlıya geçmeden önce netleştirilmesi gerekenler

Son olarak, Delphi servisleri Linux altında üretime alındığında projelerde işe yarayan kompakt bir kontrol listesi:

• Service-Unit: yeniden başlatma politikası, zaman aşımı değerleri, başlatma limitleri, ayrı kullanıcı, veri yolları üzerindeki izinler
• Konfigürasyon: kaynak, doğrulama, ortamlar arasındaki ayrım, belgelenmiş varsayılanlar
• Secrets: depolama, izinler, rotasyon, sertifika süreleri
• Logging: korelasyon, yapılandırılmış alanlar, merkezi toplama, veri koruma (hassas içerikler olmamalı)
• Monitoring: health-check’ler, metrikler, alarm kuralları, işletme için gösterge paneli
• Veritabanı: zaman aşımları, işlemler, havuzlama/limitlendirme, migrasyon planı ve geri alma
• Deployment: versiyonlanmış artefaktlar, tekrarlanabilir süreç, smoke-testler
• Security: portlar, reverse proxy/TLS, sertleştirme, yama süreci
• İşletme devri: runbook (başlat/durdur, tipik hata senaryoları, log yerleri), sorumluluklar

Sonuç: Başarı işletme modelindedir, ilk çalıştırmada değil

Linux hizmetlerini Delphi üzerinde çalıştırmak, birçok kurumsal ortamda oluşmuş mantığı kararlı, iyi entegre edilebilir bir Backend-Komponente olarak sunmanın akılcı bir yoludur. Belirleyici olan, servisin bir Linux servisi gibi işletilmesidir: kontrol merkezi olarak systemd, net bir Konfigurations- und Secret-Strategie, temiz Logging- und Monitoring-Signale ve yeniden üretilebilir, geri alınabilir Deployments.

Eğer mevcut bir Delphi ortamını adım adım REST servisleri, Worker’lar ve Linux üzerindeki entegrasyon bileşenleri yönünde geliştirmek istiyorsanız, erken bir mimari ve işletim workshop’u faydalıdır: Schnittstellen, Datenflüsse, Security und Betrieb birlikte ele alınır – ve geliştirmeden sonra „drangebaut“ edilmez.

Bunun için ortamınız hakkında teknik bir değerlendirme isterseniz, yapılandırılmış bir başlangıç için iletişim kanalı en hızlı yoldur:

Uzmanlık bağlamında entegrasyonlar, veri akışları ve devam eden geliştirme düzgün şekilde birlikte çalışmak zorundaysa, Delphi Linux servisi ve systemd servisi de önemli bir rol oynar.

Proje veya modernizasyon girişimini Net-Base ile görüşün.