Monolitik Mimari Nedir?

Monolitik mimari, geleneksel yazılım geliştirme süreçlerinde en sık tercih edilen mimari yaklaşımlardan biridir. Bu mimaride, bir uygulamanın tüm bileşenleri tek bir kod tabanında toplanır ve tek bir bütün olarak çalışır. Kullanıcı arayüzünden iş mantığına, veri tabanı erişiminden üçüncü taraf entegrasyonlara kadar tüm bileşenler aynı proje içinde yer alır.

Bu yaklaşım, özellikle projelerin başlangıç aşamasında hızlı geliştirme ve yönetim kolaylığı sağlar. Günümüzde birçok legacy proje, monolitik mimari ile geliştirilmiş ve uzun yıllardır bu yapı üzerinde kullanıcılarına hizmet vermektedir. Monolitik mimari, ilk bakışta basitliği ve sadeliği ile öne çıkarken, büyük ölçekli projelerde yönetim ve ölçeklenebilirlik açısından bazı zorluklar yaratabilir.

Monolitik mimarinin önemli bir özelliği, tüm iş kurallarının, veri işlemlerinin ve kullanıcı arayüzlerinin tek bir yerde toplanmasıdır. Bu, başlangıçta hızlı bir geliştirme süreci sağlasa da, proje büyüdükçe karmaşıklığın artmasına neden olabilir. Ancak doğru tasarım prensipleri uygulandığında, monolitik mimari hala etkili ve sürdürülebilir bir çözüm sunabilir.

Monolitik Mimarinin Avantajları

Monolitik mimari, yazılım projelerinde basitlik ve hızlı ilerleme sağlayan birçok avantaja sahiptir. Bu avantajlar, özellikle küçük ekipler veya sınırlı kaynaklarla çalışan projelerde oldukça cazip hale gelir. Monolitik mimarinin sunduğu temel avantajlar bahsedecek olursak:

1. Hızlı Başlangıç ve Geliştirme
   Monolitik mimaride tüm bileşenler tek bir projede toplandığı için yeni bir projeye başlamak son derece kolaydır. Geliştiriciler, farklı servisler veya sistemler arasında iletişim kurma gereksinimi olmadan çalışabilir, bu da geliştirme sürecini hızlandırır.

2. Kolay Debug ve Test Süreçleri
   Monolitik mimaride, uygulamanın tüm bileşenlerinin tek bir kod tabanında bulunması sayesinde hata ayıklama ve test süreçlerini kolaylaştırır. Tek bir ortamda çalışan sistemde, hataların kaynağını bulmak ve çözmek daha az zaman alır.

3. Basit ve Etkili Deployment Süreçleri
   Monolitik mimaride uygulama, tek bir birim olarak deploy edilir. Mikroservislerdeki gibi bağımsız servislerin uyumunu sağlama veya farklı sürümleri yönetme zorunluluğu yoktur. Bu, deployment süreçlerini daha sade ve yönetilebilir hale getirir.

4. Dikey Ölçeklenebilirlik
   Monolitik mimaride, donanım gücünü artırarak dikey olarak (scale up, vertical scaling) ölçeklenebilir. Daha güçlü bir sunucuya geçiş yapmak, genellikle performansı artırmak için yeterli olur. Bu, özellikle düşük ve orta trafik seviyelerine sahip projeler için ideal bir çözümdür.

5. Birlikte Çalışabilirlik
   Tüm bileşenler aynı kod tabanında olduğu için, bileşenler arası entegrasyon son derece kolaydır. Geliştiriciler, herhangi bir servis arası iletişim protokolü veya API tasarımı ile uğraşmak zorunda kalmaz.

6. Eğitim ve Yeni Katılanlar İçin Kolaylık
   Yeni bir ekip üyesinin projeye adapte olması, monolitik mimarilerde genellikle daha kolaydır. Tüm kod tabanının bir yerde bulunması, yeni katılan birinin projeyi anlamasını ve katkıda bulunmasını hızlandırır.

Monolitik Mimarinin Dezavantajları

Her ne kadar monolitik mimari basitliği ve hızlı başlangıç avantajları sunsa da, büyük ve karmaşık projelerde bazı sınırlamalar ve zorluklar ortaya çıkabilir. İşte monolitik mimarinin dezavantajları:

1. Yönetim Zorlukları
   Proje büyüdükçe, kod tabanının karmaşıklığı artar. Bu durum, özellikle büyük ekiplerde çalışırken kodun yönetimini zorlaştırabilir. Herhangi bir değişiklik, tüm sistem üzerinde geniş çaplı etkiler yaratabilir.

2. Yeni Özellikler Eklemek Zorlaşır
   Kod tabanı büyüdükçe ve bağımlılıklar arttıkça, yeni bir özellik eklemek zaman alıcı ve karmaşık bir hal alabilir. Kodun bir bölgesinde yapılan değişiklikler, beklenmedik bir şekilde diğer bölgelere etki edebilir.

3. Teknoloji Bağımlılığı
   Monolitik mimariler genellikle belirli bir programlama dili veya framework ile geliştirilir. Bu durum, yeni teknolojileri entegre etmeyi zorlaştırır. Örneğin, bir projeyi tamamen farklı bir dil veya framework'e geçirmek neredeyse imkansız olabilir.

4. Ölçeklenebilirlik Sorunları
   Monolitik mimariler dikey olarak ölçeklenebilir olsa da, bu yöntem yüksek trafik seviyelerinde yetersiz kalabilir. Yatay ölçekleme (Scale out, Horizontal Scaling) ise monolitik yapılarda oldukça karmaşıktır ve verimsizdir. Eğer yapı stateful bir yapıya sahipse, yatay ölçekleme neredeyse imkansız hale gelebilir.

5. Tek Nokta Arızası (Single Point of Failure)
   Monolitik mimariye sahip bir uygulamada herhangi bir bileşende meydana gelen bir hata, tüm sistemin çökmesine neden olabilir. Mikroservis mimarisinde ise bu tür sorunlar genellikle sadece ilgili servisi etkiler.

6. Deployment Süreçlerindeki Riskler
   Monolitik mimariye sahip bir uygulamada, küçük bir değişiklik bile tüm sistemin yeniden deploy edilmesini gerektirir. Bu, büyük projelerde zaman kaybına yol açabilir ve hata yapma riskini artırabilir.

7. Ekiplerin Çalışma Şekline Uyumsuzluk
   Büyük ekiplerde, farklı özelliklerin aynı kod tabanında geliştirilmesi çakışmalara neden olabilir. Kod üzerinde aynı anda çalışan çok sayıda kişi, kod yönetimi sorunlarını ve entegrasyon zorluklarını beraberinde getirir.

Hangi Durumlarda Monolitik Mimari Kullanılabilir?

Monolitik mimari, her ne kadar büyük ve karmaşık projelerde bazı zorluklar ortaya çıkarsa da, belirli durumlarda hâlâ oldukça etkili bir mimari seçeneği olarak karşımıza çıkar. İşte monolitik mimarinin kullanılmasının uygun olduğu bazı senaryolar:

1. Küçük Ekipler ve Projeler
   Küçük ölçekli projeler ve sınırlı sayıda geliştiriciden oluşan ekipler için monolitik mimari, geliştirme sürecini basitleştirir ve hızlandırır. Bu tür projelerde karmaşık mikroservis altyapılarına ihtiyaç duyulmaz.

2. MVP (Minimum Viable Product) Geliştirme
   Yeni bir iş modeli veya ürün fikri test ediliyorsa, monolitik mimari hızlı bir başlangıç yapmak için mükemmel bir tercihtir. Ürün piyasaya çıktıktan ve doğrulandıktan sonra ihtiyaç duyulursa mikroservis mimarisine geçiş yapılabilir.

3. Hızlı Pazara Çıkış (Time-to-Market) İhtiyacı
   Rekabetin yüksek olduğu sektörlerde, bir ürünün pazara hızlı bir şekilde çıkması gerekebilir. Monolitik mimari, geliştirme ve deployment süreçlerini hızlandırarak zaman kazandırır.

4. Düşük Trafik ve Basit İşlevsellik
   Eğer bir uygulamanın kullanıcı kitlesi ve trafiği sınırlıysa, monolitik mimari teknik açıdan yeterli bir çözüm sunar. Bu tür projelerde, yatay ölçekleme gereksinimi olmadığı için monolitik yapı herhangi bir kısıtlama oluşturmaz.

5. Ekipte Mikroservis Deneyiminin Eksikliği
   Mikroservis mimarisi, ekipte derin bir bilgi birikimi ve deneyim gerektirir. Eğer ekipte bu deneyim yoksa, monolitik mimariyle başlamak daha doğru bir yaklaşım olacaktır. Ekip, proje ilerledikçe mimari bilgi birikimini artırabilir.

6. Yüksek Entegrasyon Gereksinimi Olmayan Projeler
   Bazı projeler, genellikle birbiriyle sıkı entegre çalışan modüllerden oluşur. Bu tür projelerde, mikroservislerin sağladığı esnekliğe ihtiyaç duyulmaz. Tüm sistemin tek bir kod tabanında yer aldığı monolitik mimari, bu tür projeler için uygundur.

7. Kısa Süreli ve Deneysel Projeler
   Deneysel veya geçici olarak geliştirilen projelerde, mikroservis altyapısı kurmak zaman ve kaynak israfına neden olabilir. Monolitik mimari, bu tür projelerde hızlı bir şekilde sonuç almak için idealdir.

Monolitik Mimari ile Tasarım Prensipleri

Daha öncede bahsettiğimiz gibi monolitik mimari, tüm bileşenlerin tek bir yapı içinde toplandığı bir yazılım geliştirme yaklaşımıdır. Bu yapıda, tasarım prensiplerine uyum, büyüyen projelerde yönetilebilirliği korumak, kodun bakımını kolaylaştırmak ve uzun vadede sürdürülebilir bir sistem yaratmak için kritik bir öneme sahiptir.

Tasarım prensipleri, bir yazılım projesinde düzen, sadelik ve esneklik sağlamak için kullanılan rehberlerdir. Monolitik mimari gibi büyük ve sıkı bağlı yapılarda bu prensiplerin uygulanması, projenin karmaşıklığını azaltır ve uzun vadeli faydalar sağlar.

Aşağıda, monolitik mimariyle ilişkili olarak dört önemli tasarım prensibini ele alacağız:

• KISS (Keep It Simple, Stupid)

• DRY (Don't Repeat Yourself)

• YAGNI (You Aren't Gonna Need It)

• Separation of Concerns (SoC)

1. KISS (Keep It Simple, Stupid)

KISS (Keep It Simple, Stupid) prensibi, tasarım veya yazılım geliştirme süreçlerinde gereksiz karmaşıklıktan kaçınılması gerektiğini vurgulayan bir prensiptir. Amacı, sistemlerin veya yazılımların daha kolay anlaşılabilir, daha az hata barındıran ve daha kolay bakım yapılabilir olmasını sağlamaktır.

Monolitik mimarilerde, tüm bileşenler tek bir yerde toplandığı için karmaşıklık hızlı bir şekilde artabilir. KISS prensibi, kodu ve sistemi olabildiğince basit tutarak bu karmaşıklığı kontrol altında tutar.

Temel İlkeler:

1. Basitlik Önemlidir: Karmaşık çözümler, daha fazla hata ve bakım zorluğu yaratır.

2. Doğal Çözümler Tercih Edilmelidir: Sorunu çözmek için en az bileşene sahip en etkili çözüm seçilmelidir.

3. Kodun ve Tasarımın Kolay Anlaşılabilir Olması: Ekip arkadaşları ve hatta gelecekteki siz için kolay okunabilir kod yazılmalıdır.

4. Karmaşıklıktan Kaçın: Gereksiz özellik eklemeleri, gereksiz soyutlamalar ve aşırı mühendislikten uzak durulmalıdır.

Neden Önemlidir?

• Daha hızlı geliştirme süreçleri sağlar.

• Bakımı kolay bir sistem ortaya çıkarır.

• Yeni ekip üyelerinin sisteme daha hızlı adapte olmasına yardımcı olur.

• Karmaşık sistemlerdeki hataları çözmek için harcanan süreyi azaltır.

Örnek

Bu kod örneği, yalnızca dikdörtgen ve daire alanını hesaplamak gibi basit bir problem için gereksiz soyutlama ve aşırı mühendislik barındırmaktadır. Bu durum kodun hem anlaşılabilirliğini hem de bakımını zorlaştırmaktadır.

using System;

public abstract class Shape
{
    public abstract double Area();
}

public class Rectangle : Shape
{
    private double width;
    private double height;

    public Rectangle(double width, double height)
    {
        this.width = width;
        this.height = height;
    }

    public override double Area()
    {
        return width * height;
    }
}

public class Circle : Shape
{
    private double radius;

    public Circle(double radius)
    {
        this.radius = radius;
    }

    public override double Area()
    {
        return Math.PI * Math.Pow(radius, 2);
    }
}

public class ShapePrinter
{
    public void PrintArea(Shape shape)
    {
        if (shape is Rectangle)
        {
            Console.WriteLine($"Rectangle area: {shape.Area()}");
        }
        else if (shape is Circle)
        {
            Console.WriteLine($"Circle area: {shape.Area()}");
        }
        else
        {
            Console.WriteLine("Unknown shape");
        }
    }
}

public class Program
{
    public static void Main()
    {
        Shape rectangle = new Rectangle(5, 10);
        Shape circle = new Circle(7);

        ShapePrinter printer = new ShapePrinter();
        printer.PrintArea(rectangle);
        printer.PrintArea(circle);
    }
}

Aşağıdaki kod ise aynı problemi daha sade ve doğrudan bir şekilde çözer. Bu yaklaşım, hem daha hızlı bir şekilde anlaşılır hem de daha az kodla aynı sonucu üretir.

using System;

public class Program
{
    public static double RectangleArea(double width, double height)
    {
        return width * height;
    }

    public static double CircleArea(double radius)
    {
        return Math.PI * Math.Pow(radius, 2);
    }

    public static void Main()
    {
        double rectangleArea = RectangleArea(5, 10);
        double circleArea = CircleArea(7);

        Console.WriteLine($"Rectangle area: {rectangleArea}");
        Console.WriteLine($"Circle area: {circleArea}");
    }
}

Bu sade çözüm ile KISS prensibinin gereksiz soyutlamalardan ve karmaşıklıktan kaçınma ilkesini tam anlamıyla uygularız. Bu sayede kodun hem anlaşılabilirliği hem de bakımı kolaylaşır.

2. DRY (Don't Repeat Yourself)

DRY (Don't Repeat Yourself) prensibi, yazılım geliştirme süreçlerinde tekrar eden kodları önlemek ve kodun tekrar kullanılabilirliğini artırmayı amaçlayan bir tasarım ilkesidir. Bu prensip, bir bilgiyi veya işlevi kodda yalnızca bir kez tanımlamayı hedefler. DRY, yazılım projelerinde bakım ve genişletme sırasında karşılaşılabilecek hataları azaltarak, daha verimli bir geliştirme süreci sağlar.

Temel İlkeler:

1. Tek Sorumluluk Alanı: Her bilgi veya işlev kodda yalnızca bir kez tanımlanmalıdır.

2. Kodun Merkezi Olması: Aynı işlevi gerçekleştiren kod parçaları tek bir yerde toplanmalı ve gerektiğinde yeniden kullanılmalıdır.

3. Kolay Bakım: Kodda değişiklik gerektiğinde, yalnızca bir yeri değiştirmek yeterli olmalıdır.

4. Doğru soyutlama seviyesi bulun: Gereksiz yere her şeyi bir fonksiyona taşımak yerine, yalnızca tekrar eden işlevleri soyutlanmalıdır.

5. Kodun anlaşılabilirliğini koruyun: DRY prensibini uygularken kodun okunabilirliğini azaltmaktan kaçınılmalıdır.

6. İhtiyaç duydukça uygula (YAGNI): Henüz ihtiyaç olmayan soyutlamalar yapmaktan kaçınılmalıdır.

Neden Önemlidir?

• Kodun Kolay Yönetimi: Aynı kodu farklı yerlerde değiştirmek yerine yalnızca bir yeri düzenlersiniz.

• Daha Az Hata: Bir hatayı düzeltmek için yalnızca tek bir yere odaklanmak yeterlidir.

• Yeniden Kullanılabilirlik: İşlevsellik tek bir yerde tanımlandığında, farklı projelerde veya kod bölümlerinde kolayca tekrar kullanılabilir.

• Daha Az Karmaşıklık: Kodda tekrar eden bölümler olmadığında, kod daha temiz, anlaşılır ve yönetilebilir hale gelir.

Monolitik mimarilerde, kodun tekrar eden bölümleri projeler büyüdükçe karmaşıklığı artırır ve bakımı zorlaştırır. DRY prensibi, bu tekrarları azaltarak kodun sürdürülebilirliğini ve genişletilebilirliğini sağlar. Özellikle büyük ekiplerin çalıştığı projelerde, tekrar eden kod parçalarını ortadan kaldırarak ekipler arası uyumu artırır ve sürüm yönetimini kolaylaştırır.

Örnek

Bu kod örneği, üç farklı dikdörtgenin alanını hesaplamak için her bir dikdörtgenin boyutlarına özel ayrı hesaplama işlemleri yapılmış. Bu tekrar eden kod parçaları, hem okunabilirliği azaltmış hem de kodun bakımını zorlaştırmıştır. DRY prensibini ihlal eden bu tür yapılar, değişiklik gerektiğinde hatalara yol açabilir ve geliştirme sürecini karmaşık hale getirebilir.

using System;

public class Program
{
    public static void Main()
    {
        double length = 5;
        double width = 10;
        double area1 = length * width;
        Console.WriteLine($"Rectangle 1 area: {area1}");

        double length2 = 7;
        double width2 = 3;
        double area2 = length2 * width2;
        Console.WriteLine($"Rectangle 2 area: {area2}");

        double length3 = 6;
        double width3 = 8;
        double area3 = length3 * width3;
        Console.WriteLine($"Rectangle 3 area: {area3}");
    }
}

Çözüm olarak, tekrar eden kod parçalarını tek bir fonksiyona taşıyarak, DRY prensibine uygun bir yapı elde edebiliriz. Aşağıdaki örnekte CalculateRectangleArea adında bir metod tanımlanmış ve tüm alan hesaplamaları bu metod üzerinden gerçekleştirilmiştir. Bu yaklaşım sayesinde, kod daha temiz, modüler ve sürdürülebilir hale gelmiştir. Artık alan hesaplama mantığında bir değişiklik gerektiğinde, yalnızca bu metod üzerinde çalışmak yeterli olacaktır. Ayrıca, metodu tekrar kullanarak kodun farklı bölümlerinde de aynı işlemleri kolaylıkla gerçekleştirebiliriz.

using System;

public class Program
{
    public static double CalculateRectangleArea(double length, double width)
    {
        return length * width;
    }

    public static void Main()
    {
        double area1 = CalculateRectangleArea(5, 10);
        Console.WriteLine($"Rectangle 1 area: {area1}");

        double area2 = CalculateRectangleArea(7, 3);
        Console.WriteLine($"Rectangle 2 area: {area2}");

        double area3 = CalculateRectangleArea(6, 8);
        Console.WriteLine($"Rectangle 3 area: {area3}");
    }
}

DRY prensibinin uygulanmasıyla elde edilen bu sadeleştirilmiş yapı, hem hata yapma olasılığını azaltır hem de uzun vadede bakım ve genişletme maliyetlerini düşürür.

3. YAGNI (You Aren't Gonna Need It)

YAGNI (You Aren’t Gonna Need It), yazılım geliştirme süreçlerinde gereksiz özelliklerin veya işlevlerin önceden eklenmemesi gerektiğini savunan bir prensiptir. Genellikle Agile yöntemlerinde kullanılan bu prensip, şunu vurgular:

"Şu anda ihtiyaç duyulmayan bir özellik için kod yazmayın. İhtiyaç doğduğunda ekleyin."

Bu yaklaşım, aşırı mühendislik ve gereksiz karmaşıklığın önüne geçmeyi hedefler. YAGNI, KISS (Keep It Simple, Stupid) prensibiyle uyumlu olarak çalışır ve MVP (Minimum Viable Product) yaklaşımını destekler.

Temel İlkeler:

1. Mevcut İhtiyaca Odaklanın: Yalnızca şu anda gerekli olan özellik veya işlevleri geliştirilmelidir. Gelecekte gerekebilecek özellikler için zaman harcanmamalıdır.

2. Agile Yöntemleri Benimseyin: Yazılım iteratif bir şekilde geliştirilmeli ve yalnızca gerçekten ihtiyaç duyulduğunda yeni özellikler eklenmelidir.

3. Aşırı Mühendislikten Kaçının: Henüz kullanılmayacak soyutlamalar veya işlevler eklemekten kaçınılmalıdır.

4. Kodun Basitliğini Koruyun: Geliştirme sürecinde kodun anlaşılabilirliğini artırmaya öncelik verilmelidir.

5. İhtiyaca Göre Geliştirme: Gelecekteki belirsiz ihtiyaçları tahmin etmek yerine, mevcut gereksinimlere odaklanarak kaynakları verimli kullanılmalıdır.

Neden Önemlidir?

• Gereksiz Çaba ve Kaynak İsrafını Önler: Şu anda kullanılmayacak bir özellik için zaman ve enerji harcanmaz.

• Kodun Karmaşıklığını Azaltır: Gereksiz işlevler ve soyutlamalar kodun anlaşılabilirliğini zorlaştırır. YAGNI, yalnızca gerekli olanı geliştirerek bu karmaşıklığı ortadan kaldırır.

• Hataları Azaltır: Kullanılmayan veya nadiren kullanılan özellikler genellikle hatalara sebep olur. Bu özelliklerin eklenmemesi, yazılımın daha kararlı olmasını sağlar.

• Zaman ve Kaynak Tasarrufu Sağlar: Geliştirme süresi kısalır ve ekip kaynakları daha verimli bir şekilde kullanılır.

• MVP ve Agile Yaklaşımlarını Destekler: Ürünü hızlı bir şekilde piyasaya sürmek ve kullanıcıdan geri bildirim almak için yalnızca temel özelliklerin geliştirilmesi gerektiğini vurgular.

Monolitik mimarilerde, gelecekteki potansiyel ihtiyaçları karşılamak adına eklenen gereksiz işlevler ve özellikler, kodun karmaşıklığını artırır ve geliştirme sürecini uzatır. Bu durum, bakım süreçlerini de zorlaştırır. YAGNI prensibi, monolitik yapılarda yalnızca mevcut ihtiyaçlara odaklanarak bu sorunların önüne geçer. Özellikle MVP geliştirme aşamasında, YAGNI sayesinde kodun basitliği korunur ve uygulamanın daha hızlı bir şekilde kullanıma sunulması sağlanır.

Örnek

Bu örnekte, yalnızca ABD kullanıcılarına satış yapılan bir alışveriş uygulamasında, gelecekte Avrupa ülkelerine genişleme planlanarak şimdiden döviz dönüşümü gibi özellikler kodlanmıştır. Bu, YAGNI prensibini ihlal eder çünkü şu anda bu özellikler ihtiyaç değildir. Bu yaklaşım:

• Kodun karmaşıklığını gereksiz yere artırır.

• Kullanılmayan özelliklerin bakımını zorlaştırır.

• Gelecekte yapılacak değişikliklerde hata riskini artırır.

using System;
using System.Collections.Generic;

public class CurrencyConverter
{
    public double ConvertToCurrency(double amount, string targetCurrency)
    {
        var conversionRates = new Dictionary<string, double>
        {
            { "USD", 1.0 },
            { "EUR", 0.85 },
            { "GBP", 0.75 }
        };

        if (conversionRates.ContainsKey(targetCurrency))
        {
            return amount * conversionRates[targetCurrency];
        }
        else
        {
            throw new ArgumentException("Unsupported currency");
        }
    }
}

public class Program
{
    public static void Main()
    {
        CurrencyConverter converter = new CurrencyConverter();

        double productPriceInUSD = 100.0;
        Console.WriteLine($"Price in USD: {productPriceInUSD}");

        // Henüz ihtiyaç yokken EUR ve GBP dönüşümü yapılmış
        double priceInEUR = converter.ConvertToCurrency(productPriceInUSD, "EUR");
        Console.WriteLine($"Price in EUR: {priceInEUR}");

        double priceInGBP = converter.ConvertToCurrency(productPriceInUSD, "GBP");
        Console.WriteLine($"Price in GBP: {priceInGBP}");
    }
}

Çözüm olarak, gereksiz özellikleri sağlayan kod parçaları kaldırılmış ve yalnızca mevcut ihtiyaca odaklanılmıştır. USD fiyatlarının gösterilmesi, uygulamanın mevcut gereksinimlerini tamamen karşılamakta ve kodun sadeliğini korumaktadır. Bu yaklaşım:

• Kodun anlaşılabilirliğini artırır.

• Geliştirme süresini ve bakım maliyetlerini azaltır.

• Gelecekte eklenmesi gereken özellikler için esneklik sağlar.

using System;

public class Program
{
    public static void Main()
    {
        double productPriceInUSD = 100.0;
        Console.WriteLine($"Price in USD: {productPriceInUSD}");

        // Şu anda yalnızca USD fiyatlarını göstermek yeterlidir
    }
}

4. Separation of Concerns (SoC)

Separation of Concerns (SoC), yazılım geliştirmede her bir yazılım bileşeninin (modülün, sınıfın, katmanın, vb.) yalnızca tek bir sorumluluğa odaklanmasını sağlayan bir prensiptir. Amaç, yazılımı modüler, bakımı kolay ve yeniden kullanılabilir hale getirmektir. Bu prensip, düşük bağlılık (low coupling) ve yüksek bağlılık (high cohesion) ilkelerine dayanır.

Temel İlkeler:

1. Tek Sorumluluk İlkesi (Single Responsibility Principle - SRP): Her modül veya sınıf yalnızca bir işlevi yerine getirmelidir. Örneğin: Bir sınıf hem kullanıcı arayüzüyle hem de veritabanıyla ilgileniyorsa, bu SoC'yi ihlal eder. Bu durum kod karmaşıklığını artırır ve bakımı zorlaştırır.

2. Soyutlama (Abstraction): Katmanlar arasında net soyutlamalar yapılmalıdır. Bu, bir katmanda yapılan değişikliklerin diğer katmanları etkilemesini engeller. Örneğin, veritabanı katmanını değiştirdiğinizde kullanıcı arayüzünün etkilenmemesi gerekir.

3. Bağımsızlık (Independence): Bileşenler birbiriyle mümkün olduğunca az iletişim kurmalı ve bağımsız çalışmalıdır. Örneğin, iş mantığı (business logic) katmanı, veri erişim (data access) katmanına doğrudan bağımlı olmamalıdır.

Neden Önemlidir?

• Bakımı Kolaylaştırır: Kodun bir bölümü üzerinde yapılan değişiklikler diğer bölümleri etkilemez. Bu, değişikliklerin daha güvenli ve hızlı bir şekilde uygulanmasını sağlar.

• Test Edilebilirliği Artırır: Her bir bileşen bağımsız olarak test edilebilir. Örneğin, veri erişim katmanındaki bir hatayı düzeltmek için kullanıcı arayüzünü test etmek gerekmez.

• Yeniden Kullanılabilirlik: Farklı projelerde veya uygulama bölümlerinde belirli modüller kolayca yeniden kullanılabilir.

• Kodun Anlaşılabilirliğini Artırır: Kod daha düzenli ve modüler hale gelir, bu da yeni ekip üyelerinin projeyi anlamasını kolaylaştırır.

Monolitik mimarilerde, tüm bileşenlerin (kullanıcı arayüzü, iş mantığı, veri erişimi) tek bir yerde toplanması, kodun bakımını ve yönetimini zorlaştırır. Özellikle ekip büyüdükçe, farklı modüller üzerinde çalışan ekiplerin çakışma ihtimali artar. SoC prensibi, bileşenleri işlevlerine göre ayırarak bu sorunları ortadan kaldırır.
Örneğin, bir e-ticaret uygulamasında sipariş oluşturma süreci şu şekilde organize edilebilir:

• Sunum Katmanı (Presentation Layer): Kullanıcıdan sipariş verilerini alır.

• İş Mantığı Katmanı (Business Logic Layer): Sipariş doğrulamalarını ve işlemlerini yönetir.

• Veri Erişim Katmanı (Data Access Layer): Sipariş verilerini veritabanına kaydeder.

Örnek

Bu örnekte, kullanıcıların sipariş oluşturma işlemini gerçekleştiren bir sınıf, hem kullanıcı girişlerini doğruluyor, hem iş mantığını yönetiyor, hem de veri tabanına veri kaydediyor. Bu, SoC prensibini ihlal eder çünkü tüm sorumluluklar tek bir sınıfta toplanmıştır.

using System;

public class OrderManager
{
    public void CreateOrder(string username, string password, int productId, int quantity)
    {
        // Kullanıcı doğrulama (UI sorumluluğu)
        if (username != "admin" || password != "password")
        {
            throw new UnauthorizedAccessException("Invalid credentials");
        }

        // İş mantığı (Business Logic sorumluluğu)
        if (quantity <= 0)
        {
            throw new ArgumentException("Quantity must be greater than zero");
        }

        // Veritabanına kayıt (Data Access sorumluluğu)
        Console.WriteLine($"Order created: ProductId={productId}, Quantity={quantity}");
    }
}

public class Program
{
    public static void Main()
    {
        OrderManager orderManager = new OrderManager();
        orderManager.CreateOrder("admin", "password", 1, 5);
    }
}

Neden SoC'yi İhlal Ediyor?

1. UI Sorumluluğu: Kullanıcı doğrulama işlemi, OrderManager sınıfında yapılmış.

2. Business Logic Sorumluluğu: İş mantığı (ör. quantity kontrolü) aynı sınıfta bulunuyor.

3. Data Access Sorumluluğu: Veritabanına kayıt işlemi de aynı sınıfın içinde tanımlanmış.

4. Bakım Zorluğu: Farklı sorumlulukların tek bir sınıfta toplanması, kodun bakımını ve genişletilmesini zorlaştırır.

Aşağıdaki çözüm, her sorumluluğu ayrı bir sınıfa ayırarak SoC prensibine uygun hale getirilmiştir.

using System;

public class AuthenticationService
{
    public bool Authenticate(string username, string password)
    {
        return username == "admin" && password == "password";
    }
}

public class OrderService
{
    public void ValidateOrder(int quantity)
    {
        if (quantity <= 0)
        {
            throw new ArgumentException("Quantity must be greater than zero");
        }
    }

    public void CreateOrder(int productId, int quantity)
    {
        Console.WriteLine($"Order created: ProductId={productId}, Quantity={quantity}");
    }
}

public class Program
{
    public static void Main()
    {
        // Kullanıcı doğrulama
        AuthenticationService authService = new AuthenticationService();
        if (!authService.Authenticate("admin", "password"))
        {
            throw new UnauthorizedAccessException("Invalid credentials");
        }

        // Sipariş oluşturma
        OrderService orderService = new OrderService();
        orderService.ValidateOrder(5);
        orderService.CreateOrder(1, 5);
    }
}

Monolitik ve Katmanlı Mimari (N-Layer Architecture)

Monolitik mimaride projeler büyüdükçe, kodun tek bir yapıda toplanması yönetimi zorlaştırır ve karmaşıklığı artırır. Her bir bileşenin aynı kod tabanında bulunması, yeni özellikler eklenirken veya bakım yapılırken hatalara ve uzun geliştirme sürelerine yol açabilir. İşte bu noktada, katmanlı mimari (N-Layer Architecture) devreye girer. Katmanlı mimari, kodun belirli sorumluluklara göre ayrılmasını sağlayarak hem yönetimi kolaylaştırır hem de Separation of Concerns (SoC) prensibine uygun bir yapı oluşturur. Peki, katmanlı mimarinin temel yapısı ve faydaları nelerdir?

Katmanlı Mimari Nedir?

Katmanlı mimari, bir yazılım uygulamasının belirli sorumluluklara göre ayrılmış katmanlar üzerinde çalıştığı bir tasarım modelidir. Bu modelde her bir katman, belirli bir işlevi yerine getirir ve diğer katmanlarla belirli bir bağımsızlık içinde çalışır. Genellikle kullanılan katmanlar şunlardır:

1. Presentation Layer (Sunum Katmanı):
   Kullanıcı arayüzünü ve kullanıcı etkileşimlerini yönetir. Örneğin: Web veya mobil arayüzler.
   Headless Architecture Senaryosunda:
   Eğer uygulama bir headless architecture ile tasarlanmışsa, bu katman bir kullanıcı arayüzü sunmaz. Bunun yerine, bir API noktası (örneğin, REST API, GraphQL, gRPC) aracılığıyla istemci (client) uygulamalarına hizmet eder. Bu durumda, istemci ile Sunum Katmanı arasındaki iletişim bu API'ler üzerinden gerçekleştirilir ve bu katman, kullanıcı etkileşimlerinin başladığı merkez noktası haline gelir.

2. Application Layer (Uygulama Katmanı):
   Uygulama Katmanı, iş mantığını ve kurallarını yöneten merkez katmandır. Kullanıcıdan gelen istekleri işler, doğrular ve diğer katmanlarla koordinasyonu sağlar.

3. Domain Layer (Alan Katmanı):
   İş mantığının kurallarını ve domain modellerini içerir. Bu katman, uygulamanın merkezi iş mantığını ve kurallarını temsil eder. İş mantığının geri kalan katmanlardan izole edilmesi bu katmanda sağlanır.

4. Infrastructure/Data Access Layer (Veri Erişim Katmanı):
   Bu katman, uygulamanın dış dünyayla etkileşimini sağlar. Örneğin:

   • Veritabanı işlemleri (SQL veya NoSQL veritabanları),

   • Üçüncü taraf API çağrıları,

   • Dosya sistemi erişimi.

Katmanlı Mimarinin Avantajları

• Kod Organizasyonu:
  Kodun farklı sorumluluklara göre ayrılması, büyüyen projelerde okunabilirliği ve yönetimi kolaylaştırır.

• Bağımsızlık:
  Katmanlar arasındaki düşük bağımlılık, ekiplere paralel çalışma imkanı tanır.

• Test Edilebilirlik:
  Her katmanın bağımsız olarak test edilebilmesi, geliştirme sürecini hızlandırır.

• Yeniden Kullanılabilirlik:
  İş mantığı veya veri erişim kodları, diğer projelerde veya modüllerde tekrar kullanılabilir.

• Sürdürülebilirlik:
  Proje büyüdükçe kodun düzenli kalmasını sağlar.

Katmanlı Mimarinin Dezavantajları

• Performans Sorunları:
  Katmanlar arasında sürekli veri geçişi, büyük projelerde performans kaybına yol açabilir.

• Yüksek Karmaşıklık:
  Küçük projelerde fazla katman kullanımı gereksiz bir karmaşıklık oluşturabilir.

• Çift Yönlü Bağımlılık Riski:
  Yanlış tasarımda, katmanlar arasında çift yönlü bağımlılıklar oluşabilir, bu da yönetimi zorlaştırır.

Monolitik mimarilerde, tüm kodun tek bir yapı içinde yer alması, projelerin büyüdükçe yönetimini zorlaştırır. Bu durumda, katmanlı mimari kullanılarak kod daha düzenli ve sürdürülebilir bir hale getirilebilir. Özellikle büyük ve karmaşık projelerde, katmanlı mimari olmadan tüm kodun tek bir yerde bulunması yönetimi imkânsız hale getirebilir.

Katmanlı mimari, sorumlulukların ayrılması ile şu faydaları sağlar:

• Kod daha düzenli bir şekilde organize edilir.

• Her katman kendi sorumluluğunu üstlenir ve diğer katmanlardan bağımsız olarak çalışabilir.

• Test edilebilir bir yapı ortaya çıkar, bu da geliştirme ve bakım süreçlerini kolaylaştırır.

• Ekipler arasında görev dağılımı daha verimli bir şekilde yapılabilir.

Örneğin, bir e-ticaret uygulamasında:

• Sunum Katmanı: Kullanıcı sipariş verir.

• Uygulama Katmanı: Sipariş doğrulaması yapılır.

• Domain Katmanı: İş mantıkları çalıştırılır.

• Veri Erişim Katmanı: Sipariş bilgileri veri tabanına kaydedilir.

Modüler Monolitik Mimari: Monolitik Yapıların Evrimi

Modüler Monolitik Mimari Nedir?

Modüler monolitik mimari, klasik monolitik mimarinin bir uzantısı olarak, büyük kod tabanlarının daha düzenli, sürdürülebilir ve yönetilebilir bir yapıya dönüştürülmesini sağlayan bir tasarım yaklaşımıdır. Geleneksel monolitik mimaride tüm bileşenler tek bir kod tabanında sıkıca bağlıyken, modüler monolitik mimaride kod tabanı belirli modüllere ayrılarak organize edilir. Her bir modül kendi sorumluluk alanına sahiptir ve diğer modüllerden bağımsız bir şekilde çalışabilir.

Modüler yapı sayesinde, monolitik mimarinin sağladığı basitlik ve hız gibi avantajlardan yararlanırken, kod tabanının karmaşıklığı daha iyi yönetilir ve sürdürülebilirlik artırılır.

Monolitik Mimari ile İlişkisi

Klasik monolitik mimari, tüm uygulamanın tek bir kod tabanında birleştirildiği bir yapıdır. Modüler monolitik mimari ise bu yapıyı daha düzenli hale getirerek, uygulamanın farklı parçalarını işlevlerine göre modüller halinde organize eder. Ancak bu modüller yine tek bir kod tabanı ve deploy birimi içinde yer alır.

Bu yapı, klasik monolitik mimarinin sadeliğini korurken, büyük ve karmaşık projelerde karşılaşılan yönetim ve ölçeklenebilirlik sorunlarına çözüm getirir.

Neden Modüler Monolitik Mimari?

1. Karmaşıklığı Yönetir:
   Kod tabanı büyüdükçe karmaşıklık artar. Modüler yapı, bu karmaşıklığı işlevlere göre ayrıştırarak yönetimi kolaylaştırır.

2. Bağımsız Geliştirme ve Test:
   Modüller bağımsız olarak geliştirilebilir ve test edilebilir. Bu, ekiplerin paralel çalışmasını sağlar.

3. Mikroservislere Geçiş İçin Temel:
   Modüller, bağımsız mikroservislere dönüştürülebilecek şekilde tasarlanabilir. Bu sayede, mikroservislere geçiş daha az maliyetli ve daha hızlı bir şekilde gerçekleştirilebilir.

4. Kod Tekrarını Azaltır:
   Ortak işlevler modüller içinde merkezi olarak yönetilir ve kod tekrarı önlenir.

5. Sürdürülebilirlik:
   Modüler yapı, uzun vadeli projelerde kod tabanının sürdürülebilirliğini artırır ve bakımı kolaylaştırır.

Nasıl Bir Fayda Sağlar?

Monolitik mimarilerde büyüyen projeler, genellikle kod tabanının karmaşıklığını artırır ve geliştirme sürecini yavaşlatır. Modüler monolitik mimari, bu sorunları çözmek için etkili bir araçtır. Kodun daha düzenli olması, ekiplerin farklı modüller üzerinde bağımsız çalışmasını sağlar ve büyük projelerin daha kolay yönetilmesine olanak tanır.

Monolitikten Mikroservise Geçiş: Süreç ve Prensipler

Neden Mikroservislere Geçiş?

Modüler monolitik mimari, belirli bir ölçekte etkili olsa da, çok büyük ölçekli projelerde bazı sınırlamalarla karşılaşabilir. Özellikle aşağıdaki durumlarda mikroservislere geçiş bir gereklilik haline gelebilir:

• Bağımsız Ölçeklenebilirlik: Her modülün farklı trafik ve yük gereksinimleri olabilir. Mikroservisler, her modülü ayrı ayrı ölçeklendirme imkanı sunar.

• Teknoloji Çeşitliliği: Farklı modüllerin farklı teknolojilerle geliştirilmesi gerekiyorsa, mikroservis mimarisi bu çeşitliliği destekler.

• Bağımsız Geliştirme ve Dağıtım: Mikroservisler, farklı ekiplerin bağımsız olarak geliştirme yapabilmesine ve sadece ilgili servislerin dağıtımına olanak tanır.

• Yüksek Karmaşıklık: Çok büyük ve karmaşık monolitik yapılarda, değişiklik yapmak ve hataları çözmek zorlaşabilir. Mikroservisler, bu karmaşıklığı izole eder.

Geçiş Sürecindeki Zorluklar

Monolitikten mikroservislere geçiş karmaşık bir süreçtir ve dikkatli bir planlama gerektirir. Geçiş sürecindeki başlıca zorluklar şunlardır:

1. Servislerin Tanımlanması: Mevcut monolitik yapının hangi modüllerinin bağımsız birer servis haline getirileceği belirlenmelidir.

2. Veri Yönetimi: Merkezi bir veritabanından, her servisin kendi veri deposuna sahip olduğu bir yapıya geçiş yapılır. Bu, veritabanı bölme (database partitioning) ve veri tutarlılığı (data consistency) sorunlarını gündeme getirir.

3. Servisler Arası İletişim: Monolitik yapılarda genellikle aynı kod tabanı içinde olan bileşenler arasındaki iletişim, mikroservislerde API veya mesajlaşma sistemleri ile sağlanır.

4. Karmaşık Dağıtım Süreçleri: Mikroservisler, CI/CD süreçlerinde ek karmaşıklık yaratır. Dağıtım stratejileri dikkatlice planlanmalıdır.

Geçiş Süreci: Adım Adım

1. Hazırlık ve Analiz:

   • Monolitik yapıyı analiz ederek bağımsız servisler için uygun olan modülleri belirleyin.

   • Veri bağımlılıklarını ve modüller arası ilişkileri inceleyin.

   • İhtiyaçlara uygun bir mikroservis stratejisi belirleyin.

2. Modüler Monolitik Yapıyı Güçlendirin:
   Geçiş sürecinden önce, monolitik yapının modüler hale getirilmesi, geçişin daha sorunsuz gerçekleşmesini sağlar.

3. Pilot Mikroservis Oluşturun:
   Geçişe düşük riskli bir modül ile başlayarak, bir pilot mikroservis oluşturun ve öğrenim süreci başlatın.

4. Kademeli Geçiş Yapın:
   Tüm sistemi aynı anda mikroservise dönüştürmek yerine, kademeli bir geçiş süreci izleyin. Parça parça ayrıştırma, riskleri minimize eder.

5. Servisler Arası İletişim Altyapısını Kurun:

   • REST API, gRPC veya mesajlaşma sistemleri (ör. RabbitMQ, Kafka, AWS SQS) kullanarak servisler arası iletişimi sağlayın.

   • Servislerin birbirine bağımlılığını azaltmak için asenkron iletişim yöntemlerini tercih edin.

6. Monitoring ve Observability Altyapısını Güçlendirin:
   Mikroservislerin izlenebilirliğini artırmak için loglama, dağıtılmış tracing (ör. OpenTelemetry), ve metrik toplama araçları (ör. Prometheus, Grafana) kullanın.

Mikroservise Geçişte Kullanılan Patternler

1. Strangler Fig Pattern:
   Strangler Pattern, mevcut bir monolitik sistemi parça parça bir mikroservice mimarisine taşımak için kullanılan bir yazılım geliştirme desenidir. Bu desen, eski sistemin tamamını bir anda yeniden yazmak yerine, sistemin farklı modüllerini ya da işlevlerini aşamalı olarak yenilerken, eski ve yeni sistemin aynı anda çalışmasını sağlar.

2. Database Per Service:
   Her mikroservisin kendi veri tabanına sahip olduğu bu yaklaşım, veri bağımsızlığı sağlar.

3. API Gateway:
   Servisler arası iletişimi kolaylaştırmak ve servisleri dış dünyadan izole etmek için bir API Gateway kullanılır.

4. Event-Driven Architecture:
   Servisler arasındaki iletişim, olay tabanlı bir yapıya dayanır. Örneğin, bir sipariş oluşturulduğunda, bu olay mesajlaşma sistemi aracılığıyla diğer servislere iletilir.

5. Bulkhead Pattern:
   Bulkhead Pattern, sistem tasarımında kullanılan bir dayanıklılık (resilience) tasarım desenidir. Bu desen, sistemdeki farklı bileşenlerin veya işlevlerin birbirinden izole edilmesini sağlar. Böylece bir bileşende meydana gelen bir sorun, diğer bileşenlerin çalışmasını etkilemez. Bu desenin adı, gemilerdeki su geçirmez bölmelere benzetilir. Gemilerde bulkhead bölmeleri, geminin bir kısmında su sızıntısı olsa bile, diğer bölümlerin zarar görmeden çalışmasını sağlar.

Yazılım geliştirme dünyasında mimari seçimler, projelerin başarısını doğrudan etkileyen kritik unsurlardır. Monolitik mimari, hızlı başlangıçlar, basitlik ve düşük karmaşıklık gerektiren projeler için hâlâ güçlü bir seçenek olmaya devam etmektedir. Ancak, projeler büyüdükçe ve gereksinimler karmaşıklaştıkça, mikroservislere geçiş ihtiyacı doğabilir.

Bu yazıda, monolitik mimarinin avantajlarını ve dezavantajlarını tartışırken, katmanlı mimari ve modüler monolitik yapının önemine dikkat çektik. Ayrıca, mikroservislere geçiş sürecinin aşamalarını, dikkat edilmesi gereken zorlukları ve bu süreçte kullanılabilecek patternlerden kısaca bahsettik. Mikroservislere geçiş, uzun vadeli bir strateji ile planlanmalı ve kademeli bir şekilde gerçekleştirilmelidir. Doğru tasarım prensipleri ve güçlü bir altyapı ile, hem monolitik yapılardan hem de mikroservis mimarisinden en iyi şekilde faydalanmak mümkündür.

Yazılım geliştirme süreçlerinde doğru mimari seçimi, yalnızca teknolojik değil, aynı zamanda iş hedeflerine uygun bir yapı oluşturarak, projenin başarısını garanti altına alır. Gelecekteki blog yazılarımızda, moduler monolith mimarisi, mikroservis mimarisi ve bu yapılardaki best practice’ler üzerine daha derinlemesine odaklanacağız.

Bu bilgilerin üzerine daha fazla araştırma yaparak, denemeler yaparak bu konularda kendinizi geliştirebilir ve ihtiyaçlara göre projelerinizde doğru mimari kararlar verebilirsiniz. Umarım sana dokunmuş olabilirim. Merak ettiğin bir şey olursa benimle iletişime geçebilirsin.

Daha Derine Dalmak İsteyenler İçin Kaynaklar

1. Building Microservices – Sam Newman
   Mikroservis mimarisiyle ilgili kapsamlı bilgiler sunan bu kitap, yazılım geliştiriciler için bir rehber niteliğindedir.

2. Monolith to Microservices - Sam Newman

   Bu kitap, monolitik bir yapıdan mikroservis mimarisine geçiş sürecini detaylı bir şekilde ele alır. İş sürekliliğini koruyarak geçiş yapmanın yöntemlerini, örnekler ve desenlerle açıklar. Uygulama ve veri tabanı ayrıştırması, entegrasyon stratejileri ve iletişim süreçleri gibi konulara değinir. Mikroservise geçişin ne zaman ve nasıl yapılması gerektiği üzerine rehberlik sağlar. Sistemlerini yeniden inşa etmek yerine parça parça dönüştürmek isteyen organizasyonlar için idealdir.

3. Martin Fowler - Monolith First

   Bu metinde Martin Fowler, monolith-first stratejisi (önce monolitik mimari ile başlama) ve mikroservis mimarisi arasında bir karşılaştırma yapıyor. Mikroservislerin birçok avantajı olsa da, bu avantajların belirli bir karmaşıklık seviyesinde işe yaradığını ve küçük/orta ölçekli ya da başlangıç aşamasındaki projelerde genellikle monolitik bir mimariyle başlamanın daha mantıklı olduğunu savunuyor.

4. Strangler Fig Pattern
   Microsoft kendi yayınladığı bu blog yazısında monolitikten mikroservislere geçiş sürecinde kullanılan bu desen hakkında detaylı bilgi veriyor.

5. Clean Code – Robert C. Martin (Uncle Bob)
   Bu kitap, kaliteli kod yazmanın prensiplerini ve iyi bir yazılım geliştiricinin sahip olması gereken disiplinleri ele alır. Kodun nasıl daha okunabilir, sürdürülebilir ve kolay bakımı yapılabilir hale getirileceği üzerine pratik öneriler sunar. Yazılım geliştiriciler için bir başucu kitabıdır.

6. Clean Architecture – Robert C. Martin (Uncle Bob)
   Bu kitap, yazılım mimarisi tasarımı üzerine kapsamlı bilgiler sağlar. Sürdürülebilir, bağımsız ve modüler sistemler inşa etmek için temel prensipleri ve desenleri açıklar. Uygulama mimarilerinde yüksek bağlılığı azaltmak ve uzun vadeli başarıyı garantilemek isteyen yazılımcılar için ideal bir kaynaktır.

7. Designing Data-Intensive Applications – Martin Kleppmann
   Bu kitap, güvenilir, ölçeklenebilir ve sürdürülebilir sistemler tasarlamak için veri yönetimi ve sistem mimarisi üzerine kapsamlı bir rehberdir. Dağıtık sistemler, veri tabanı mimarileri, veri işleme, tutarlılık ve performans konularında derinlemesine bilgiler sunar. Özellikle büyük veri ve mikroservis mimarisi üzerine çalışanlar için vazgeçilmez bir kaynaktır.

1. Kubernetes'in Geçmişi ve Evrimi

2. Kubernetes Cluster Nedir? Yeni Başlayanlar İçin Kılavuz

3. Kubernetes Komut Satırı Aracı: kubectl

Kubernetes'de bir obje oluşturmanın üç temel yolu vardır:

1. Yaml yapılandırma dosyaları

2. JSON yapılandırma dosyaları

3. kubectl komut satırı

YAML Yapılandırma Dosyaları

YAML (YAML Ain't Markup Language), insan tarafından okunabilir yapılandırma dosyaları oluşturmak için kullanılan sade ve anlaşılır bir veri serileştirme dilidir. Kubernetes'de, YAML dosyaları, sistemin ihtiyaç duyduğu yapılandırmaları tanımlamak ve yönetmek için standart bir araç haline gelmiştir.

Artıları:

1. Okunabilirlik: YAML, girintileme ve boşluklarla yapıyı ifade eder, bu da onu insanlar tarafından daha kolay okunabilir hale getirir. Karmaşık yapılandırma dosyaları için daha anlaşılırdır.

2. Yalınlık: Daha az sembol ve işaretleme kullanır ({}, [], ,, : gibi). Bu da özellikle büyük dosyalarda temiz ve anlaşılır bir yapı sağlar.

3. Desteklenen Veri Türleri: YAML, string, integer, float, boolean gibi temel veri türlerini destekler. Ayrıca çok satırlı string'ler, liste ve sözlük (dictionary) gibi daha karmaşık yapıları da rahatlıkla ifade edebilir.

4. Esneklik: YAML esnek bir yapı sunar. Veri türleri genellikle otomatik olarak algılanır, bu da özellikle hızlıca yapılandırma dosyaları yazarken kullanışlı olabilir. Örneğin, string değerler tırnak işareti olmadan da yazılabilir, bu da yazmayı ve okumayı kolaylaştırır.

Eksileri:

1. Hata Yapma Riski: Girintileme hataları YAML dosyalarında sıkça karşılaşılan bir sorundur. Girintileme hataları doğru çalışmayan yapılandırmalara yol açabilir.

2. Performans: JSON'a göre daha karmaşık ve soyut bir yapısı olduğundan, işlenmesi JSON'dan daha yavaş olabilir.

3. Standart Dışı Kullanımlar: YAML, isteğe bağlı olarak yorum satırları ve özel karakterleri destekler, bu da bazen taşınabilirlik ve standart uyumu açısından sorun yaratabilir.

YAML ile bir pod oluşturmak istediğimizde aşağıdaki gibi bir tanımlama yapabiliriz.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: nginx:latest
      ports:
        - containerPort: 80

JSON Yapılandırma Dosyaları

JSON (JavaScript Object Notation), veri depolama ve veri aktarımı için yaygın olarak kullanılan hafif bir veri değişim formatıdır. JSON, insan tarafından okunabilir bir metin formatı olup, JavaScript nesne gösterimi üzerine kurulmuştur, ancak dil bağımsızdır. JSON, yapılandırılmış verileri bir dizi anahtar-değer çifti ve sıralı liste olarak ifade eder.

Artıları:

1. Basitlik: JSON, basit bir yapıdadır ve çok net bir sözdizimi kullanır. Bu da onu hızlı ve kolay bir şekilde yazılabilir ve işlenebilir hale getirir.

2. Performans: JSON, daha basit yapısı sayesinde daha hızlı işlenebilir. Genellikle web API'larında veri aktarımı için kullanılır.

3. Standart Uyumluluk: JSON, web servisleri ve API'lar için yaygın olarak kullanılan bir format olduğu için geniş bir destek ve uyumluluk sağlar.

4. Tip Güvenliği ve Veri Doğrulama: JSON, tip güvenliği ve veri doğrulama konusunda daha katıdır. JSON dosyasında her veri türü (string, number, boolean, array, object) açıkça belirtilir ve bu sayede veri yapısının doğruluğu daha net bir şekilde kontrol edilebilir. Örneğin, bir string değeri her zaman tırnak içinde belirtilir, bu da JSON'un veri doğrulama araçları tarafından kolayca işlenmesini sağlar.

Eksileri:

1. Okunabilirlik: Özellikle karmaşık yapılandırma dosyaları söz konusu olduğunda, JSON'un okunması ve yönetilmesi zor olabilir.

2. Yazım Hataları: JSON'un sıkı bir sözdizimi vardır (örneğin, tırnak işaretleri, virgüller). Küçük bir hata, JSON dosyasının tamamen geçersiz olmasına neden olabilir.

3. Esneklik Eksikliği: JSON, çok satırlı stringler ve yorumlar gibi özellikleri desteklemez. Bu da yapılandırma dosyalarında esnekliği sınırlayabilir.

JSON ile bir pod oluşturmak istediğimizde aşağıdaki gibi bir tanımlama yapabiliriz.

{
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
    "name": "my-pod"
  },
  "spec": {
    "containers": [
      {
        "name": "my-container",
        "image": "nginx:latest",
        "ports": [
          {
            "containerPort": 80
          }
        ]
      }
    ]
  }
}

Kubectl Komut Satırı

Yaml ya da json dosyaları kullanmadan da kubectl komutlarını kullanarak çeşitli objeler oluşturmak ve güncellemek mümkündür.

Artıları:

1. Hızlı ve Anlık Yönetim: Kubernetes objeleri doğrudan komut satırı aracılığıyla da oluşturulabilir ve yönetilebilir.

Eksileri:

1. Sürdürülebilirlik: Yapılandırmaların belgelenmesi ve versiyon kontrolü zor olur.

2. Karmaşıklık: Daha karmaşık yapılandırmalar için komut satırı yeterli olmaz.

Kubectl ile bir pod oluşturmak istediğimizde aşağıdaki gibi komut yazabiliriz.

kubectl run my-pod --image=nginx:latest --port=80

Her ne kadar kubectl komut satırı, hızlı ve doğrudan müdahale gerektiren durumlar için kullanışlı olsa da, uzun vadeli yapılandırmalar için tercih edilmez. Kubectl, komut satırı doğrudan terminal üzerinden çalıştığı için yapılan işlemlerin tekrarlanabilirliği ve izlenebilirliği sınırlıdır. Bu yöntem, özellikle karmaşık ve uzun yapılandırmalar için uygun değildir, çünkü komutlar terminalde çalıştırıldıktan sonra kaybolur ve bu da uzun vadeli yapılandırmaların yönetimini zorlaştırır. Bunun yerine, JSON ve YAML dosyaları, yapılandırma dosyalarının daha etkili bir şekilde yönetilmesine olanak tanır. CI/CD (Continuous Integration/Continuous Deployment) süreçlerinde, yapılandırma dosyalarının versiyon kontrolü altında tutulması, izlenebilir olması ve otomatik olarak işlenebilirliği son derece önemlidir. Hem JSON hem de YAML dosyaları, bu süreçlerde başarıyla kullanılabilir. YAML dosyaları, özellikle insan tarafından okunabilirliği ve yazılabilirliği nedeniyle CI/CD süreçlerinde daha fazla tercih edilirken, JSON da belirli otomasyon araçları ve API entegrasyonları ile uyumluluğu nedeniyle tercih edilebilir.

YAML ve JSON Arasındaki Farklar

1. Sözdizimi: YAML, girintileme kullanırken JSON köşeli parantezler ([]) ve süslü parantezler ({}) kullanır. Bu, YAML'ı daha okunabilir, JSON'u ise daha katı bir format haline getirir.

2. Yorumlar: YAML yorumları desteklerken JSON desteklemez. Bu, YAML'ı yapılandırma dosyaları için daha uygun hale getirir.

3. Veri Yapıları: Her iki format da aynı veri yapılarının çoğunu destekler, ancak YAML daha zengin ve esnek bir şekilde çok satırlı stringler ve karmaşık yapıların ifade edilmesine izin verir.

Kubernetes ve Cloud Dünyasında Neden YAML Tercih Ediliyor?

1. Okunabilirlik: Kubernetes gibi karmaşık sistemlerde yapılandırma dosyalarının anlaşılması ve yönetilmesi önemlidir. YAML, okunabilirliği sayesinde kullanıcılar için daha erişilebilir hale gelir.

2. Modülerlik ve Esneklik: YAML, girintileme ve blok tabanlı yapısıyla, karmaşık nesne yapılarını ve hiyerarşileri düzenlemek için idealdir. Kubernetes gibi büyük ölçekli sistemlerde, farklı konfigürasyon parçalarının bir araya getirilmesi ve düzenlenmesi gerektiğinde, YAML'ın modüler yapısı büyük bir avantaj sağlar.

3. Yorumlama Yeteneği: YAML, yapılandırma dosyalarında yorum satırlarına izin verir. Bu, yapılandırma dosyalarının amacı ve kullanımı hakkında daha fazla bilgi vermek için yararlıdır.

YAML ve JSON'un her biri farklı senaryolar için güçlü araçlar sunar. Kubernetes başta olmak üzere birçok modern bulut sistemi, yapılandırma dosyaları için YAML'ın okunabilirliği, esnekliği ve yorumlama yeteneği gibi avantajları onu tercih edilen bir format haline getirir.

YAML ile Kubernetes Objelerinin Yönetimi

YAML, JSON ve kubectl komut satırından bahsettiğimize göre şimdi bir kubernetes yaml dosyasının nasıl yapılandırıldığını, bu dosyalarda sıkça kullanılan alanları ve objeye göre değişebilen alanları inceleyeceğiz.

Bir Kubernetes YAML dosyası, genellikle dört ana bölüm içerir:

1. apiVersion: Bu alan, Kubernetes API'sinin hangi versiyonunun kullanıldığını belirtir. Her objenin, belirli bir API versiyonuna bağlı olarak tanımlanması gerekir.

2. kind: Bu alan, oluşturulacak Kubernetes objesinin türünü tanımlar (örneğin, Pod, Service, Deployment vb.).

3. metadata: Objenin adı, etiketler, ve açıklamalar gibi meta bilgileri içerir.

4. spec: Bu alan, objenin özel yapılandırmalarını içerir. Bu bölüm, objenin türüne göre büyük ölçüde değişir.

Bu dört ana bölümden apiVersion, kind ve metada tüm objelerin tanımında bulunur. spec bölümü obje türüne göre değişir.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
  containers:
    - name: my-container
      image: nginx:latest
      ports:
        - containerPort: 80

Örneğin yukarıdaki yaml tanımlamasında, kind değeri Pod. Yani biz bir pod tanımlaması yapıyoruz. apiVersion kısmında v1 değerini görüyoruz. Bu tanımlar rastgele yazdığımız tanımlar değildir. Bu tanımlar kubernetes api içerisinde bulunur. Örneğin biz bir pod oluşturmak istiyoruz ancak apiVersion, kind alanlarına ne yazacağımızı bilmiyoruz diyelim. Bu durumda kubectl komut satırını kullanarak ya da kubernetes dökümantasyonunu okuyarak öğrenebiliriz.

• Dökümantasyon: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/

Yukarıdaki adresi ziyaret ettiğimizde tarayıcımızda aşağıdakine benzer sayfa yüklenecektir. Burada kind ve apiVersion bilgilerini bulabileceğiz.

• Bu bilgileri kubectl komut satırı üzerinden de öğrenebiliriz.

    kubectl explain pod
  

  Yukarıdaki komutu çalıştırdığımızda, terminal bize cevap olarak aşağıdaki gibi bir çıktı üretir. Burada kind ve apiVersion bilgilerini görebilirsiniz.

  

  Her kubernetes objesine ek bilgiler eklemek için metada bölümünü kullanırız. metada içerisine name, labels (etiketler), annotations (ek açıklamalar) gibi tanımlamalar yapabiliriz. Aşağıdaki yaml tanımlamasında gördüğünüz gibi metadata içerisinde pod'a isim, etiketler ve ekstra bilgiler ekledik.

Labels (etiketler), Kubernetes ekosisteminde çok önemlidir. Kubernetes objelerini ayırmada, gruplamada ve seçici sorgulamalar yapmada kullanılır. Etiketler sayesinde belirli bir etiketle işaretlenmiş objeleri seçebilir, bu objeler üzerinde toplu işlemler gerçekleştirebilir ve monitoring, scaling gibi operasyonlarda etiketleri referans alarak otomatik süreçler oluşturabilirsiniz. Ayrıca, etiketler kullanarak belirli bir uygulamanın farklı versiyonlarını veya ortamlarını ayırt etmek mümkündür.

apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    app: cmspanel
    environment: production
    tier: frontend
  annotations:
    description: "Bu pod frontend uygulamamızı, production ortamında çalıştırır."
    maintainer: "serhatleventyavas@gmail.com"
spec:
  containers:
    - name: cmspanel
      image: nginx:latest
      ports:
        - containerPort: 80

Her kubernetes objesinin kendi özgü ayarları, tanımlamaları vardır. Bu tanımları yapmak için spec bölümünü kullanırız. Bu bölüm, objenin türüne göre büyük ölçüde değişir.

Örneğin, aşağıdaki YAML dosyasında bir Pod oluşturulurken kullanılan spec tanımını görebilirsiniz.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: nginx:latest
      ports:
        - containerPort: 80

Spec bölümünde kullandığımız tanımları açıklamak gerekirse:

• containers: Pod içinde çalışacak container'ları tanımlar.

• name: Container'ın adını belirler.

• image: Kullanılacak Docker imajını belirtir.

• ports: Container'da açılacak portları tanımlar. Bu örnekte, containerPort 80 olarak belirlenmiştir.

Pod'un spec bölümü hakkında daha detaylı bilgi edinmek için Kubernetes dokümantasyonunu ziyaret edebilirsiniz.

Kubectl Komutu ve YAML ile Pod Yönetimi

Yazımızın bu son bölümünde, bir YAML dosyası kullanarak nasıl bir Pod oluşturabileceğimizi, güncelleyebileceğimizi ve silebileceğimizi ele alacağız. Bu konuları ileride yazmayı planladığım Pod makalesinde daha detaylı olarak inceleyeceğim. Ancak, bu noktada bir YAML dosyasının nasıl çalıştırıldığını göstermek ve temel Pod yönetimi işlemlerini anlamak adına bu örnek oldukça faydalı olacaktır.

Pod Oluşturma

Öncelikle, bir YAML dosyası oluşturarak Pod tanımlamamızı yapalım. Aşağıdaki içerikle mypod.yaml adlı bir dosya oluşturalım:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mycontainer
      image: nginx:latest
      ports:
        - containerPort: 80

Bu YAML dosyasını oluşturduktan sonra, aşağıdaki kubectl apply komutunu kullanarak Pod'u çalıştırabiliriz:

kubectl apply -f mypod.yaml

Bu komut, Kubernetes API'sine dosyada tanımlı olan Pod'u oluşturmasını söyler. Pod'un başarıyla oluşturulup oluşturulmadığını doğrulamak için şu komutu kullanabilirsiniz:

kubectl get pods

Ayrıca aşağıdaki komut ile pod hakkında daha fazla bilgi öğrenebiliriz.

kubectl describe pods mypod

Pod Güncelleme

Oluşturduğumuz Pod'u güncellemek için YAML dosyamızda değişiklikler yapabiliriz. Örneğin, container'ın kullandığı imajı değiştirelim ve bir adet etiket ekleyelim:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  labels:
    app: backend
spec:
  containers:
    - name: mycontainer
      image: nginx:alpine
      ports:
        - containerPort: 80

Değişiklikleri kaydettikten sonra, yine kubectl apply komutunu çalıştırarak Pod'u güncelleyebilirsiniz:

kubectl apply -f mypod.yaml

Bu komut, mevcut Pod'u günceller ve yeni yapılandırmaya göre yeniden oluşturur.

Tekrardan aşağıdaki komutu çalıştıralım ve yaptığımız değişiklikleri görelim.

kubectl describe pods mypod

Pod Silme

Son olarak, oluşturduğumuz Pod'u silmek istersek, kubectl delete komutunu kullanabiliriz:

kubectl delete -f mypod.yaml

Bu komut, YAML dosyasında tanımlı olan Pod'u siler ve kümede bu isimde bir Pod kalmaz. Bunu görebilmek için tekrardan podları listeleyelim.

kubectl get pods

Bu makalede, Kubernetes yapılandırma dosyalarının oluşturulması ve yönetilmesi konusunda JSON, YAML formatlarını ve kubectl komut satırı ele aldık. YAML'ın neden sektör standardı haline geldiğini ve Kubernetes dünyasında yapılandırma dosyalarının vazgeçilmez bir parçası olduğunu inceledik. Kubernetes YAML dosyalarının ana bölümlerini tanıtarak, Kubernetes objelerinin nasıl tanımlandığını ve yönetildiğini açıkladık. Son olarak, öğrendiklerimizi pekiştiren bir örnekle, YAML kullanarak Kubernetes'te Pod oluşturma sürecini adım adım uyguladık. Bu bilgilerin üzerine daha fazla araştırma yaparak, denemeler yaparak kubernetes konusunda kendinizi geliştirebilir ve uygulamalarınızı kubernetes ortamında çalıştırabilirsiniz. Umarım sana dokunmuş olabilirim. Merak ettiğin bir şey olursa benimle iletişime geçebilirsin.

kubectl Nedir?

kubectl, Kubernetes kümesi ile etkileşime geçmenizi sağlayan bir komut satırı aracıdır. Kubernetes'in api-server objesine komutlar göndererek kubernetes kümesindeki kaynakları yönetmenize olanak tanır. kubectl, Kubernetes'in çeşitli bileşenlerini ve kaynaklarını (örneğin, podlar, hizmetler, dağıtımlar) yaratmak, güncellemek, silmek ve görüntülemek için kullanılır.

Eğer örnekleri sizde uygulamak isterseniz bir kubernetes kümesine ihtiyacınız olacak. Kendi bilgisayarınıza minikube kurarak hızlı bir şekilde bir kubernetes kümesine sahip olabilirsiniz.

kubectl Kubernetes Cluster İle Nasıl İletişim Kurar?

kubectl, kubernetes kümesi ile iletişime geçebilmesi için bir takım bilgilere ihtiyaç duyar. Bunlar;

1. Kullanıcı kimlik bilgileri (users)

2. Küme bilgileri (clusters)

3. Bağlam bilgileri (context)

Bu bilgileri doğru bir şekilde kubectl tarafına verdiğimiz zaman kubernetes kümesine başarılı bir şekilde bağlanabilir ve kubernetes api-server objesi ile sağlıklı bir şekilde iletişim kurabiliriz. Kubectl bu verileri okumak için varsayılan olarak bilgisayarımızdaki ana dizin altındaki .kube klasörü içerisindeki config dosyasına bakar.

Örneğin;

• macos: ~/.kube/config

• linux: ~/.kube/config

• windows: "C:\Users\<KullanıcıAdı>\.kube\config"

Örneğin ben kendi makinemdeki config dosyasını vscode editörü ile açtığımda aşağıdaki yaml tanımını görüyorum. docker-desktop ve minikube adında iki farklı kümeye, docker-desktop ve minikube adında iki farklı kullanıcıya sahibim. Son olarak bu kullanıcıları ve küme bilgilerini birleştiren context bilgilerimi görüyorum. Contextler sayesinde hangi kümeye hangi kullanıcı ile bağlanacağımızı belirleriz.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCVENDQWUyZ0F3SUJBZ0lJSXFzd1Q3eUN0bFl3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TkRBM01USXdOVFV3TlRCYUZ3MHpOREEzTVRBd05UVTFOVEJhTUJVeApFekFSQmdOVkJBTVRDbXQxWW1WeWJtVjBaWE13Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLCkFvSUJBUUM2SkdXeFFONHNLZWpkNWNmcnhsOEJhNytnUGxiZkpZRmRVbTFjZmE5cmlRd1UxazJyaFpMaDJuN0MKOS9zcXpzckx5dkhwaktSby85R3VoZmJFVEVObkJYTU1GT3BmOG96Vnd3SzlyMzRWa1p1QTVEY213d3VxOW1lWApRZkhwajJicE12SS9iYno3V1lzVkJ5TzNOL2xGWGMxN3ppQTJzeWRNT0NRZjRjZHlycWc1QnRGejlQb2FaRVZtCk84Q2tnK0NZMVVBTm9jWHNEVE5LTjFDbU5GejFIa3NjTElvR0hRQmJVbCtqT1FNNndoQ0Ewd2FmU0w0ZDJPSHEKK1QzL3BIWEJRUmhuNHV5VmZBcDBxZ1hhVE5LMWtLTGZQOCs1aDVPVDh0OFF4T1NsVWozb1VLOEZBTGFUL05mUApzejZlL08rendLWVU2UjJHK2dSM2ViZG5uWC8xQWdNQkFBR2pXVEJYTUE0R0ExVWREd0VCL3dRRUF3SUNwREFQCkJnTlZIUk1CQWY4RUJUQURBUUgvTUIwR0ExVWREZ1FXQkJURDhkMFJTRkRuMEJNWmpBOFJsZlFvcmthV2h6QVYKQmdOVkhSRUVEakFNZ2dwcmRXSmxjbTVsZEdWek1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQ1RoS1V2SUlQZgpITU9RNi9iQ2pjUk40RlF4M0p6My9CQXFwRkhiaTBTMHcvcEllNW9FMDdLUnJWdDZnSVp0UGtMNUhrNmxrUnovCjNtQ3Z6TysxMDBKaW1RWjNqVzVtUElUS0czcWhjNDdhMHl5c1k2TXNabG1OR2lBbEtiSUNCc0xpbFpCaXFGMFAKQkYzRUlrVnY1dVZzV05VTjJYWWo4QkwvczhCYjRWUXJFeCtFYTZwc1UxdkROa2ZDQjFkakRnb0hVaXBra0JVZQo2REV2M1dINHNsS0x0QTRGSEZ2OXNwckR4MUx6cmJvRzUraExvUUphZS8zTE1mMlRTL25tVFlZMFVScEZXbmxaCjhlSlh2NDZQQ2NRT0pYYTRtS08rZkxIM2piSkZpSHk2MkgrNnp3Zko2eW1NRVhoQmgrUjgySjJaQ0xUL2FRTXkKZEwzeFJ4d1NGZFh4Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://kubernetes.docker.internal:6443
  name: docker-desktop
- cluster:
    certificate-authority: C:\Users\serha\.minikube\ca.crt
    extensions:
    - extension:
        last-update: Sun, 02 Aug 2024 09:08:25 +03
        provider: minikube.sigs.k8s.io
        version: v1.33.1
      name: cluster_info
    server: https://127.0.0.1:57415
  name: minikube
contexts:
- context:
    cluster: docker-desktop
    user: docker-desktop
  name: docker-desktop
- context:
    cluster: minikube
    extensions:
    - extension:
        last-update: Sun, 02 Aug 2024 09:08:25 +03
        provider: minikube.sigs.k8s.io
        version: v1.33.1
      name: context_info
    namespace: default
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: docker-desktop
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURRakNDQWlxZ0F3SUJBZ0lJT2Z4WHdqOWNtUjh3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TkRBM01USXdOVFV3TlRCYUZ3MHlOVEEzTVRJd05UVTFOVEZhTURZeApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sc3dHUVlEVlFRREV4SmtiMk5yWlhJdFptOXlMV1JsCmMydDBiM0F3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQytvVitqazFhWklZTloKTVNDVUsrckx1UEZYVzZOWnNZWG12aG1yc3NhOXUyNFpLelhVcWxxOEdLZHlHNnhJZ2c5WW41L1cwdkN6eVAzcwpsWXpnR2tNYlZiYm0wZGh4UytUVUFiVWZCcjgybG1DbS80Y0MyVHJBODVIUHNsSUFhdWJsTlM1L05GVzMwMEZkCjhWaFN3dmhVdjZTU281dm15Z2RxMzZpdVk3S01ZeGlHUHVEQUZpSlhybjR0bFh0MEs4QW85ZEV5bGJhS0h0MFoKVmFJOWcyUjBCcXZXK21pQTlyeTVNbjhsNlA2S0hLRTAyVmxucGVzeDlpWjB6VjhuZ0pKOC9aTlh5TXVJdW9ZUwo3NDgyVUNucVpRVktteDNPZEdGYkVKZDNjWG5WM0Y1K21ZTFhMNXhMRk1odUw2TFhkaDdMVExRa1lYNk5LQmtGCmlFVTM2ZFdiQWdNQkFBR2pkVEJ6TUE0R0ExVWREd0VCL3dRRUF3SUZvREFUQmdOVkhTVUVEREFLQmdnckJnRUYKQlFjREFqQU1CZ05WSFJNQkFmOEVBakFBTUI4R0ExVWRJd1FZTUJhQUZNUHgzUkZJVU9mUUV4bU1EeEdWOUNpdQpScGFITUIwR0ExVWRFUVFXTUJTQ0VtUnZZMnRsY2kxbWIzSXRaR1Z6YTNSdmNEQU5CZ2txaGtpRzl3MEJBUXNGCkFBT0NBUUVBUXk1Wmd2dHhYNDBaSGNaNDR0L3ZvbEhGQWk2eG8vdVVhUmFSN1IzeUpMVjNTaXp3Sk1ZRmxrNFcKdDAwRkMzL3VsWS9NdTkrTlE1MnpXU0s0R0NwaFllOHpMdFNnUGM4WU41QnFrTDlWYnYwNTJtMjBYWHBjaHJ2RAo1cDBjMklIWFhMSkJ6SG0zMDNoQkN1N2w3MVVsSUFTVExkcTBzK3ZrMkFhVmVTVjkwbG56bFdXbi92OUtjaFZ6CmJPWFo2T3JvZDB0MXNmczNCZlRoMmZsd09vNkdadCtwN0J0TTJIT0Jta0ZOYUNYTFFuYkNRYXpkQU5rbWMyWEwKUkxxSVVibVdGeWwrcjFZaG1Ibk50NHRqRlBldzF1L1piWUFnd1J1am5hQUdKM08ya1Q0VkFrNUtNSHNyZFZHNApyL0lINC8rN1ZGNk8rSnFoQlBXVXVIcTlwVkpHNFE9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBdnFGZm81TldtU0dEV1RFZ2xDdnF5N2p4VjF1aldiR0Y1cjRacTdMR3ZidHVHU3MxCjFLcGF2QmluY2h1c1NJSVBXSitmMXRMd3M4ajk3SldNNEJwREcxVzI1dEhZY1V2azFBRzFId2EvTnBaZ3B2K0gKQXRrNndQT1J6N0pTQUdybTVUVXVmelJWdDlOQlhmRllVc0w0Vkwra2txT2I1c29IYXQrb3JtT3lqR01ZaGo3Zwp3QllpVjY1K0xaVjdkQ3ZBS1BYUk1wVzJpaDdkR1ZXaVBZTmtkQWFyMXZwb2dQYTh1VEovSmVqK2loeWhOTmxaClo2WHJNZlltZE0xZko0Q1NmUDJUVjhqTGlMcUdFdStQTmxBcDZtVUZTcHNkem5SaFd4Q1hkM0Y1MWR4ZWZwbUMKMXkrY1N4VEliaStpMTNZZXkweTBKR0YralNnWkJZaEZOK25WbXdJREFRQUJBb0lCQVFDa1EvaGV3d0szVjVxUQppL1hQMkh3dDZvTUV6UEZZdzlGbmdONHNCeFNjdjlyaWswcUNvLzBsNG5TL3JqcnFERERmSkVXZTN3d05VQ0FHCjh1Tis1UUo0bG9iU0pYZEdRYWpBUzJ4Z2ZQYmVPZnkxU3JGemNlN2YvOExnMzM4cjN2SnlCajYzM0VnVTdGU0MKZUFxczNsY1E2RWNQR1M2cFUrUEtZMG8rWTZpaXNPN0V3MEt2QmlFVkd0Y3NwbzAxSGhERXlIYUIvRWNMaVR4RQprY29ndmUvbHFMRldZN0w0MU9IY0srUDRXclN5M0pRVXpNUjVYV0VwRkU4Ymk2UHZiRlVZTEpVTVNueitOVmxoCnU5bVVZMks1Zzg1c003dkxKYnppVUp5eStRZHFBS09MSEhSNmwzRmxBWnJpckQrVkx4elVHRzZWNG1FUFdtN28KekttUzNtZUJBb0dCQU1iTGhoQVhkZVNlZ0JRVi83YkJYRm1BYTdPOHFBN0trNkNqSWh0NkhRekJvY0pncWc2eApvQTZidmdmd3hmSGJpeEMyT1Jib0VBdy8rdlNlVlJUZTRwb2dCeDU4TlkzeS9PU1ZWUXdwTlZZbmJtSlBuU2lPCmdXUk9rbitNZ1IyeTJtaURvZnRyc2V2a3lRa3E4OURWbytieGgranB6MmljbTFqdGh1ZXpkUGxiQW9HQkFQVjgKWkNFa3Iycm1TbnBTdFIyYnd5OUpaKzhUVm9yOGZaMXZmeHF6Szd3NGx6QmtUdDNwaW5JSmdFNDZGRnBVL3o1MwpPNit3QVNyOGtHRWtTWEp5YmZZOVJMcXNWVGVFTkh1SG5jQnU4RzJnT0JLaTI2YTJ0TG5FaC8rTyt4b0l5L3QzCmNVRTB0Q3hGSjNObERnalRETE04dkN4YjQ2NjJVdXlvYzRSaS9RakJBb0dBUDU3M0FzTmZXWkZZVUJWU1J6ek8KdjE0WUdlZXdxVHN2eitNbGtVR2RkbTJweFRtR2N6bHBqZ05ONStDb21PUzROdHI2bmxnYWVyRW5NWTVTa0dGYwppQkxqOUYrd0RBUE41NkhiSEE4OElKeHgrVWlkZFZOV0diSUR0SXBVOEJwRFI5dUl4WndMendEalRlblBLZkNWCmlkMldyM1hVaVJoRnAwb3RPSTM0UzYwQ2dZQUdvRkh2bHhicEVzaEYzdittaWZMTnp2UndQcHhpYWdoVi9KRjQKdmdkYk1FZmNkWWl2Y3NOYTZxaTg4OUppMGRLRjlCLzNVUS9uQWlRL2l3UTBnNlEyTmxjcGxzZENGVjU1U3lMVgo4K2luZk9DbW1DREhzanpVbXRwMDZuNGFxTXdnd0l1ZEQvZ2hEY2pQMDVWNlpYLzlRcEZ0dlJrN09RNnA5cTRQCmo4QjJ3UUtCZ1FDNWlWbGdrdWZFUGowazhiMkVZU01VcXlMR1RlaXRrZmtJYkQ3Q1BZejZva0p4eUxLWVY1UncKYi9JZDd0RndiREZPemc3Vk1zMnBhajd6UmF2dnd6bHc5NWViUTUzT094aG9NbWxPTmtUVTRhMk9vS1ZTdW9CYQo5S2VyanRjZnlNMVRWelJJZVlrWWFST1QxbW1KUFNtclkwUnovWWVUUlRQVG9GcVVscjdqamc9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
- name: minikube
  user:
    client-certificate: C:\Users\serha\.minikube\profiles\minikube\client.crt
    client-key: C:\Users\serha\.minikube\profiles\minikube\client.key

Ayrıca gördüğünüz üzere bir config dosyası üzerinde birden fazla küme, kullanıcı ve context bilgisi bulunabilir ve biz kubectl üzerinden contextler arasında geçişler yapabiliriz.

kubectl config Komutları

1. Contextleri listeleme için aşağıdaki komutu yazarız.

kubectl config get-contexts

Bu komut bize aşağıdaki gibi bir sonuç üretir.

Bu tablodaki kolonlardan kısaca bahsedelim.

• CURRENT: Config içerisine birden fazla context tanımlanıyor olsada biz anlık olarak sadece bir context üzerinde çalışabiliriz. kubectl'e verdiğimiz tüm komutlar current olarak işaretlenmiş context üzerinde çalıştırılıyor. Yukarıdaki tabloda benim current context'im minikube isimle context. Yazdığım tüm komutlarda minikube context'in bağlandığı kubernetes kümesi üzerinde çalıştırılacak. Tablodaki current kolonu yıldız ile işaretlenen context, current context'dir.

• NAME: Context adı

• CLUSTER: Context'in bağlandığı kubernetes cluster adı

• AUTHINFO: Context'in kullandığı kullanıcı adı

• NAMESPACE: Context'in kullanıdığı namespace bilgisi

2. Aktif context bilgisini alabilmek için aşağıdaki komutu yazarız.

kubectl config current-context

Bu sonuç olarak sadece aktif context'in adını yazar.

3. Eğer aktif context'den başka bir context geçiş yapmak istiyorsak aşağıdaki komutu yazarız.

kubectl config use-context docker-desktop

Bu komut çalıştıktan sonra aktif context değerimiz docker-desktop isimli context olur.

kubectl Yapısı

kubectl komutları belirli bir yapıya sahiptir. Temel bir kubectl komutu şu şekilde yapılandırılmıştır:

kubectl [komut] [kaynak tipi] [kaynak adı] [flags]

1. Komut

kubectl'de kullanılabilen temel komutlar şunlardır:

• create: Yeni bir kaynak oluşturur.

• get: Mevcut kaynakları listeler.

• describe: Bir kaynağın detaylarını gösterir.

• apply: Bir YAML dosyasındaki kaynak tanımlarını uygular veya günceller.

• delete: Bir kaynağı siler.

Örnek:

kubectl get pods

Bu komut, mevcut tüm podları listeler.

2. Kaynak Tipi

kubectl komutlarında kullanılan kaynak tipleri, Kubernetes'in temel yapı taşlarını oluşturur. Aşağıda yaygın olarak kullanılan bazı kaynak tiplerini ve kısa açıklamalarını bulabilirsiniz:

2.1. Pod

Podlar, Kubernetes'in en küçük dağıtım birimidir. Bir veya daha fazla konteyneri barındırır.

Örnek:

kubectl get pods

2.2. Deployments

Deployments, belirli bir pod setinin ve bu podların sürümlerinin yönetimini sağlar.

Örnek:

kubectl get deployments

2.3. Services

Services, Kubernetes içindeki podların ağ üzerinde erişilebilir olmasını sağlar. Yük dengeleme (load balancer) ve hizmet keşfi (service discovery) sunar.

Örnek:

kubectl get services

2.4. ConfigMaps

ConfigMap, yapılandırma verilerini key-value (anahtar-değer) çiftleri olarak saklar ve podlar tarafından kullanılabilir.

Örnek:

kubectl get configmaps

2.5. Secrets

Secret, duyarlı verileri (örneğin, parolalar, tokenlar) güvenli bir şekilde saklar ve podlar tarafından kullanılabilir.

Örnek:

kubectl get secrets

2.6. ReplicaSet

ReplicaSet, belirli bir pod sayısının her zaman çalışır durumda olmasını sağlar.

Örnek:

kubectl get replicasets

2.7. Namespace (namespaces)

Namespace, kaynakları mantıksal olarak izole etmek için kullanılır. Büyük kümelerde kaynakları organize etmek için yararlıdır.

Örnek:

kubectl get namespaces

2.8. Ingress (ingresses)

Ingress, HTTP ve HTTPS yönlendirmeleri için kuralları tanımlar. Dış trafiğin cluster içindeki hizmetlere nasıl yönlendirileceğini belirler.

Örnek:

kubectl get ingresses

2.9. Node (nodes)

Node, Kubernetes kümesindeki fiziksel veya sanal makineleri temsil eder.

Örnek:

kubectl get nodes

2.10. PersistentVolume

PersistentVolume (PV), kümede depolama kaynaklarını temsil eder. Podlar için kalıcı depolama sağlar.

Örnek:

kubectl get persistentvolumes

2.11. PersistentVolumeClaim (persistentvolumeclaims)

PersistentVolumeClaim (PVC), podlar tarafından talep edilen kalıcı depolama kaynaklarını tanımlar.

Örnek:

kubectl get persistentvolumeclaims

2.12. StatefulSet

StatefulSet, durum bilgisi olan uygulamaları yönetmek için kullanılır. Her bir podun kimliğini korur.

Örnek:

kubectl get statefulsets

2.13. Job

Job, belirli sayıda podu çalıştıran ve tamamlandıklarında sona eren geçici görevler için kullanılır.

Örnek:

kubectl get jobs

2.14. CronJob

CronJob, belirli zaman aralıklarında yinelenen görevleri (job'ları) çalıştırmak için kullanılır.

Örnek:

kubectl get cronjobs

3. Kaynak Adı

Komutun hedef aldığı spesifik kaynağın adıdır. Bu, belirli bir pod, deployment, service veya başka bir kaynağın adını belirtir.

Örnek:

kubectl delete pod mypod

Bu komut, "mypod" adlı podu siler.

4. Bayraklar (Flag)

Bayraklar, komutun davranışını değiştirmek veya ek seçenekler eklemek için kullanılır. Örneğin, komuta -o eklediğimiz çıktıyı belirli bir formatta görüntülemek için kullanılır (json, yaml, wide vb.).

Örnek:

kubectl get pods -o wide

Bu komut, podları daha geniş bir formatta listeler, daha fazla bilgi içerir.

kubectl Kullanım Örnekleri

kubectl'in gücünü ve esnekliğini göstermek için bazı kullanım örneklerine bakalım.

Bir Pod Oluşturma

Bir pod oluşturmak için run komutunu kullanabilirsiniz:

kubectl run nginxpod --image=nginx

Bu komut, nginx imajını kullanan bir pod oluşturur.

Podları Listeleme

Kümedeki tüm podları listelemek için get komutunu kullanabilirsiniz:

kubectl get pods

Pod Detaylarını Görüntüleme

Bir podun detaylarını görüntülemek için describe komutunu kullanabilirsiniz:

kubectl describe pod nginxpod

Bir YAML Dosyasını Uygulama

Bir YAML dosyasındaki tanımları uygulamak için apply komutunu kullanabilirsiniz:

kubectl apply -f deployment.yaml

Bir Kaynağı Silme

Bir kaynağı silmek için delete komutunu kullanabilirsiniz:

kubectl delete pod nginx-pod

Özetlemek gerekirse kubectl, Kubernetes kümesi ile etkileşime geçmek için temel bir araçtır. Komut yapısı ve esnekliği sayesinde Kubernetes kaynaklarını yönetmek oldukça kolay ve etkilidir. Bu makalede kubectl'in temel yapısını ve bazı yaygın kullanım örneklerini ele aldık. Bu bilgilerin üzerine daha fazla araştırma yaparak, denemeler yaparak kubernetes konusunda kendinizi geliştirebilir ve uygulamalarınızı kubernetes ortamında çalıştırabilirsiniz. Umarım sana dokunmuş olabilirim. Merak ettiğin bir şey olursa benimle iletişime geçebilirsin.

Yukarıda gördüğünüz diagram bir Kubernetes cluster diagramıdır. Basit bir şekilde anlatmak gerekirse, Kubernetes kurduğumuzda bir cluster'a sahip oluruz. Bir cluster, bir grup makineden oluşur. Cluster içerisinde bir veya daha fazla worker makineler bulunur ve biz bu worker makinelerine Node adını veririz. Node'lar, uygulama iş yüklerimizi çalıştırır ve yönetir.

Cluster ayrıca bir veya daha fazla Master Node içerir. Master Node'lar, Kubernetes'in Control Plane bileşenlerini barındırır. Control Plane, cluster'ın yönetim ve kontrol işlevlerini yerine getiren bileşenlerin tümüdür ve şunları içerir:

• API Server: Tüm API isteklerini karşılar ve yönetir. Bu bileşen sayesinde biz istediğimiz işlemleri api üzerinden istek atarak kubernetes'e iletiriz. Kubernetes api server ana uygulaması kube-apiserver’dır. Yatay ölçeklenebilir.

• etcd: Cluster'ın tüm yapılandırma ve durum bilgilerini saklayan dağıtılmış anahtar-değer deposudur. Basitleştirmek gerekirse Kubernetes'in veritabanıdır.

• Controller Manager: Cluster'ın durumunu kontrol eden ve yönetim işlemlerini gerçekleştiren Node Controller, Job Controller, EndpointSlice Controller gibi bir çok controller çalıştırır. Her controller'ın ayrı bir görevi vardır.

• Scheduler: Yeni oluşturulan Pod'ları uygun Node'lara yerleştirir. Uygun node seçimini yaparken dikkate aldığı bir kaç faktör vardır.

  1. Kaynak Gereksinimleri: Pod'un CPU ve bellek gibi bireysel ve toplu kaynak ihtiyaçları, Node'un mevcut kaynaklarıyla karşılaştırılır.

  2. Donanım/Yazılım/Politika Kısıtlamaları: Pod'un belirli donanım veya yazılım gereksinimlerine ve organizasyon politikalarına uygun olup olmadığı kontrol edilir.

  3. Affinity ve Anti-Affinity Şartları: Pod'un belirli Node'lara yakın veya uzak olmasını sağlayan kurallar dikkate alınır.

  4. Veri Yerelleştirme: Pod'un kullanacağı veri kaynaklarının bulunduğu yer de dikkate alınır. Veri kaynaklarına yakın olmak, veri erişim hızını artırabilir.

  5. İş Yükleri Arası Etkileşim: Pod'ların diğer iş yükleriyle olan etkileşimleri göz önünde bulundurulur, bu etkileşimler performans ve güvenilirlik açısından önemlidir.

  6. Son Teslim Tarihleri: Pod'un belirli bir zaman diliminde çalışması veya tamamlanması gerekiyorsa, bu da yerleşim kararlarını etkileyebilir.

• Cloud Controller Manager: Cloud Provider ile etkileşimi sağlar ve cloud kaynaklarının yönetimini gerçekleştirir. Örneğin, load balancer oluşturma, Node'ların sağlıklı olup olmadığını kontrol etme gibi işlemleri yapar. Bu bileşen, AWS EKS (Elastic Kubernetes Service), Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS) gibi popüler cloud sağlayıcılar ile entegrasyonu kolaylaştırır. Cloud Controller Manager, bu hizmetler aracılığıyla otomatik ölçeklendirme, yük dengeleme ve cloud ortamında kaynak yönetimi gibi kritik görevleri yerine getirir.

Worker Node'lar, uygulamalarınızı çalıştıran birimlerdir ve her biri şu bileşenleri içerir:

• kubelet: Her Node'da çalışan ve Pod'ların durumunu API Server'a raporlayan ajan.

• kube-proxy: Ağ kurallarını uygulayan ve ağ trafiğini yönlendiren ağ bileşeni.

• Container Runtime: Konteynerlerin çalıştırıldığı ortam (örn. Docker, containerd).

Worker Node'lar üzerinde çalışan en küçük birim ise Pod'lardır. Pod'lar, aynı Node üzerinde çalışan bir veya daha fazla konteyneri barındıran yapılardır. Her Pod, kendi IP adresine ve depolama alanına sahip olabilir ve aynı Node üzerindeki diğer Pod'larla ağ paylaşımında bulunabilir. Kısacası, Kubernetes cluster, uygulamalarınızı dağıtmak ve yönetmek için birlikte çalışan bir Node ve Pod grubudur.

Kubernetes cluster'ının temel bileşenlerini incelediğimiz bu yazıda, cluster'ın yapı taşları olan Node'lar, Pod'lar ve Control Plane bileşenlerini tanıdık. Bu bileşenler, Kubernetes'in iş yüklerinizi etkili bir şekilde yönetmesini sağlar.

Özetle, Kubernetes cluster:

• Uygulama iş yüklerinizi çalıştıran ve yöneten worker Node'lar,

• Cluster'ın yönetim ve kontrol işlevlerini yerine getiren Master Node'lar,

• Yeni oluşturulan Pod'ları uygun Node'lara yerleştiren Scheduler,

• Cluster'ın tüm yapılandırma ve durum bilgilerini saklayan etcd,

• Tüm API isteklerini karşılayan ve yöneten API Server,

• Cluster'ın durumunu kontrol eden ve yönetim işlemlerini gerçekleştiren Controller Manager,

• Cloud provider ile etkileşimi sağlayan ve cloud kaynaklarının yönetimini gerçekleştiren Cloud Controller Manager,

• Her Node'da çalışan ve Pod'ların durumunu API Server'a raporlayan kubelet,

• Ağ kurallarını uygulayan ve ağ trafiğini yönlendiren kube-proxy,

• Konteynerlerin çalıştırıldığı ortam olan container runtime gibi bileşenlerden oluşur.

Bu temel bileşenlerin yanı sıra, Kubernetes'in iş yüklerinizi ve cluster'ınızı yönetmek için daha birçok bileşeni bulunmaktadır. Bu bileşenler, Kubernetes'in esnek ve ölçeklenebilir yapısını daha da güçlendirir.

Kubernetes'in temel bileşenlerini anlamak, Kubernetes'i verimli bir şekilde kullanmanın ilk adımıdır. Bu bilgilerin üzerine daha fazla araştırma yaparak, denemeler yaparak kubernetes konusunda kendinizi geliştirebilir ve uygulamalarınızı kubernetes ortamında çalıştırabilirsiniz. Bir sonraki yazımda Podlardan bahsedeceğim. Umarım sana dokunmuş olabilirim. Merak ettiğin bir şey olursa benimle iletişime geçebilirsin.

Kaynakçalar

1. https://kubernetes.io/docs/concepts/overview/components/

Kubernetes ve faydalarını daha iyi anlamak için, kubernetesin tarihçesinden bahsetmemizin iyi olacağını düşünüyorum. Günümüzde web trafiğinin büyük bir kısmı Google'ın hizmetleri, reklam ağları ve analiz araçları üzerinden geçmektedir. Google, insanoğlunun hayatına girdiği günden beri her zaman yoğun istekleri işleme ile karşı karşıya kalmıştır. Bu yoğun istekleri yönetmek için devamlı veri merkezlerine yeni sunucular, o sunucuların üstlerine yeni sistemler inşa etmek ve bunları uyumlu şekilde çalıştırmak için mücadele vermiştir. Tahmin edersiniz ki binlerce makineye sahip veri merkezlerini manuel yönetmek imkansıza yakın bir çalışma olur. Bunun sonucunda google tarafında bu süreçleri otonomize etme ihtiyacı doğdu.

Borg ve Omega'nın Gelişimi ve Birleşmesi

Google mühendisleri bu sunucuları yönetebilmek için bir cluster manager sistem geliştirmeye karar verdiler ve 2003 yılında Borg adında bir cluster manager sistem yazılımı geliştirdiler. Bu yazılım binlerce işi, binlerce makine üzerinde çalışan bir çok cluster arasında çalıştırmaya ve onları yönetmeye başladı. Borg sayesinde artık süreçleri otonomize etmeye başladılar. Ancak bir sorun vardı. Borg aslında kendi içerisinde karmaşık bir sistemdi ve onu yönetmek zaman ilerledikçe zorlamaya başlamıştı ve artan iş yükü ve çeşitlilik nedeniyle taleplere cevap veremez hale gelmeye başlamıştı. Onlara daha modüler ve esnek bir yapı sunabilecek bir sisteme ihtiyaçları vardı. Bu yüzden google mühendisleri kolları baştan sıvadılar ve modüler, esnek bir yapıya sahip olacak ve borg'un iyi yaptığı işleri daha iyi yapabilecek, zaman geçtikçe ihtiyaç duyulan özellikleri de içerecek bir sistem geliştirmeye başladılar. Bu sistemin adınada Omega adını verdiler. Omega, Borg'un bazı sınırlamalarını aşmak için geliştirilmiş bir sistemdi. Ancak, geliştirme sürecinde bazı teknik zorluklarla karşılaşıldı ve bu nedenle Omega, Borg ile entegre edildi. Omega, Borg'un üzerine eklenen modüler ve esnek özelliklerle Borg'un daha güçlü ve verimli hale gelmesini sağladı. Ayrıca omega tarafındaki bu geliştirmeler Google'da çalışan bazı mühendislere ilham oldu ve yeni bir açık kaynak sistem geliştirmelerine motivasyon sağladı.

Kubernetes'in Doğuşu

Craig Mcluckie, Brendan Burns, Joe Beda adındaki bu üç google mühendisi Borg ve Omega'nın sağladığı verimlilik ve esneklikten ilham alarak, bu özellikleri daha geniş bir geliştirici topluluğu ile paylaşmak amacıyla yeni bir sistem geliştirmeye karar verdiler. Project Seven adıyla geliştirilen proje, 2014 yılında Kubernetes adını alarak bu sistemi ekosistem ile paylaştılar. Bu yeni sistemi açık kaynak yaparak, tüm geliştiricilerin kullanmasına ve katkıda bulunmasına olanak sağladı. Bu şekilde ihtiyaçlar daha hızlı giderildi. Hatalar daha hızlı farkedildi ve düzeltildi. Ayrıca 2010'ların başında bulut bilişiminin hızlıca popülerleşmesi, dağıtık sistemlere duyulan ihtiyacın artması gibi durumlar sebebiyle devops süreçleri daha önemli hale gelmeye başladı. Kubernetes bulut ortamlarında kaynakları verimli kullanma ve devops süreçlerinin içerisinde olarak yazılım geliştirme ve dağıtım süreçlerinin otomasyonunu sağlaması ve süreçlerin hızını artırması ile birlikte zamanla ekosistemde popüler olmaya başladı.

Google, Kubernetes'i 2015 yılında Cloud Native Computing Foundation'a devretti. Bu adım, Kubernetes'in daha geniş bir açık kaynak topluluğu tarafından benimsenmesini ve geliştirilmesini sağladı. CNCF, Kubernetes'in geliştirilmesini destekleyerek, konteyner orkestrasyonu için endüstri standardı haline gelmesine yardımcı oldu.

Bu yazımda Kubernetes'in geçmişini, evrimini ve nasıl bir standart hale gelmesini anlatmaya çalıştım. Bir sonraki yazımda kubernetes'in kurulumuna ve temellerine gireceğiz. Umarım sana dokunmuş olabilirim. Merak ettiğin bir şey olursa benimle iletişime geçebilirsin.

Kaynakçalar:

1. https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/

2. https://research.google/pubs/omega-flexible-scalable-schedulers-for-large-compute-clusters/

3. https://www.cncf.io/

4. https://opensource.googleblog.com/2024/05/kubernetes-130-is-now-available-in-gke.html

Liskov Substitution Prensibi, nesne yönelimli tasarımda ilgili sınıflar arasında ikame edilebilirliğin (substitutability) ve davranışsal alt tiplendirmenin (behavioral subtyping) önemini vurgulayan temel bir prensiptir. İyi bir yazılım tasarımında olması gereken sürdürülebilirliği ve esnekliği teşvik eden beş SOLID ilkesinden biridir. LSP olarak kısaltılır. Bu prensip ilk kez 1987 yılında Barbara Liskov tarafından yayınlanan bir makale ile ortaya çıkmıştır. Barbara Liskov bu prensibin matematiksel formülünü aşağıdaki gibi tanımlamıştır.

Tanım

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

Tanım biraz karışık geldiyse, beraber bu tanımı açıklamaya çalışalım. Elimizde T adında bir sınıf olsun ve T sınıfından o2 adında bir nesne üretelim ve P adındaki uygulamamızda kullanalım. Ardından bir S sınıfı oluşturalım ve S sınıfından o1 adında başka bir nesne oluşturalım. Daha sonra biz o2 nesnesi yerine o1 nesnesini koyabilirsek ve bunu yaparken uygulamanın davranışları değişmezse S sınıfı, T sınıfının bir alt tipidir diyebiliriz. Bu durumda T sınıfı üst sınıf (parent class), S sınıfı ise alt sınıf (child class) diyebiliriz. Yani S sınıfı, T sınıfını miras almıştır ve T sınıfının tüm özelliklere sahiptir. Aslında bir çoğumuzda bu tanım nesne tabanlı programlamadaki inheritance konseptini aklımıza getiriyor olabilir. Böyle düşünmemiz doğrudur. Çünkü LSP, inheritance ile yakından ilişkilidir. LSP, inheritance nasıl uygulamamız konusunda bize bazı kurallar koyarak yol gösterir. Bu kurallar şunlardır:

1. Davranışı Koruma (Behavior Preservation): Alt sınıflar, üst sınıflarının yerine geçebilmeli ve bu durumda programın doğruluğunu bozmamalıdır. Yani, bir alt sınıfın nesnesi, üst sınıfın nesnesi olarak kullanıldığında, beklenen davranışın sağlanması gerekmektedir.
2. Değişmezler Korunmalıdır(Invariants must be preserved): Alt sınıflar, üst sınıflarının metot imzalarını (isim, parametreler, dönüş tipleri) korumalıdır. Bu, alt sınıf nesnelerinin üst sınıf nesneleri ile değiştirilebilir olmasını sağlar. Yani çok biçimlilik (Polymorphism) sağlar.
3. Ön Koşullar Güçlendirilemez (Preconditions cannot be strengthened): Alt sınıflar, üst sınıflarının metotlarındaki ön koşulları güçlendirmemelidir. Üst sınıfın ön koşullarını ya da daha gevşek koşulları kabul etmelidir.
4. Son Koşullar Zayıflatılamaz (Postconditions cannot be weakened): Alt sınıflar, üst sınıflarının metotlarındaki son koşulları zayıflatmamalıdır. Üst sınıfın son koşullarını ya da daha spesifik koşulları kabul etmelidir.
5. İstisna Kuralı (Exception Rule): Eğer üst sınıfın bir metodu istisna (exception) fırlatıyorsa, alt sınıfın o metodu, üst sınıfın fırlattığı istisnaların aynısını ya da alt türlerini fırlatabilmelidir. Bu, istisna türlerinin uyumlu bir şekilde işlenmesini sağlar.

Bu kurallara uyum sağlayarak geliştirlen sistemlerin tasarımları esnek, genişletilebilir ve sürdürebilir olur. Şimdi hep beraber bu prensibi ve kuralları örneklerle anlamaya çalışalım.

İlk örneğimizde Licence adında bir üst sınıf, PersonalLicence ve BusinessLicence adında iki alt sınıfımız var. Licence sınıfı içerisinde CalcFee adında bir metot var ve bu metot lisans ücretini hesaplıyor. PersonalLicence ve BusinessLicence sınıflarıda Licence sınıfını miras alıyor ve CalcFee metodunu ezerek(overriding) farklı hesaplamalar yaparak lisans bedelini dönüyor.

Figure 1

public class Licence
{
public virtual decimal CalcFee()
{
Console.WriteLine("Licence is calculating");
// Some calculations
return 120;
}
}

public sealed class PersonalLicence : Licence
{
public override decimal CalcFee()
{
Console.WriteLine("Personal licence is calculating");
// Some calculations
return 85;
}
}

public sealed class BusinessLicence : Licence
{
public override decimal CalcFee()
{
Console.WriteLine("Business licence is calculating");
// Some calculations
return 100;
}
}

Ayrıca Billing adında bir sınıfımız var. Bu sınıf oluşturulurken Licence tipinde bir parametre alıyor.

public sealed class Billing
{
private readonly Licence _licence;

public Billing(Licence licence)
{
_licence = licence;
}

public void CalcFee()
{
_licence.CalcFee();
}
}

Aşağıdaki kod parçasında ise üç farklı billing nesnesi oluşturdum. Nesneleri oluştururken Licence, PersonalLicence ve BusinessLicence nesnelerini sırasıyla parametre olarak verdim. Daha sonra her birinde CalcFee metodunu çağırdım.

var billing1 = new Billing(new Licence());
var billing2 = new Billing(new PersonalLicence());
var billing3 = new Billing(new BusinessLicence());
billing1.CalcFee();
billing2.CalcFee();
billing3.CalcFee();

Uygulamayı çalıştırdığımda aşağıdaki çıktıyı aldım.

Licence is calculating
Personal licence is calculating
Business licence is calculating

Bu örnekte üst sınıf olan Licence, Billing ile birlikte çalışabiliyor. Licence yerine Personal Licence ve Business Licence alt sınıflarının nesnelerini parametre olarak Billing servisine verdiğimizde uygulamamızın akışı bozulmadan çalışmaya devam edebiliyor. Böylece bu örnekte LSP’ye uygun bir şekilde geliştirme yapmış olduk.

İkinci örneğimizde LSP’yi ihlel eden bir senaryo oluşturmaya çalışalım. Calculator adında bir üst sınıf ve PositiveCalculator adında bir alt sınıfımız olsun. Calculator sınıfındaki Sum metodu 2 sayıyı alıyor ve toplayıp geri dönüyor. PositiveCalculator sınıfı ise Sum metodunu eziyor (overriding). Number1 ve number2 parametrelerine sıfır ya da sıfırdan büyük olma koşulu uyguluyor. Eğer bu koşul sağlanmaz ise hata fırlatıyor.

Figure 2

public class Calculator
{
public virtual int Sum(int number1, int number2)
{
return number1 + number2;
}
}

public sealed class PositiveCalculator : Calculator
{
public override int Sum(int number1, int number2)
{
if (number1 < 0)
{
throw new InvalidOperationException("number1 must be positive");
}

if (number2 < 0)
{
throw new InvalidOperationException("number1 must be positive");
}

return number1 + number2;
}
}

Calculator sınıfından bir nesne ürettiğimizde ve Sum metodunu çağırdığımızda uygulamamız beklediğimiz gibi çalışıyor.

Calculator calculator = new Calculator();
int result = calculator.Sum(-2, 8);

if (result != 6)
{
Console.WriteLine($"expected result 6, but result is {result}");
}
else
{
Console.WriteLine("The result is as expected");
}

Figure 3

Şimdi aynı kod parçasını PositiveCalculator ile deneyelim.

Calculator calculator = new PositiveCalculator();
int result = calculator.Sum(-2, 8);

if (result != 6)
{
Console.WriteLine($"expected result 6, but result is {result}");
}
else
{
Console.WriteLine("The result is as expected");
}

Figure 4

Calculator sınıfı yerine PositiveCalculator sınıfını kullandığımız zaman uygulamamızda beklenmedik bir şekilde bir hata aldık ve bu uygulamamızın akışını bozdu. Bu akışı düzeltmek için kodumuzu try catch bloğu içerisine alabiliriz. Ancak böyle bir değişim uygulamamızın akışını değiştirmek oluyor. Bizim amacımız üst sınıfın rahatlıkla çalışabildiği ortamlarda alt sınıflarında bir değişim olmadan rahatlıkla çalışabilmesi olmalıdır. PositiveCalculator sınıfı içerisindeki sum metodu içerisine eklediğimiz ön koşul yüzünden Ön koşullar güçlendirilemez kuralını ihlal ettik. Üst sınıfın bilmediği bir hatayı alt sınıfta fırlattığımız için ve istemci böyle bir hatadan haberdar olmadığı için uygulamamızın beklenmedik bir şekilde kapanmasına neden oldu. Son olarak uygulamanın akışı bozulduğu için Davranışı Koruma kuralını da ihlal ettik. Yani LSP’yi ihlal etmiş olduk.

LSP, geliştiricileri “is-a” ilişkisine tüm yönleriyle uymaya çalışan sınıflar ve hiyerarşiler tasarlamaya teşvik ederek sürdürülebilir, genişletilebilir ve öngörülebilir yazılım sistemleri oluşturmak için bir temel sağlar. LSP’yi uygulayarak daha modüler, uyumlu çalışabilen kodlar yazılabilir. Yeni sınıfların ve özelliklerin kolay entegrasyonu sağlanabilir. Kod tabanını zaman içerisinde oluşabilecek değişikliklere karşı daha dayanıklı hale getirebilir. LSP uyumluluğu, yüksek kaliteli nesne yönelimli kod yazmanın önemli bir yönüdür. Yazılım projelerinin genel sağlığına ve uzun ömürlülüğüne katkıda bulunur.

Bu yazımda Liskov Substitution Prensibini anlatmaya çalıştım. Umarım sana dokunmuş olabilirim. Merak ettiğin bir şey olursa benimle iletişime geçebilirsin.

— Bana ulaşmak için: Twitter, Linkedin

Open-Closed prensibi, ben dahil bir çoğumuz için SOLID prensiplerini araştırırken karşısına çıkan 5 prensipten birisidir. “O” harfine karşılık gelir. OCP olarak kısaltırılır. Aslında SOLID arka arkaya bir kişi tarafından ortaya atılmış prensipler değildir. OCP 1988 yılında Bertrand Meyer tarafından ortaya atılmış bir prensiptir. Daha sonra Robert C. Martin OCP ile 4 diğer prensibi bir bütün halinde insanlara aktarmaya çalışmıştır. Open-Closed prensibini ilk ortaya atan Bertrand Meyer prensibi aşağıdaki gibi açıklamıştır.

A software artifact (classes, modules, functions, etc.) should be open for extension but closed for modification.

Türkçe’ye çevirmek istersek; Bir yazılım genişlemeye açık, fakat değişime kapalı olmalıdır. Başka bir söylemle, bir yazılımının yapısını ve davranışını değiştirmek zorunda kalmadan, genişletilebilir olmasıdır. Bertrand Meyer çözüm olarak kalıtımı (inheritance) önermiştir. Kalıtım ile sınıfları genişletmeyi amaçlamıştır. Eğer bir sınıfın genişlemeye ihtiyacı varsa ondan türeyen yeni bir alt sınıf oluşturmayı önermiştir. Bu oluşturulan yeni alt sınıfa, ihtiyaç duyulan yeni değişkenler, methodlar eklenerek genişlemenin sağlanabileceğini belirtmiştir.

Günümüzde bu yöntem OCP için çok uygulanmasada tarihteki ilk tanımı ve çözümü bu şekilde ortaya atılmıştır. Ancak bu çözümün bazı sıkıntıları vardır. Öncelikle kalıtım (inheritance) yoluyla oluşturulan alt sınıflar, üst sınıfın methodlarına, değişkenlerine bağlı ise iki sınıf arasında sıkı bir bağımlılık (tight coupling) oluşturur. Birbirine sıkı bağımlı yapılar esnemez ve kırılgan sistemler oluşturur. Bizim amacımız gevşek bağımlı (loose coupling) yapılar oluşturarak esnek sistemler geliştirmektir. Bir diğer problem ise c#, java, kotlin, swift gibi dillerde bir alt sınıfın sadece bir üst sınıftan türetilebilir olmasıdır. Bir sınıfa birden fazla yeni özellik eklemek istediğimizde, bunu tek bir kalıtım ile yapamayacağımız için devamlı birbirinden türeyen sınıflar oluşturmak zorunda kalacağız. Bu da yönetmemiz ve bakımını yapmamız gereken çok fazla sınıflar ortaya çıkaracaktır. Bir başka problem ise zaman içerisinde mevcut sınıflardan türetilen yeni sınıfların Liskov Substitution Prinsibini ihlal edebilir olmasıdır. Bu ihlal de bize başka teknik borçlara ve problemlere yol açabilir.

Robert C. Martin OCP’iyi tekrardan ele aldı ve yeni bir çözüm ortaya koydu. Bu çözümü oluştururken soyutlama (abstraction) ve çok biçimliliğin (polymorphism) güçlerinden faydalandı. Robert C. Martin üst sınıflar yerine arayüz(interface) kullanmayı tercih etti. Yeni gelen bir geliştirme talebi olduğunda, yeni bir sınıf oluşturdu ve ilgili arayüzü (interface) yeni sınıfa uyguladı**(implementation)** ve detayları oluşturduğu sınıf içerisinde tanımladı. Arayüzün kullanıldığı diğer sınıflarda herhangi bir değişiklik yapmadan yeni özellikleri ekledi. Yeni oluşturduğu sınıfları çok biçimlilik (polymorphism) sayesinde arayüzün kullandığı sınıflara parametre olarak verebilmiş oldu. Bu çözüm sayesinde gereksiz kalıtım (inheritance) işlemlerinden kurtuldu, soyutlama(abstraction) yaparak gevşek bağımlı(loose coupling) yapılar ortaya çıkardı ve esnek bir sistem kurmayı başardı.

Bu prensibi bir örnek ile anlatmaya çalışalım. Öncelikle Open-closed prensibini ihlal edebilecek bir kod yapısı üzerine konuşalım. Ardından bunu nasıl düzeltiriz ve nasıl Open-Closed prensibine uygun hale getirebiliriz bakalım. Örneğimizde müşterilerin türüne göre taşıma bedelini hesaplayalım. İş modelimize göre 2 farklı müşteri türümüz var. Bu müşteri türleri Default ve Silver olsun. Sistem içerisinde son 6 ayda yapılan taşıma sayısının 10 adedi geçmeyen müşterilere Default müşteri ve son 6 ayda yapılan taşıma sayısının 10 ve üzeri olduğu müşterilere de Silver müşteri diyelim. Default müşterilerimizden kilogram başına 50,00 TRY ve Silver müşterilerimizden kilogram başına 30,00 TRY ücret alınacak olsun. Örneğin gelen ağırlığımız 1.000 kg olursa, taşıma bedeli Default müşterilerimiz için 1.000 * 50,00 = 50.000 TRY ve Silver müşterilerimiz için 1.000 * 30,00 = 30.000 TRY olacaktır. Bu koşullara göre aşağıdaki kodu geliştirdiğimizi düşünelim.

public enum CustomerType
{
    Default,
    Silver
}

public class ShippingService
{
    public double CalculateShippingCost(CustomerType customerType, double totalWeightAsKg)
    {
        return customerType switch
        {
            CustomerType.Default => totalWeightAsKg * 50.0,
            CustomerType.Silver => totalWeightAsKg * 30.0,
            _ => throw new NotSupportedException("Invalid customer type")
        };
    }
}

Elimizde CustomerType adında bir enum ve ShippingService adında bir sınıf var. Bu sınıf CalculateShippingCost adında bir method barındırıyor. Bu method parametre olarak CustomerType ve toplam taşınacak malın ağırlığını alıyor. CustomerType göre müşterinin kilogram başına ücreti belirleniyor ve toplam ağırlık ile çarpılarak taşıma bedeli ortaya çıkıyor. Bu istekleri karşılayan bir kod yazdık ve test ettik. Herşey doğru bir şekilde çalışıyor. Bir süre sonra iş modelimizin değiştiğini ve Gold türünde yeni bir müşteri türü daha eklendiğini öğrendik. Gold türündeki bir müşterinin fiyat hesaplaması yapılırken kilogram başına 15,00 TRY ücret belirlendiğini öğrendik. Bizim bu koşuluda karşılayacak geliştirmeyi yapmamız gerekiyor.

public enum CustomerType
{
    Default,
    Silver,
    Gold
}

public class ShippingService
{
    public double CalculateShippingCost(CustomerType customerType, double totalWeightAsKg) {
        return customerType switch
        {
            CustomerType.Default => totalWeightAsKg * 50.0,
            CustomerType.Silver => totalWeightAsKg * 30.0,
            CustomerType.Gold => totalWeightAsKg * 15.0,
            _ => throw new NotSupportedException("Invalid customer type")
        };
    }
}

Yukarıdaki kod örneğinde gerekli geliştirmeyi yaptık. Peki, bu yaptığımız geliştirme yöntemi doğru bir yöntem mi? Bir sonraki talepte Platinum, Diamond gibi farklı müşteri türleri daha eklenmek istenirse ne yapacağız? Burayı gelip tekrardan gerekli yerlere eklemeler yapmak mı isteyeceğiz? Tüm bunlar Open-Closed prensibini ihlal eden davranışlardır. Her yeni bir talepte var olan kodu değiştirmek, çalıştığına emin olduğumuz kod parçaların tutarlığının tekrardan sorgulanmasına sebep olabilir. Bir değişim gördüğü için test edilmesi gerekir. Yapılan değişimler bize başka noktalarda başka hatalara sebep olabilir. Peki bunu Open-Closed prensibine göre nasıl geliştirebiliriz?

public interface ICalculateShippingCostService
{
    double Calculate(double totalWeightAsKg);
}

public sealed class DefaultCalculateShippingCostService : ICalculateShippingCostService
{
    public double Calculate(double totalWeightAsKg)
    {
        const double pricePerWeightAsKg = 50.0;
        var totalPrice = pricePerWeightAsKg * totalWeightAsKg;
        return totalPrice;
    }
}

public sealed class SilverCalculateShippingCostService : ICalculateShippingCostService
{
    public double Calculate(double totalWeightAsKg)
    {
        const double pricePerWeightAsKg = 30.0;
        var totalPrice = pricePerWeightAsKg * totalWeightAsKg;
        return totalPrice;
    }
}

public sealed class GoldCalculateShippingCostService : ICalculateShippingCostService
{
    public double Calculate(double totalWeightAsKg)
    {
        const double pricePerWeightAsKg = 15.0;
        var totalPrice = pricePerWeightAsKg * totalWeightAsKg;
        return totalPrice;
    }
}

public class ShippingService
{
    private readonly ICalculateShippingCostService _calculateShippingCostService;

    public ShippingService(ICalculateShippingCostService calculateShippingCostService)
    {
        _calculateShippingCostService = calculateShippingCostService;
    }

    public double CalculateShippingCost(double totalWeightAsKg)
    {
        return _calculateShippingCostService.Calculate(totalWeightAsKg);
    }
}

Yukarıdaki geliştirdiğimiz koda baktığımızda ICalculateShippingCostService adında bir arayüz(interface) oluşturduk. Arayüz içerisinde Calculate adında bir method tanımladık. Daha sonra DefaultCalculateShippingCostService, SilverCalculateShippingCostService, GoldCalculateShippingCostService adında 3 adet sınıf oluşturduk. Hepsi ICalculateShippingCostService arayüzünü uyguladı ve her biri Calculate methodu içerisinde gerekli geliştirmeler yapıldı. ShippingService refactor edip yeniden düzenledik. Artık constructor içerisinde ICalculateShippingCostService arayüzünü parametre olarak alıyoruz ve CalculateShippingCost methodu içerisinde arayüzün Calculate methodunu çağırıyoruz. Bu şekilde Open-Closed prensibi uygulayan bir kod yapısına sahip olduk. İleride Platinum, Diamond gibi farklı müşteri türleri gelsede mevcut kodu değiştirmeden yeni sınıflar oluşturarak mevcut sistemimizi genişletebileceğiz.

Özetlemek gerekirse, Open-Closed prensibi sistemimize esneklik katar. Sistemi genişlemeye açık olacak şekilde tasarladığımız için mevcut kodu değiştirmeden yeni özellikler, işlevler ekleyebiliriz. Değişime karşı direnci düşük seviyede tutarız. Ayrıca bakım maliyetleri daha az olur. Open-Closed prensibi ile mevcut kodu değiştirmediğimiz için mevcut kodumuzda hata oluşma riskini azaltmış oluruz. Ölçeklenebilir sistemler kurabiliriz. Yeni gereksinimler ortaya çıktıkça mevcut sistemimizi değiştirmek zorunda kalmadan yeni sınıflar ekleyebiliriz. Böylece modüler bir sistem kurmuş oluruz. Yeniden kullanılabilen kod bloklarını geliştirmiş oluruz. OCP’ye uygun yaptığımız örnekte de gördüğünüz gibi GoldCalculateShippingCostService adında bir sınıfımız var. Bu sınıfımız ihtiyaç halinde başka noktalarda da kullanabiliriz. Örneğimizde ShippingService içerisindeki CalculateShippingCost methodu sadece Calculate adında bir methodu çağırıyor**.** Bunun dışında hesaplama ile ilgili hiçbir bilgiye sahip değil. OCP sayesinde kapsülleme (encapsulation) yaparak uygulama ayrıntılarını gizleyebiliriz.

Bu yazımda Open-Closed prensibini anlatmaya çalıştım. Umarım sana dokunmuş olabilirim. Merak ettiğin bir şey olursa benimle iletişime geçebilirsin.

Bugünkü yazımızda AWS CDK ile serverless uygulama geliştireceğiz. Serverless compute, bir sunucunun sorumluluğunu almadan uygulamalarımızı ya da servislerimizi derlemeyi ve çalıştırmayı sağlayan sistemlerdir. Serverless ile uygun maliyetli, esnek, ölçeklenebilir, her zaman kullanılabilir sistemler tasarlayabiliriz. Tüm bunları yaparken sunucu yönetimi (kurulum, bakım, güvenlik) gibi önemli bir sorumluluğuda AWS bırakırız.

Bu örnek projemizde bir apigateaway servisi oluşturacağız ve bu oluşturduğumuz apigateaway, kullanıcıların isteklerini karşılayacak. Gelen istekleri lambda servislerine yönlendirecek. Lambda servisleri dynamodb üzerinde okuma ya da yazma işlemlerini yapacak ve cevabı geri döndürecek. Tüm bu süreçleri, typescript dili ve aws cdk kütüphanesi ile kodlayarak oluşturacağız. Modellediğimiz bulut altyapısınıda cloudformation ile deploy edeceğiz.

AWS CDK, Serverless ve yapacağımız uygulama hakkında kısaca bahsettik. Şimdi yapacağımız uygulamaya geçelim. Bir AWS Cdk uygulaması oluşturabilmemiz için bilgisayarımızda aws-cdk npm paketi global olarak yüklü olması gerekiyor.

npm install -g aws-cdk

Yukarıdaki kod ile aws-cdk paketini bilgisayarımıza indiriyoruz. Daha sonra mkdir ile yeni bir klasör oluşturuyoruz ve cd ile o klasörün içerisine geçiyoruz. cdk init ile bir aws cdk uygulaması oluşturuyoruz ve projenin dilinin typescript olacağını belirtiyoruz.

mkdir ProductServerlessApplication
cd ProductServerlessApplication
cdk init --language typescript

Bu işlem sonunda cdk uygulamamız oluşmuş oluyor. Uygulamayı vscode ile açtığımızda uygulamanın yapısı aşağıda görebilirsiniz.

cdk application structure

bin klasörü genişlettiğimizde product_serverless_application.ts dosyasını görüyoruz. Bu dosyayı açtığımızda bir cdk.App nesnesi ve bir alt satırda ise ProductServerlessApplicationStack nesnesinin oluşturulduğunu görüyoruz.

lib klasörünü genişleştiğimizde product_serverless_application-stack.ts adında bir dosya bulacağız. Bu dosyayı açtığımızda cdk.Stack miras alan bir ProductServerlessApplicationStack sınıfı görüyoruz.

Bir cdk uygulamasının yapısı aşağıdaki görseldeki gibidir. Her AWS CDK uygulamasında bir App ve bir ya da birden fazla Stack olabilir. cdk.Stack AWS CloudFormationdaki Stacklere karşılık gelir. Her bir stack deployment birimidir. Stackleri birbirinden bağımsız bir şekilde deploy edebiliriz ancak bir stack kapsamında tanımlanan tüm AWS kaynakların tümü birlikte deploy edilecektir. Construct, aws cdk uygulamasındaki temel yapı taşıdır. Her bir construct, aws’deki bulut bileşinini temsil eder. Bir construct içerisinde bir ya da birden fazla aws kaynakları bulunabilir. Bir stack içerisinde bir ya da birden fazla Construct olabilir.

AWS CDK uygulamasındaki temel konseptlerden kısaca bahsettikten sonra örnek uygulamamızda bir app, bir stack ve bir adet construct bulunacak.

lib klasörü içerisine modules adında bir klasör oluşturdum. modules içerisine products adında başka bir klasör oluşturdum. Ayrıca hataları yönetebilmek için modules içerisine api-error.ts dosyasını oluşturdum.

export class ApiError extends Error {
statusCode: number = 0;
message: string = "";

constructor(statusCode: number, message: string) {
super();
this.statusCode = statusCode;
this.message = message;
}
}

products klasörü altına services adında bir klasör oluşturdum. services klasörüne lambda servislerimizi koyacağız. products klasörü içerisine ayrıca product-construct.ts adında dosya oluşturdum. product-construct.ts dosyasını açıp product construct tanımlaması yaptım.

modules directory

import { Construct } from "constructs";

export class ProductConstruct extends Construct {
constructor(scope: Construct, id: string) {
super(scope, id);
}
}

ProductConstruct oluşturduktan sonra ProductServerlessApplicationStack gelip ProductConstruct nesnesini oluşturdum.

import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import { ProductConstruct } from "./modules";

export class ProductServerlessApplicationStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);

new ProductConstruct(this, "Products");
}
}

Bu şekilde bir construct’ı stack ile bağlamış olduk. Şimdi lambda servislerimizi yazalım. İlk yazacağımız servis ürün oluşturmamızı sağlayacak. Her ürünün bir id değeri olacak ve id değerini uuid şeklinde tutacağız. Bu yüzden uuid npm paketini indirmemiz gerekiyor.

npm install uuid
npm install --include\=dev @types/uuid

Yukarıdaki kodlar ile uuid ve uuid types paketlerini indirmiş olduk. Bu örnek uygulamada ürünlerimizi dynamodb üzerinde saklayacağız. Bu yüzden dynamodb client nesnesi oluşturabilmek, put command, update command, scan command sınıflarına erişebilmek için dynamodb npm paketini indirmeliyiz.

npm install @aws-sdk/client-dynamodb

Son olarak lambda sınıflarına, type tanımlamalarına erişebilmek için aws-lambda types npm paketini indirmeliyiz.

npm install --include\=dev @types/aws-lambda

services klasörü içerisine create.ts adında bir dosya oluşturdum. Bir ürün oluşturabilmek için ürünün başlık, açıklama ve ücret parametreleri alıyoruz.

// create.ts
import { APIGatewayEvent, APIGatewayProxyResult, Context } from "aws-lambda";
import {
AttributeValue,
DynamoDBClient,
PutItemCommand,
} from "@aws-sdk/client-dynamodb";
import { v4 as uuidv4 } from "uuid";
import { ApiError } from "../../api-error";

export const handler = async (
event: APIGatewayEvent,
context: Context
): Promise => {
try {
const requestBodyJSON = JSON.parse(event.body ?? "{}");
const title = (requestBodyJSON["title"] ?? "") as string;
const description = (requestBodyJSON["description"] ?? "") as string;
const price = (requestBodyJSON["price"] ?? "") as string;

if (title.length === 0) {
throw new ApiError(400, "Title is required");
}

if (description.length === 0) {
throw new ApiError(400, "Description is required");
}

if (price.length === 0) {
throw new ApiError(400, "Price is required");
}

if (isNaN(Number(price))) {
throw new ApiError(400, "Price is not valid");
}

const productId = uuidv4();

const client = new DynamoDBClient({});

const newRecord: Record = {
id: {
S: productId,
},
title: {
S: title,
},
description: {
S: description,
},
price: {
N: parseFloat(price).toFixed(2),
},
is_deleted: {
BOOL: false,
},
created_date: {
S: new Date().toUTCString(),
},
};

const command = new PutItemCommand({
TableName: "products",
Item: newRecord,
});

await client.send(command);

return {
statusCode: 201,
body: JSON.stringify({
data: {
title: title,
description: description,
price: price,
id: productId,
},
}),
};
} catch (error) {
if (error instanceof ApiError) {
return {
statusCode: error.statusCode,
body: JSON.stringify({
message: error.message,
}),
};
}
return {
statusCode: 500,
body: JSON.stringify({
message: "Unknown Error",
}),
};
}
};

Burada kullanıcıdan gelen başlık, açıklama ve ücret parametrelerini basit bir kaç kontrolden geçirdikten sonra dynamodb’ye yeni bir kayıt eklemek için PutItemCommand sınıfını kullanıyoruz ve oluşturulan nesneyi send methoduna parametre olarak vererek yeni bir ürün oluşturuyoruz.

Sırada bir ürünü güncellemek için kullanacağımız fonksiyonu yazalım. Bunun için services klasörü altında update.ts adında bir dosya oluşturuyoruz.

//update.ts
import { APIGatewayEvent, APIGatewayProxyResult, Context } from "aws-lambda";
import {
AttributeValue,
DynamoDBClient,
UpdateItemCommand,
} from "@aws-sdk/client-dynamodb";
import { validate as uuidValidate } from "uuid";
import { ApiError } from "../../api-error";

export const handler = async (
event: APIGatewayEvent,
context: Context
): Promise => {
try {
const pathParameters = event.pathParameters ?? {};
const productId = pathParameters["id"] ?? "";

const requestBodyJSON = JSON.parse(event.body ?? "{}");
const title = (requestBodyJSON["title"] ?? "") as string;
const description = (requestBodyJSON["description"] ?? "") as string;
const price = (requestBodyJSON["price"] ?? "") as string;

if (productId.length === 0) {
throw new ApiError(400, "Product Id is required");
}

if (!uuidValidate(productId)) {
throw new ApiError(400, "Product Id is not valid");
}

if (title.length === 0) {
throw new ApiError(400, "Title is required");
}

if (description.length === 0) {
throw new ApiError(400, "Description is required");
}

if (price.length === 0) {
throw new ApiError(400, "Price is required");
}

if (isNaN(Number(price))) {
throw new ApiError(400, "Price is not valid");
}

const client = new DynamoDBClient({});

const command = new UpdateItemCommand({
TableName: "products",
Key: {
id: {
S: productId,
},
},
UpdateExpression:
"set title = :title, description = :description, price = :price",
ConditionExpression: "id = :id and is_deleted = :is_deleted",
ExpressionAttributeValues: {
":title": { S: title },
":description": { S: description },
":price": { N: parseFloat(price).toFixed(2) },
":id": { S: productId },
":is_deleted": { BOOL: false },
},
ReturnValues: "ALL_NEW",
});

await client.send(command);

return {
statusCode: 200,
body: JSON.stringify({
data: {
title: title,
description: description,
price: price,
id: productId,
},
}),
};
} catch (error) {
if (error instanceof ApiError) {
return {
statusCode: error.statusCode,
body: JSON.stringify({
message: error.message,
}),
};
}
return {
statusCode: 500,
body: JSON.stringify({
message: "Unknown Error",
}),
};
}
};

Ürünü güncellemek için ürün id, başlık, açıklama, ücret parametrelerini kullanıcıdan alıyoruz. Bunları kontrollerden geçirdikten sonra ürünü güncellemek için UpdateItemCommand sınıfını kullanarak bir nesne oluşturuyoruz. Daha sonra send methodu ile ürün verisini güncelliyoruz.

Sıradaki servisimiz ürün silme fonksiyonu. services klasörü içerisine delete.ts dosyasını oluşturuyoruz.

//delete.ts
import { APIGatewayEvent, APIGatewayProxyResult, Context } from "aws-lambda";
import { validate as uuidValidate } from "uuid";
import { ApiError } from "../../api-error";
import { DynamoDBClient, UpdateItemCommand } from "@aws-sdk/client-dynamodb";

export const handler = async (
event: APIGatewayEvent,
context: Context
): Promise => {
try {
const pathParameters = event.pathParameters ?? {};
const productId = pathParameters["id"] ?? "";

if (productId.length === 0) {
throw new ApiError(400, "Product Id is required");
}

if (!uuidValidate(productId)) {
throw new ApiError(400, "Product Id is not valid");
}
const client = new DynamoDBClient({});

const command = new UpdateItemCommand({
TableName: "products",
Key: {
id: {
S: productId,
},
},
UpdateExpression: "set is_deleted = :is_deleted",
ConditionExpression: "id = :id and is_deleted = :current_is_deleted",
ExpressionAttributeValues: {
":id": { S: productId },
":current_is_deleted": { BOOL: false },
":is_deleted": { BOOL: true },
},
ReturnValues: "ALL_NEW",
});

await client.send(command);

return {
statusCode: 200,
body: JSON.stringify({
message: "Product is deleted",
}),
};
} catch (error) {
if (error instanceof ApiError) {
return {
statusCode: error.statusCode,
body: JSON.stringify({
message: error.message,
}),
};
}
return {
statusCode: 500,
body: JSON.stringify({
message: "Unknown Error",
}),
};
}
};

Ürün silme fonksiyonu, ürün güncelleme fonksiyonu ile mantık olarak aynı. Bu örnekte ürünü veritabanından tamamen silmek yerine is_deleted değerini true yaparak silinmiş olarak işaretliyoruz.

Son olarak ürünleri getirecek olan fonksiyonumuzu yazalım. Bunun için services klasörü altına get-list.ts dosyasını açalım.

// get-list.ts
import { DynamoDBClient, ScanCommand } from "@aws-sdk/client-dynamodb";
import { APIGatewayEvent, APIGatewayProxyResult, Context } from "aws-lambda";
import { ApiError } from "../../api-error";

export interface ProductDto {
id: string;
title: string;
description: string;
price: number;
}

export const handler = async (
event: APIGatewayEvent,
context: Context
): Promise => {
try {
const client = new DynamoDBClient({});

const command = new ScanCommand({
FilterExpression: "is_deleted = :is_deleted",
ExpressionAttributeValues: {
":is_deleted": { BOOL: false },
},
TableName: "products",
});

const response = await client.send(command);

const productList: ProductDto[] = (response.Items ?? []).map((p) => {
return {
id: p["id"].S ?? "",
title: p["title"].S ?? "",
description: p["description"].S ?? "",
price: parseFloat(p["price"].N ?? "0.0"),
};
});

return {
statusCode: 200,
body: JSON.stringify({
data: productList,
}),
};
} catch (error) {
if (error instanceof ApiError) {
return {
statusCode: error.statusCode,
body: JSON.stringify({
message: error.message,
}),
};
}
return {
statusCode: 500,
body: JSON.stringify({
message: "Unknown Error",
}),
};
}
};

ScanCommand sınıfını dynamodb’den verileri çekmek için kullanırız. Burada is_deleted=false olan ürünleri istediğimiz için filtreme yaptık ve send methodu ile ürünleri dynamodb’den aldık. Temel crud işlemlerini yapan fonksiyonları yazdığımıza göre artık bunları lambda olarak tanımla işlemini geçebiliriz. Bunun için ProductConstruct içerisine geri dönüyoruz.

import { Construct } from "constructs";
import { NodejsFunction } from "aws-cdk-lib/aws-lambda-nodejs";
import { Runtime } from "aws-cdk-lib/aws-lambda";
import { join } from "path";
import { Duration } from "aws-cdk-lib";
import * as apigateway from "aws-cdk-lib/aws-apigateway";
import { AttributeType, Table } from "aws-cdk-lib/aws-dynamodb";
import * as cdk from "aws-cdk-lib";

export class ProductConstruct extends Construct {
constructor(scope: Construct, id: string) {
super(scope, id);

const restApiId = "ProductApi";
const dynamoProductTableName = "products";

const dynamoProductTable = new Table(this, dynamoProductTableName, {
partitionKey: {
name: "id",
type: AttributeType.STRING,
},
tableName: dynamoProductTableName,
removalPolicy: cdk.RemovalPolicy.RETAIN,
});

const productApiGateaway = new apigateway.RestApi(this, restApiId, {
restApiName: "Product Api",
description: "Product Rest Api",
deploy: true,
deployOptions: {
stageName: "prod",
tracingEnabled: true,
},
endpointTypes: [apigateway.EndpointType.EDGE],
});

const createProductFunction = new NodejsFunction(this, "CreateProduct", {
runtime: Runtime.NODEJS_18_X,
entry: join(__dirname, "services", "create.ts"),
timeout: Duration.minutes(1),
memorySize: 512,
});

const putProductFunction = new NodejsFunction(this, "PutProduct", {
runtime: Runtime.NODEJS_18_X,
entry: join(__dirname, "services", "update.ts"),
timeout: Duration.minutes(1),
memorySize: 512,
});

const deleteProductFunction = new NodejsFunction(this, "DeleteProduct", {
runtime: Runtime.NODEJS_18_X,
entry: join(__dirname, "services", "delete.ts"),
timeout: Duration.minutes(1),
memorySize: 512,
});

const getProductListFunction = new NodejsFunction(this, "getProductList", {
runtime: Runtime.NODEJS_18_X,
entry: join(__dirname, "services", "get-list.ts"),
timeout: Duration.minutes(1),
memorySize: 512,
});

dynamoProductTable.grantReadWriteData(createProductFunction);
dynamoProductTable.grantReadData(getProductListFunction);
dynamoProductTable.grantReadWriteData(putProductFunction);
dynamoProductTable.grantReadWriteData(deleteProductFunction);

const getProductListFunctionIntegration = new apigateway.LambdaIntegration(
getProductListFunction
);

const createProductFunctionIntegration = new apigateway.LambdaIntegration(
createProductFunction
);

const putProductFunctionIntegration = new apigateway.LambdaIntegration(
putProductFunction
);

const deleteProductFunctionIntegration = new apigateway.LambdaIntegration(
deleteProductFunction
);

const productResource = productApiGateaway.root.addResource("products", {});
const productResourceWithId = productResource.addResource("{id}");

productResource.addMethod("GET", getProductListFunctionIntegration);

productResource.addMethod("POST", createProductFunctionIntegration);

productResourceWithId.addMethod("PUT", putProductFunctionIntegration);

productResourceWithId.addMethod("DELETE", deleteProductFunctionIntegration);
}
}

İlk önce bir dynamodb tablosuna ihtiyacımız olduğu için construct içerisinde tablo oluşturduk. partitionKey basit bir primary key’dir. Bu gerekli bir parametredir. ismini ve tipini belirttim. tableName tablonun adıdır. RemovalPolicy dynamodb tablosunun CloudFormation tarafından yönetilmesinin durdurulması durumunda tablonun durumunun ne olacağını kontrol eder. 3 farklı durum vardır:

1. Destroy: Tabloyu yok et.
2. Retain: Tabloyu tutmaya devam et.
3. Snapshot: Tabloyu yok et, ancak yok etmeden önce bir kopyasını al ve onu sakla.

Bir çok kaynakta Retain default seçenektir.

const dynamoProductTableName = "products";

const dynamoProductTable = new Table(this, dynamoProductTableName, {
partitionKey: {
name: "id",
type: AttributeType.STRING,
},
tableName: dynamoProductTableName,
removalPolicy: cdk.RemovalPolicy.RETAIN,
});

Daha sonra bir apigateaway kaynağına ihtiyacımız var. Kullanıcıyı bir ürün oluşturmak, güncellemek, silmek ya da ürünleri getirmek istediğinde apigateaway ile karşılayacağız. apigateaway ile bir RestApi oluşturduk ve deploy değerini true yaptık. Bu şekilde rest api direk dış dünyaya açmış olduk. deployOptions ile stageName ve tracingEnabled değerlerimizi verdik. tracingEnabled değerine true vererek Amazon X-Ray izlemeyi aktifleştirdik. endpointTypes değerine ise apigateway.EndpointType.EDGE değerini verdik. Bu restApi’lar için varsayılan bir değerdir. EDGE dışında REGIONAL ve PRIVATE değerler vardır.

const restApiId = "ProductApi";
const productApiGateaway = new apigateway.RestApi(this, restApiId, {
restApiName: "Product Api",
description: "Product Rest Api",
deploy: true,
deployOptions: {
stageName: "prod",
tracingEnabled: true,
},
endpointTypes: [apigateway.EndpointType.EDGE],
});

Daha sonra NodeJs lambda fonksiyonlarını tanımladık. lambda fonksiyonlarımın çalışacağı runtime versiyonunu nodejs18 seçtik. timeout olarak 1 dakika verdik. lambda fonksiyonun kullanacağı memorySize değerini 512mb olarak belirledik. Son olarak entrye değer olarak lambda fonksiyonun çalıştıracağı handler fonksiyonlarını verdik.

const createProductFunction = new NodejsFunction(this, "CreateProduct", {
runtime: Runtime.NODEJS_18_X,
entry: join(__dirname, "services", "create.ts"),
timeout: Duration.minutes(1),
memorySize: 512,
});

const putProductFunction = new NodejsFunction(this, "PutProduct", {
runtime: Runtime.NODEJS_18_X,
entry: join(__dirname, "services", "update.ts"),
timeout: Duration.minutes(1),
memorySize: 512,
});

const deleteProductFunction = new NodejsFunction(this, "DeleteProduct", {
runtime: Runtime.NODEJS_18_X,
entry: join(__dirname, "services", "delete.ts"),
timeout: Duration.minutes(1),
memorySize: 512,
});

const getProductListFunction = new NodejsFunction(this, "getProductList", {
runtime: Runtime.NODEJS_18_X,
entry: join(__dirname, "services", "get-list.ts"),
timeout: Duration.minutes(1),
memorySize: 512,
});

Bu lambda fonksiyonların dynamodb ile etkileşime geçebilmesi için gerekli izinleri lambda servislerine vermemiz gerekiyor. Create, update, delete servislerine okuma(read) ve yazma(write) izinlerini, get list servisine ise sadece okuma (read) iznini verdik.

dynamoProductTable.grantReadWriteData(createProductFunction);
dynamoProductTable.grantReadData(getProductListFunction);
dynamoProductTable.grantReadWriteData(putProductFunction);
dynamoProductTable.grantReadWriteData(deleteProductFunction);

Oluşturduğumuz apigateaway ile lambda fonksiyonları entegre etmemiz gerekiyor.

const getProductListFunctionIntegration = new apigateway.LambdaIntegration(
getProductListFunction
);

const createProductFunctionIntegration = new apigateway.LambdaIntegration(
createProductFunction
);

const putProductFunctionIntegration = new apigateway.LambdaIntegration(
putProductFunction
);

const deleteProductFunctionIntegration = new apigateway.LambdaIntegration(
deleteProductFunction
);

Lambda fonksiyonlarını apigateaway ile entegre ettikten sonra ise api kaynakları, methodları tanımlamamız gerekiyor. Bu şekilde apigateaway ile müşterimizinden istekleri alıp, gerekli lambda fonksiyonlarını çalıştırabileceğiz. Lambda fonksiyonlarımız dynamodb ile beraber ürün ekleyebilecek, güncelleyebilecek, silebilecek ve tüm ürünleri listeleyebilecek.

const productResource = productApiGateaway.root.addResource("products", {});
const productResourceWithId = productResource.addResource("{id}");

productResource.addMethod("GET", getProductListFunctionIntegration);

productResource.addMethod("POST", createProductFunctionIntegration);

productResourceWithId.addMethod("PUT", putProductFunctionIntegration);

productResourceWithId.addMethod("DELETE", deleteProductFunctionIntegration);

Sıradaki adım uygulamamızı cloudformation ile birlikte tüm kaynakları oluşturmak ve çalışabilir hale getirmek olacaktır. Bunu yapmak için önce uygulamamızın cloudformation tarafından anlaşılıp, çalıştırabilmesi için bir şablon oluşturmamız gerekiyor. Aşağıda görmekte olduğunuz kod parçası uygulamamızı çalıştırır ve uygulamamızdaki bulunan tüm kaynakları içeren bir cloudformation şablonuna çevirir. Oluşturulan şablon dosyası cdk.out klasörü içerisinde bulunur. Yine yazmış olduğumuz crud fonksiyonlarını da burada esbuild tarafından javascripte dönüşmüş hallerini bulabilirsiniz.

cdk synth

Dosya format türü yaml’dır. cdk synth komutu çalıştığında esbuild ile nodejs lambda fonksiyonlarımızı javascript koduna dönüştürmek için dockera ihtiyaç duyacaktır. Eğer docker makinenizde yoksa ya da çalışmıyorsa aşağıdaki gibi bir hata alabilirsiniz.

docker error

Cloudformation şablonunu oluşturduktan sonra bunu deploy edebiliriz. Deploy edebilmemiz için cdk deploy komutunu kullanabiliriz. Bu işlemi yapabilmemiz için bir aws hesabına ihtiyacımız olacaktır. aws hesabınıza giriş yaptıktan sonra IAM Identity Center panelinden kullanıcılar ekranına gelip bir kullanıcı oluşturacağız.

Add user butonuna tıklayalım.

Gerekli bilgileri girdikten sonra oluşturduğumuzun kullanıcının email adresine kurulum bilgilerini içeren bir email alacaktır. Bu email üzerinden şifresini oluşturabilecek ve aws paneline erişim sağlayabilecek.

Bu işlemleri yaptıktan sonra kullacımızın paneli yukarıdaki ekran alıntısındaki gibi gözükecektir. AWS kaynaklarına erişim sağlayabilmesi için AWS account’u ile kullanıcıyı eşleştirmemiz gerekiyor.

AWS Accounts

Aws accounts sekmesine geliyoruz ve root altındaki AWS tıklıyoruz.

AWS Account Detail

Assign users or groups butonuna tıkladıktan sonra açılan ekranda oluşturduğumuz kullanıcıyı ve izin kümesini seçip süreci tamamlıyoruz. Eğer sistemde bir izin kümesi yoksa onu da permission sets sekmesinden oluşturabilirsiniz. Bu işlemi yaptıktan sonra kullanıcınız verilen izinler doğrultusunda kaynaklara erişim sağlayabilecektir.

Bu işlemlerden sonra konsol üzerinden aws configure sso komutunu çağırarak kullanıcımızın profil bilgisini bilgisayarımız üzerinde oluşturmalıyız. Bizden birkaç bilgi istedikten sonra profilimiz başarılı bir şekilde oluşturmuş olduk.

aws configure sso

Son olarak profilimiz ile deployment sürecini başlatmalıyız. Bunun için aws deploy —profile [profile name] komutunu çalıştırmalıyız.

aws deploy --profile [profile name]

deployment process

deploymen result

Deployment işlemi bittikten sonra bize api endpoint url bilgisini döndürdüğünü görebiliriz. Panelden cloudformation ekranına geldiğimizde yeni bir stack oluştuğunu görebiliriz.

cloudformation

dynamodb tables ekranına geldiğimizde products isminde yeni bir dynamodb tablosu oluşturulduğunu görebiliriz.

dynamodb tables

apigateaway ekranına geldiğimizde yeni bir rest api oluşturulduğunu görebiliriz.

api gateaway

lambda ekranına geldiğimizde de lambda fonskiyonlarını görebiliriz.

lambda functions

Herşey doğru bir şekilde oluşturulduğunu gördüğümüze göre beraber doğru bir şekilde çalıştıklarını test edelim.

create product

update product

get product list

delete product

postman üzerinden yaptığımız testlerde rest api servislerimiz doğru şekilde çalıştığını görüyoruz. Eğer oluşturduğunuz stackleri yok etmek istiyorsanız cdk destroy — profile [profile name] komutunu çalıştırarak yok edebilirsiniz.

cdk destroy --profile [profile name]

Bu yazımızda aws cdk ile lambda fonksiyonları, dynamodb ve apigateaway birbirleri ile entegre şekilde çalıştırabildik. Tüm bu süreci tamamen infrastructure kod ile yaptık. Sizde istediğiniz aws kaynaklarını aws cdk ile oluşturabilirsiniz. Umarım sana dokunmuş olabilirim. Bu örnek projenin kaynak kodunu aşağıya bırakıyorum. Merak ettiğin bir şey olursa benimle iletişime geçebilirsin.

[GitHub - serhatleventyavas/ProductServerlessApplication
Contribute to serhatleventyavas/ProductServerlessApplication development by creating an account on GitHub.github.com](https://github.com/serhatleventyavas/ProductServerlessApplication "https://github.com/serhatleventyavas/ProductServerlessApplication")

Uygulamayı konuştukça bir yandan da kafamda ilgili entity’leri düşünüyordum. Kullanıcılar için bir User entity, borçlar için bir Loan entity olacaktı. İlk amacımız kullanıcıları email ve şifre ile giriş yapmalarını sağlamaktı. Bunun için kayıt ol, giriş yap, şifremi unuttum gibi temel servisleri yazdık. İkinci aşamamız ise kullanıcı bir borç (loan) oluşturabilmesiydi. Arkadaşımla bir borç oluşturulurken hangi parametreleri almalı ve kayıt gerçekleşirken iş kurallarımız ne olacak onları belirledik.

• Loan Title: minimum 3 karakter ve maksimum 120 karakter olabilir.
• Loan Description: boş olabilir ve maksimum 255 karakter olabilir.
• Loan Type : boş olamaz, bizim sistem içerisinde belirlediğimiz loan type listesinin içerisinde olmalı.
• Total Amount: boş olamaz ve negatif bir değer olamaz.
• Total Currency: boş olamaz ve bizim sistem içerisinde belirlediğimiz currency type listesinin içerisinde olmalı.
• Bir kullanıcı ücretsiz pakette maksimum 5 tane borç kaydı açabilir.

Bu kurallara göre bir loan entity yazmam gerekiyordu. Proje küçük bir proje olmasına rağmen ben bu projede birim testlerini yazmak istedim. Birim testler yani unit test, kodumuzu test etmek için kullandığımız bir yöntemdir. Unit testler kodumuzdaki en küçük birimi test eder olarak öğreniriz ve bu şekilde uygulamaya çalışırız. Birim testler aslında kodumuzdaki bir davranışı (use case) bağımlılıklar olmadan test etmelidir. Projemizdeki her en küçük birim için testler yazarsak, kodumuzun hareket kabiliyetini kısıtlarız, kodu kendi ellerimiz ile kitleriz. Bir yerden sonra refactor ederken bile karşımızda direnç gösteren testler ile karşı karşıya kalırız. Bizim amacımız iş kurallarımızın doğru şekilde çalıştığına emin olmak ve bağımlılıklardan sıyrılmış birim testler yazmak olmalıdır.

Bu uygulamada yeni borç oluşturmak bir davranıştır ve bunu bağımlılıklar olmadan birim testler ile test etmeliyiz. Borcu kapamak ya da bir taksidini ödemek de uygulamadaki diğer davranışlardır. Hepsi uygulamadaki kullanıcı ile etkileşime geçen davranışlardır. Bizim amacımız bu davranışları birim testler ile bağımlılıklar olmadan test edebilmektir.

Daha fazla uzatmadan kolları sıvayıp servislerimizi geliştirmeye başlayalım. Projemizin solution oluşturmak için terminalden aşağıdaki kodu yazdım.

dotnet new sln -o Wallet

Bu kod Wallet klasörü içerisine boş bir solution açar. Wallet klasörü içerisine girelim. Şimdi projemizin domain katmanını oluşturmak ve solution ile bağlamak için terminale aşağıdaki kodu yazılım.

dotnet new classlib -o Wallet.Domain
dotnet sln add .\Wallet.Domain\

Projemizin application katmanını oluşturmak ve solution ile bağlamak için için aşağıdaki kodu yazalım.

dotnet new classlib -o Wallet.Application
dotnet sln add .\Wallet.Application\

Application katmanındaki servislerimizi test etmek için application test katmanını oluşturalım ve solution ile bağlayalım.

dotnet new xunit -o Wallet.Application.Tests
dotnet sln add .\Wallet.Application.Tests\

Son olarak application katmanının domain katmanına erişebilmesi ve application test katmanının application katmanına erişebilmesi için referansları ekleyelim.

dotnet add .\Wallet.Application.Tests\ reference .\Wallet.Application\
dotnet add .\Wallet.Application\ reference .\Wallet.Domain\

Projemizin gerekli kurulumları yaptıktan sonra ilk servisimiz olan borç oluşturma servisini yazabiliriz.

Servisimizi yazmadan önce servisimizin bir borç oluşturabilmek için ihtiyaç duyduğu parametreleri saklayan bir veri yapısına ihtiyacımız var. Bunun için aşağıdaki CreateLoanInput recordunu oluşturdum.

using Wallet.Domain.Users;

namespace Wallet.Application.Loans.CreateLoan;

public sealed record CreateLoanInput( string Title,
string Description,
string LoadTypeCode,
decimal TotalAmount,
string CurrencyCode,
User User);

Daha sonra ICreateLoanService interfacesini oluşturdum.

using Wallet.Domain.Loans;

namespace Wallet.Application.Loans.CreateLoan;

public interface ICreateLoanService
{
Task Handle(CreateLoanInput input, CancellationToken cancellationToken);
}

Neden bir interface ihtiyacımız var sorusu akıllarda oluşmuş olabilir. Projelerde amacımız bağımlılıkları mümkün oldukça soyutlamaktır. Somut yapılar projenin parçalarını birbirleri ile sıkı sıkıya bağlar ve birbirinden ayrılmasını zorlaştırır. Soyut yapılar ile bu bağımlılıkları gevşek tutmaya çalışırız, böylelikle projenin değişime olan direncini azaltmış oluruz. Bir örnek vermek gerekirse, herkes sıklıkla e-ticaret platformlarından ya da bankalardan ürünler, kampanyalar hakkında sms ve email yoluyla bilgilendirme alıyordur. Zaman zaman bu platformlardan email, sms ile bilgilendirme ayarlarınızı değiştiriyor olabilirsiniz. Bu durumda sistem sizin talebinize göre sizi bilgilendirme yöntemlerini değiştiriyor. Peki bu değişimi nasıl yönetiyor olabilirler? Ben olsam şöyle bir çözüm üretiyor olabilirdim;

public sealed record NotifyUserInput(User User, string Title, string Description);

public interface INotifyUserService {
Task Notify(NotifyUserInput input);
}

public sealed class NotifySmsUserService : INotifyUserService
{
public Task Notify(NotifyUserInput input)
{
//notify with sms api
}
}

public sealed class NotifyEmailUserService : INotifyUserService
{
public Task Notify(NotifyUserInput input)
{
//notify with email api
}
}

public sealed class NotifyNothingUserService: INotifyUserService
{
public Task Notify(NotifyUserInput input)
{
//do not notify user
}
}

Burada bir INotifyUserService interface oluşturdum. Bu interface 3 farklı sınıfa uyguladım. Kullanıcı duruma göre sms ile bilgilendirilmek isterse NotifySmsUserService, email ile bilgilendirilmek isterse NotifyEmailUserService, herhangi bir şekilde bilgilendirmek istemiyorsa NotifyNothingUserService servisini çağırabilirim.

public sealed class SendNewProductToCustomerService
{
private readonly INotifyUserService _notifyUserService;
public User User { get; private set; }
public Product Product { get; private set; }

public SendNewProductToCustomerService( User user,
Product product,
INotifyUserService notifyUserService )
{
User = user;
Product = product;
_notifyUserService = notifyUserService;
}

public Task Handle()
{
// handle it
}
}

// notify with email
var sendNewProductToCustomerService = new SendNewProductToCustomerService(
user: User,
product: Product,
notifyUserService: new NotifyEmailUserService()
);

// notify with sms
var sendNewProductToCustomerService = new SendNewProductToCustomerService(
user: User,
product: Product,
notifyUserService: new NotifySmsUserService()
);

// do not notify
var sendNewProductToCustomerService = new SendNewProductToCustomerService(
user: User,
product: Product,
notifyUserService: new NotifyNothingUserService()
);

Yukarıdaki örnekte gördüğünüz gibi SendNewProductToCustomerService servisi INotifyUserService interfacesine bağlı olduğu için INotifyUserService interfacesini uygulayan bir çok farklı sınıf ile birlikte çalışabilir hale geldi. Neyse konumuza geri dönelim. En son ICreateLoanService interfacemizi oluşturmuştuk. Sıra geldi CreateLoanService sınıfını oluşturalım ve ICreateLoanService interfacesini uygulayalım.

using Wallet.Domain.Loans;

namespace Wallet.Application.Loans.CreateLoan;

public sealed class CreateLoanService : ICreateLoanService
{
public Task Handle(CreateLoanInput input)
{
throw new NotImplementedException();
}
}

Şimdi iş kurallarımızı kontrol eden kodumuzu yazalım.

using Wallet.Domain.Abstractions;
using Wallet.Domain.Loans;

namespace Wallet.Application.Loans.CreateLoan;

public sealed class CreateLoanService : ICreateLoanService
{
private readonly IUnitOfWork _unitOfWork;
private readonly ILoanRepository _loanRepository;

public CreateLoanService(IUnitOfWork unitOfWork, ILoanRepository loanRepository)
{
_unitOfWork = unitOfWork;
_loanRepository = loanRepository;
}

public async Task Handle(CreateLoanInput input, CancellationToken cancellationToken)
{
var user = input.User;
var title = input.Title;
var description = input.Description;
var loadTypeCode = input.LoadTypeCode;
var currencyCode = input.CurrencyCode;
var totalAmount = input.TotalAmount;

var currency = Currency.GetByCode(currencyCode);
var amount = Money.Create(totalAmount, currency);
var loanType = LoanType.GetByCode(loadTypeCode);

if (!user.IsPremium)
{
var totalLoanCount = await _loanRepository.GetTotalLoanCountByUserId(user.Id);
if (totalLoanCount >= 5)
{
throw new MaxLoanCountException();
}
}

var loan = Loan.Create(user, title, description, loanType, amount);

await _loanRepository.Add(loan);
await _unitOfWork.SaveChangesAsync(cancellationToken);

return loan;
}
}

Burada CreateLoanService oluşturulurken 2 adet parametreye ihtiyaç duyuyor. Burada da gördüğünüz gibi CreateLoanService interfacelere bağlı. IUnitOfWork ve ILoanRepository implement eden sınıfların nesneleri bir kullanıcının toplam kayıtlı loan sayısını döndürmek ve yeni bir loan kaydını veritabanına kaydetmek için kullanacağız. Borç türü, borç tutarı ve borcun para birimini yönetebilmek için LoanType, Currency ve Money value objelerini oluşturdum. Ayrıca kullanıcıyı temsil edecek User entity sınıfını oluşturdum.

using Wallet.Domain.Abstractions;

namespace Wallet.Domain.Users;

public sealed class User : Entity
{
public string FirstName { get; private set; }
public string LastName { get; private set; }
public string Email { get; private set; }
public string Password { get; private set; }
public bool IsPremium { get; private set; }

private User(Guid id, string firstName, string lastName, string email, string password, bool isPremium) : base(id, DateTime.UtcNow)
{
FirstName = firstName;
LastName = lastName;
Email = email;
Password = password;
IsPremium = isPremium;
}

public static User Create(string firstName, string lastName, string email, string password, bool isPremium)
{
var user = new User(Guid.NewGuid(), firstName, lastName, email, password, isPremium);

return user;
}
}

namespace Wallet.Domain.Abstractions;

public interface IUnitOfWork
{
Task SaveChangesAsync(CancellationToken cancellationToken = default);
}

namespace Wallet.Domain.Loans;

public interface ILoanRepository
{
public Task GetTotalLoanCountByUserId(Guid userId);
public Task Add(Loan loan);
}

namespace Wallet.Domain.Loans;

public sealed record Currency
{
public static readonly Currency Try = new("TRY");
public static readonly Currency Eur = new("EUR");
public static readonly Currency Usd = new("USD");
public static readonly Currency Gbp = new("GBP");
public static readonly IReadOnlyCollection All = new[] { Try, Eur, Usd, Gbp };

public string Code { get; init; }

private Currency(string code) => Code = code;

public static Currency GetByCode(string code)
{
return All.FirstOrDefault(p => p.Code == code) ?? throw new InvalidCurrencyException();
}
}

namespace Wallet.Domain.Loans;

public sealed record LoanType
{
public static readonly LoanType PersonalFinanceCredit = new("PersonalFinanceCredit");
public static readonly LoanType Mortgage= new ("Mortgage");
public static readonly LoanType CreditCardInstallment = new("CreditCardInstallment");
public static readonly IReadOnlyCollection All = new[] { PersonalFinanceCredit, Mortgage, CreditCardInstallment };

public string Code { get; init; }

private LoanType(string code)
{
Code = code;
}

public static LoanType GetByCode(string code)
{
return All.FirstOrDefault(p => p.Code == code) ?? throw new InvalidLoanTypeException();
}
}

namespace Wallet.Domain.Loans;

public sealed record Money
{
public decimal Amount { get; init; }
public Currency Currency { get; init; }

private Money(decimal amount, Currency currency)
{
Amount = amount;
Currency = currency;
}

public static Money Create(decimal amount, Currency currency)
{
if (amount < 0)
{
throw new AmountMustBePositiveException();
}

return new Money(amount, currency);
}

private static void Validate(Money first, Money second)
{
if (first.Currency != second.Currency)
{
throw new CurrenciesMustBeSameException();
}

if (first.Amount < 0)
{
throw new AmountMustBePositiveException();
}

if (second.Amount < 0)
{
throw new AmountMustBePositiveException();
}

if (first.Amount >= int.MaxValue)
{
throw new InvalidAmountException();
}

if (second.Amount >= int.MaxValue)
{
throw new InvalidAmountException();
}
}

public static Money operator +(Money first, Money second)
{
Validate(first, second);

var tempSum = first.Amount + second.Amount;

if (tempSum >= int.MaxValue)
{
throw new InvalidAmountException();
}

var tempDiff = tempSum - first.Amount;

if (tempDiff != second.Amount)
{
throw new InvalidAmountException();
}

return new Money(first.Amount + second.Amount, first.Currency);
}

public static Money operator -(Money first, Money second)
{
Validate(first, second);

var diff = first.Amount - second.Amount;

if (diff < 0)
{
throw new AmountMustBePositiveException();
}

return new Money(diff, first.Currency);
}
}

Aşağıda da Loan entity sınıfını görebilirsin. Yeni bir borç nesnesi oluşturmak için constructor kullanmıyorum. Bunun yerine Create methodunu çağırıyorum.

using Wallet.Domain.Abstractions;
using Wallet.Domain.Users;

namespace Wallet.Domain.Loans;

public sealed class Loan: Entity
{
public Guid UserId { get; private set; }
public string Title { get; private set; }
public string Description { get; private set; }
public LoanType LoanType { get; private set; }
public Money TotalAmount { get; private set; }

private Loan(Guid id, Guid userId, string title, string description, LoanType loanType, Money totalAmount) : base(id, DateTime.UtcNow)
{
UserId = userId;
SetTitle(title);
SetDescription(description);
LoanType = loanType;
TotalAmount = totalAmount;
}

public static Loan Create(User user,
string title, string description, LoanType loanType, Money totalAmount)
{
var userId = user.Id;

var loan = new Loan(Guid.NewGuid(), userId, title, description, loanType, totalAmount);
return loan;
}

internal void SetTitle(string title) {
var trimTitle = title.Trim();
if (string.IsNullOrEmpty(trimTitle))
{
throw new RequiredLoanTitleException();
}

if (trimTitle.Length < 3)
{
throw new MinLengthLoanTitleException();
}

if (trimTitle.Length > 120)
{
throw new MaxLengthLoanTitleException();
}
Title = title;
}

internal void SetDescription(string description) {
var trimDescription = description.Trim();
if (trimDescription.Length > 255)
{
throw new MaxLengthLoanDescriptionException();
}
Description = description;
}
}

Bir loan nesnesi oluşturmak için gerekli olan tüm geliştirmeyi yaptık. Şimdi testlerini yazalım.

using Wallet.Application.Loans.CreateLoan;
using Wallet.Domain.Loans;
using Wallet.Domain.Users;

namespace Wallet.Application.Tests.Loans.CreateLoan;

public class CreateLoanServiceTests
{
[Fact]
public async Task Given_Empty_Title_Throw_RequiredLoanTitleException()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", true);
var input \= new CreateLoanInput(
User: user,
Title: "",
Description: "",
LoadTypeCode: LoanType.Mortgage.Code,
TotalAmount: 10_000,
CurrencyCode: Currency.Try.Code
);
var service \= new CreateLoanService(new FakeUnitOfWork(), new FakeLoanRepository());

await Assert.ThrowsAsync(() => service.Handle(input, new CancellationToken()));

}

[Fact]
public async Task Given_2_Chars_Title_Throw_MinLengthLoanTitleException()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", true);
var input \= new CreateLoanInput(
User: user,
Title: new string('*',2),
Description: "",
LoadTypeCode: LoanType.Mortgage.Code,
TotalAmount: 10_000,
CurrencyCode: Currency.Try.Code
);
var service \= new CreateLoanService(new FakeUnitOfWork(), new FakeLoanRepository());

await Assert.ThrowsAsync(() => service.Handle(input, new CancellationToken()));

}

[Fact]
public async Task Given_121_Chars_Title_Throw_MaxLengthLoanTitleException()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", true);
var input \= new CreateLoanInput(
User: user,
Title: new string('*', 121),
Description: "",
LoadTypeCode: LoanType.Mortgage.Code,
TotalAmount: 10_000,
CurrencyCode: Currency.Try.Code
);
var service \= new CreateLoanService(new FakeUnitOfWork(), new FakeLoanRepository());

await Assert.ThrowsAsync(() => service.Handle(input, new CancellationToken()));

}

[Fact]
public async Task Given_256_Chars_Description_Throw_MaxLengthLoanDescriptionException()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", true);
var input \= new CreateLoanInput(
User: user,
Title: "Title",
Description: new string('*', 256),
LoadTypeCode: LoanType.Mortgage.Code,
TotalAmount: 10_000,
CurrencyCode: Currency.Try.Code
);
var service \= new CreateLoanService(new FakeUnitOfWork(), new FakeLoanRepository());

await Assert.ThrowsAsync(() => service.Handle(input, new CancellationToken()));
}

[Fact]
public async Task Given_Empty_Loan_Type_Code_Throw_InvalidLoanTypeException()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", true);
var input \= new CreateLoanInput(
User: user,
Title: "Title",
Description: "Description",
LoadTypeCode: "",
TotalAmount: 10_000,
CurrencyCode: Currency.Try.Code
);
var service \= new CreateLoanService(new FakeUnitOfWork(), new FakeLoanRepository());

await Assert.ThrowsAsync(() => service.Handle(input, new CancellationToken()));
}

[Fact]
public async Task Given_Not_Exists_Code_Loan_Type_Code_Throw_InvalidLoanTypeException()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", true);
var input \= new CreateLoanInput(
User: user,
Title: "Title",
Description: "Description",
LoadTypeCode: "invalidCode",
TotalAmount: 10_000,
CurrencyCode: Currency.Try.Code
);
var service \= new CreateLoanService(new FakeUnitOfWork(), new FakeLoanRepository());

await Assert.ThrowsAsync(() => service.Handle(input, new CancellationToken()));
}

[Fact]
public async Task Given_Empty_Currency_Code_Throw_InvalidCurrencyException()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", true);
var input \= new CreateLoanInput(
User: user,
Title: "Title",
Description: "Description",
LoadTypeCode: LoanType.Mortgage.Code,
TotalAmount: 10_000,
CurrencyCode: ""
);
var service \= new CreateLoanService(new FakeUnitOfWork(), new FakeLoanRepository());

await Assert.ThrowsAsync(() => service.Handle(input, new CancellationToken()));
}

[Fact]
public async Task Given_Not_Exists_Currency_Code_Throw_InvalidCurrencyException()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", true);
var input \= new CreateLoanInput(
User: user,
Title: "Title",
Description: "Description",
LoadTypeCode: LoanType.Mortgage.Code,
TotalAmount: 10_000,
CurrencyCode: "invalid_code"
);
var service \= new CreateLoanService(new FakeUnitOfWork(), new FakeLoanRepository());

await Assert.ThrowsAsync(() => service.Handle(input, new CancellationToken()));
}

[Fact]
public async Task Given_Negative_Amount_Throw_AmountMustBePositiveException()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", true);
var input \= new CreateLoanInput(
User: user,
Title: "Title",
Description: "Description",
LoadTypeCode: LoanType.Mortgage.Code,
TotalAmount: -10_000,
CurrencyCode: Currency.Try.Code
);
var service \= new CreateLoanService(new FakeUnitOfWork(), new FakeLoanRepository());

await Assert.ThrowsAsync(() => service.Handle(input, new CancellationToken()));
}

[Fact]
public async Task Given_Freemium_User_With_5_Loans_Total_Throw_MaxLoanCountException()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", false);
var input \= new CreateLoanInput(
User: user,
Title: "Title",
Description: "Description",
LoadTypeCode: LoanType.Mortgage.Code,
TotalAmount: 10_000,
CurrencyCode: Currency.Try.Code
);
var service \= new CreateLoanService(new FakeUnitOfWork(), new FakeLoanRepository(5));

await Assert.ThrowsAsync(() => service.Handle(input, new CancellationToken()));
}

[Fact]
public async Task Given_Correct_Input_And_Freemium_User_Create_Loan_Successfully()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", false);
var input \= new CreateLoanInput(
User: user,
Title: "Title",
Description: "Description",
LoadTypeCode: LoanType.Mortgage.Code,
TotalAmount: 10_000,
CurrencyCode: Currency.Try.Code
);

var fakeUnitOfWork \= new FakeUnitOfWork();
var fakeLoanRepository \= new FakeLoanRepository(4);
var service \= new CreateLoanService(fakeUnitOfWork, fakeLoanRepository);

var loan \= await service.Handle(input, new CancellationToken());

Assert.Equal(1, fakeLoanRepository.TotalCalledGetTotalLoanCountByUserId);
Assert.Equal(1, fakeUnitOfWork.Count);
Assert.Contains(loan, fakeLoanRepository.AddedLoanList);
Assert.NotNull(loan);
Assert.Equal(loan.UserId, user.Id);
Assert.Equal(loan.LoanType.Code, input.LoadTypeCode);
Assert.Equal(loan.TotalAmount.Currency.Code, input.CurrencyCode);
Assert.Equal(loan.TotalAmount.Amount, input.TotalAmount);
Assert.Equal(loan.Title, input.Title);
Assert.Equal(loan.Description, input.Description);
}

[Fact]
public async Task Given_Correct_Input_And_Premium_User_Create_Loan_Successfully()
{
var user \= User.Create("Serhat", "Yavaş", "serhatleventyavas@gmail.com", "test123", true);
var input \= new CreateLoanInput(
User: user,
Title: "Title",
Description: "Description",
LoadTypeCode: LoanType.Mortgage.Code,
TotalAmount: 10_000,
CurrencyCode: Currency.Try.Code
);

var fakeUnitOfWork \= new FakeUnitOfWork();
var fakeLoanRepository \= new FakeLoanRepository(5);
var service \= new CreateLoanService(fakeUnitOfWork, fakeLoanRepository);

var loan \= await service.Handle(input, new CancellationToken());

Assert.Equal(0, fakeLoanRepository.TotalCalledGetTotalLoanCountByUserId);
Assert.Equal(1, fakeUnitOfWork.Count);
Assert.Contains(loan, fakeLoanRepository.AddedLoanList);
Assert.NotNull(loan);
Assert.Equal(loan.UserId, user.Id);
Assert.Equal(loan.LoanType.Code, input.LoadTypeCode);
Assert.Equal(loan.TotalAmount.Currency.Code, input.CurrencyCode);
Assert.Equal(loan.TotalAmount.Amount, input.TotalAmount);
Assert.Equal(loan.Title, input.Title);
Assert.Equal(loan.Description, input.Description);
}
}

Yukarıdaki testlerimiz bir borç oluşturmak için tanımladığımız tüm iş kurallarını test ediyor. Ayrıca testlerimizde gördüğünüz gibi iş kurallarına uymayan durumlarda özel hata fırlatıyoruz. Bu hatalarıda aşağıda bulabilirsin.

namespace Wallet.Domain.Loans;

public sealed class RequiredLoanTitleException: Exception;
public sealed class MinLengthLoanTitleException : Exception;
public sealed class MaxLengthLoanTitleException : Exception;
public sealed class MaxLengthLoanDescriptionException : Exception;
public sealed class MaxLoanCountException: Exception;
public sealed class InvalidLoanTypeException: Exception;
public sealed class InvalidCurrencyException: Exception;
public sealed class AmountMustBePositiveException: Exception;
public sealed class CurrenciesMustBeSameException: Exception;
public sealed class InvalidAmountException: Exception;

Test Results

Yukarıdaki ekran alıntısında yazdığımız testlerin hepsinin doğru şekilde çalıştığını görebiliyoruz.

Tests Coverage

Yukarıdaki ekran alıntısında ise Unit Tests Coverage sonucunu görebiliriz. Unit Test Coverage, testler kodumuzun ne kadar ile etkileşime geçti onu yüzdesel olarak bize sunar. CreateLoanService ve Loan sınıflarına %100 olarak dokunmuşuz, her satırı ile etkileşime geçmişiz. Yani elimizdeki iş kurallarının her maddesini test etmişiz. Buradaki amacımız %100 oranına ulaşmak değil. Amacımız bir borç oluşturulurken elimizdeki iş kuralları doğru şekilde çalıştığından emin olmak. Bu şekilde oluşabilecek hataların önüne geçebiliriz. Tabi farkedemediğimiz iş kuralları yüzünden hatalar oluşabilir, ancak elimizdeki iş kurallarının doğru çalıştığına eminiz. Bu sayede kodun hata ve bakım maliyetlerini azaltabiliriz.

Uzun bir yazı oldu. Bu yazımızda xUnit ile nasıl test yazabiliriz, unit test nedir, soyutlama ve bağımlılıklardan küçük küçük örnekler ile bahsetmeye çalıştım. Umarım sana dokunmuş olabilirim. Bu örnek projenin kaynak kodunu aşağıya bırakıyorum. Merak ettiğin bir şey olursa benimle iletişime geçebilirsin.

[GitHub - serhatleventyavas/Wallet
Contribute to serhatleventyavas/Wallet development by creating an account on GitHub.github.com](https://github.com/serhatleventyavas/Wallet "https://github.com/serhatleventyavas/Wallet")

Örneğin yukarıda Rider IDE’ sini kullanarak yazmış olduğum basit bir c# kodu örneği bulunuyor. Örnekte int tipinde ve age isminde bir değişken oluşturdum ve 25 değerini bu değişkene atadım. Daha sonra bir alt satırda aynı değişkene Serhat ataması yaptım. Bu atama sonrasında IDE burada Serhat değerinin altını çizerek hata döndürdü ve bu atamanın yapılamayacağı hakkında bilgi verdi.

Rider build failed

Ayrıca Rider üzerinden build işlemi yapmak istediğim zaman derleme aşamasında hata oluştu ve yine aynı hatayı bana bildirdi.

Terminal build failed

Aynı hatayı terminal üzerinden dotnet build komutunu çalıştırdığımızda da görebiliriz.

C# dışında static typing destekleyen bazı diller; C, C++, Java, Rust, Go, Scala, Kotlin, Swift

Kısaca özetleyecek olursak; static typing dillerde derleme zamanında tip kontrolü yapılır. Böylelikle çalışma zamanında oluşabilecek hataların önüne geçilir.