Bulutta Yerel nedir?

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Azure için Buluta Özel .NET Uygulamaları Tasarlama adlı e-Kitap'tan bir alıntıdır.

PDF'i indirin

Yaptığınız işlemi durdurun ve iş arkadaşlarınızdan "Buluta Özel" terimini tanımlamasını isteyin. Birkaç farklı yanıt alma ihtimaliniz yüksek.

Basit bir tanımla başlayalım:

Bulutta yerel mimari ve teknolojiler, bulutta yerleşik olarak bulunan ve bulut bilişim modelinden tam olarak yararlanan iş yüklerini tasarlama, oluşturma ve çalıştırmaya yönelik bir yaklaşımdır.

Cloud Native Computing Foundation resmi tanımı sağlar:

Buluta özel teknolojiler, kuruluşların genel, özel ve hibrit bulutlar gibi modern, dinamik ortamlarda ölçeklenebilir uygulamalar oluşturmasını ve çalıştırmasını sağlar. Kapsayıcılar, hizmet ağları, mikro hizmetler, sabit altyapı ve bildirim temelli API'ler bu yaklaşımı örneklemektedir.

Bu teknikler esnek, yönetilebilir ve gözlemlenebilir gevşek bir şekilde bağlanmış sistemler sağlar. Sağlam otomasyon ile birlikte, mühendislerin minimum emekle sık sık ve tahmin edilebilir şekilde yüksek etkili değişiklikler yapmasına olanak sağlar.

Bulutta yerel olarak hız ve çeviklik söz konusudur. İş sistemleri, iş yeteneklerinin etkinleştirilmesinden iş hızını ve büyümesini hızlandıran stratejik dönüşüm silahlarına kadar gelişmektedir. Pazara hemen yeni fikirler almak zorunlu.

Aynı zamanda, iş sistemleri de kullanıcıların daha fazlasını istemesiyle giderek daha karmaşık hale gelmiştir. Hızlı yanıt verme, yenilikçi özellikler ve sıfır kapalı kalma süresi beklerler. Performans sorunları, yinelenen hatalar ve hızlı hareket edilememesi artık kabul edilemez. Kullanıcılarınız rakibinizi ziyaret edecektir. Buluta özel sistemler hızlı değişimi, büyük ölçeği ve dayanıklılığı benimseyecek şekilde tasarlanmıştır.

Bulutta yerel teknikler uygulayan bazı şirketler aşağıdadır. Elde ettikleri hızı, çevikliği ve ölçeklenebilirliği düşünün.

Şirket	Deneyim
Netflix	Üretimde 600'den fazla hizmeti vardır. Günde 100 kez dağıtır.
Uber	Üretimde 1.000'den fazla hizmet vardır. Her hafta birkaç bin kez dağıtır.
WeChat	Üretimde 3.000'den fazla hizmet vardır. Günde 1.000 kez dağıtır.

Gördüğünüz gibi Netflix, Uber ve WeChat birçok bağımsız hizmet içeren buluta özel sistemleri kullanıma sunar. Bu mimari stili, pazar koşullarına hızlı bir şekilde yanıt vermelerini sağlar. Canlı, karmaşık bir uygulamanın küçük alanlarını tam yeniden dağıtım olmadan anında güncelleştirir. Gerektiğinde hizmetleri ayrı ayrı ölçeklendirir.

Yerel bulutun yapı taşlarını

Bulut yerelinin hızı ve çevikliği birçok faktörden türetilir. En önemlisi bulut altyapısıdır. Ancak daha fazlası da var: Şekil 1-3'te gösterilen beş temel yapı daha buluta özel sistemler için temel yapı taşı sağlar.

Şekil 1-3. Bulutta yerel temel sütunlar

Her bir sütunun önemini daha iyi anlamak için biraz zaman ayıralım.

Bulut

Buluta özel sistemler, bulut hizmeti modelinden tam olarak yararlanan sistemlerdir.

Dinamik, sanallaştırılmış bir bulut ortamında başarılı olmak için tasarlanan bu sistemler, Hizmet Olarak Platform (PaaS) işlem altyapısını ve yönetilen hizmetleri kapsamlı bir şekilde kullanır. Temel altyapıyı, otomasyon aracılığıyla dakikalar içinde sağlanan ve isteğe bağlı olarak yeniden boyutlandırılan, ölçeklendirilen veya yok edilen atılabilir altyapı olarak ele alır.

Evcil hayvanlarla malları nasıl tedavi ettiğimiz arasındaki farkı düşünün. Geleneksel bir veri merkezinde sunucular evcil hayvan olarak kabul edilir: anlamlı bir ad verilen ve önem verilen fiziksel bir makine. Aynı makineye daha fazla kaynak ekleyerek (ölçeği artırarak) ölçeklendirin. Sunucu hastalanırsa, sağlığına geri dönersiniz. Sunucu kullanılamaz duruma gelirse, herkes bunu fark eder.

Emtia hizmet modeli farklıdır. Her örneği bir sanal makine veya kapsayıcı olarak hazırlarsınız. Bunlar aynıdır ve Service-01, Service-02 gibi bir sistem tanımlayıcısı atanır. Daha fazla örnek oluşturarak ölçeklendirilirsiniz (ölçeği genişletebilirsiniz). Bir örneğin kullanılamaz duruma geldiğini kimse fark etmez.

Emtia modeli sabit altyapıyı benimser. Sunucular onarılamaz veya değiştirilmez. Biri başarısız olursa veya güncelleştirme gerektiriyorsa, yok edilir ve yeni bir tane sağlanır; hepsi otomasyon aracılığıyla yapılır.

Bulutta yerel sistemler, ticari hizmet modelini benimser. Altyapı ölçeklendirildikçe veya ölçeği genişletildikçe, üzerinde çalıştıkları makineleri dikkate almadan çalışmaya devam ederler.

Azure bulut platformu otomatik ölçeklendirme, kendi kendini düzeltme ve izleme özellikleriyle bu tür yüksek düzeyde esnek altyapıyı destekler.

Modern tasarım

Bulutta yerel bir uygulamayı nasıl tasarlarsınız? Mimariniz nasıl görünür? Hangi ilkelere, desenlere ve en iyi yöntemlere uyarsınız? Hangi altyapı ve operasyonel endişeler önemli olabilir?

Twelve-Factor Uygulaması

Bulut tabanlı uygulamalar oluşturmak için yaygın olarak kabul edilen bir metodoloji, Twelve-Factor Uygulaması'dır. Geliştiricilerin modern bulut ortamları için iyileştirilmiş uygulamalar oluşturmak için izlediği bir dizi ilke ve uygulamayı açıklar. Ortamlar arasında taşınabilirliğe ve bildirim temelli otomasyona özellikle dikkat edilir.

Her web tabanlı uygulama için geçerli olsa da, birçok uygulamacı Twelve-Factor'i bulutta yerel uygulamalar oluşturmak için sağlam bir temel olarak değerlendirir. Bu ilkeleri temel alarak oluşturulan sistemler hızla dağıtıp ölçeklendirebilir ve pazar değişikliklerine hızlı tepki vermek için özellikler ekleyebilir.

Aşağıdaki tabloda Twelve-Factor metodolojisi vurgulanır:

Faktör	Açıklama
1 - Kod Tabanı	Her mikro hizmet için kendi deposunda depolanan tek bir kod tabanı. Sürüm denetimiyle izlenir, birden çok ortam (QA, Hazırlama, Üretim) dağıtabilir.
2 - Bağımlılıklar	Her mikro hizmet, tüm sistemi etkilemeden değişiklikleri kucaklayarak kendi bağımlılıklarını yalıtıp paketler.
3 - Yapılandırmalar	Yapılandırma bilgileri mikro hizmetten taşınır ve kodun dışında bir yapılandırma yönetim aracı aracılığıyla dışlanır. Aynı dağıtım, doğru yapılandırmanın uygulandığı ortamlarda yayılabilir.
4 - Yedekleme Hizmetleri	Yardımcı kaynaklar (veri depoları, önbellekler, ileti aracıları) adreslenebilir bir URL aracılığıyla gösterilmelidir. Bunun yapılması, kaynağı uygulamadan ayrıştırarak değiştirilebilir olmasını sağlar.
5 - Derleme, Sürüm, Çalıştırma	Her sürümün derleme, yayın ve çalıştırma aşamalarında katı bir ayrım yapması gerekir. Her birinin benzersiz bir kimlikle etiketlenmesi ve geri alma özelliğini desteklemesi gerekir. Modern CI/CD sistemleri bu ilkenin yerine getirilmesine yardımcı olur.
6 - İşlemler	Her mikro hizmet, çalışan diğer hizmetlerden yalıtılmış olarak kendi işleminde yürütülmelidir. Gerekli durumu dağıtılmış önbellek veya veri deposu gibi bir yedekleme hizmetine dışlayın.
7 - Bağlantı Noktası Bağlama	Her mikro hizmet kendi bağlantı noktasında kullanıma sunulan arabirimleri ve işlevleriyle kendi içinde olmalıdır. Bunu yapmak, diğer mikro hizmetlerden yalıtım sağlar.
8 - Eşzamanlılık	Kapasitenin artırılması gerektiğinde, kullanılabilir en güçlü makinede tek bir büyük örneğin ölçeğini artırmanın aksine, hizmetlerin ölçeğini birden çok özdeş işlemde (kopyalar) yatay olarak genişletin. Uygulamayı eşzamanlı olacak şekilde geliştirerek bulut ortamlarında ölçeğin sorunsuz bir şekilde genişletilmesi.
9 - Depoability	Hizmet örnekleri atılabilir olmalıdır. Ölçeklenebilirlik fırsatlarını ve düzgün kapatmaları artırarak sistemi doğru durumda bırakmak için hızlı başlatmayı tercih edin. Docker kapsayıcıları ve bir düzenleyici bu gereksinimi doğal olarak karşılar.
10 - Geliştirme/Üretim Eşlik	Yüksek maliyetli kısayollardan kaçınarak, uygulama yaşam döngüsü genelindeki ortamları mümkün olduğunca benzer tutun. Burada kapsayıcıların benimsenmesi, aynı yürütme ortamının tanıtılmasıyla büyük katkıda bulunabilir.
11 - Günlüğe kaydetme	Mikro hizmetler tarafından oluşturulan günlükleri olay akışları olarak değerlendirin. Bunları bir olay toplayıcısıyla işleyin. Günlük verilerini Azure İzleyici veya Splunk gibi veri madenciliği/günlük yönetimi araçlarına ve sonunda uzun süreli arşivleme işlemlerine yayma.
12 - Yönetici İşlemleri	Veri temizleme veya bilgi işlem analizi gibi yönetim/yönetim görevlerini tek seferlik işlemler olarak çalıştırın. Bu görevleri üretim ortamından ancak uygulamadan ayrı olarak çağırmak için bağımsız araçlar kullanın.

Oniki Faktörlü Uygulamanın Ötesinde adlı kitapta yazar Kevin Hoffman, özgün 12 faktörün (2011'de yazılmış) her birini ayrıntılarıyla anlatıyor. Ayrıca günümüzün modern bulut uygulaması tasarımını yansıtan üç ek faktörden de bahsedmektedir.

Yeni Faktör	Açıklama
13 - Api First	Her şeyi bir hizmet haline getirin. Kodunuzun bir ön uç istemcisi, ağ geçidi veya başka bir hizmet tarafından kullanılacağını varsayalım.
14 - Telemetri	bir iş istasyonunda, uygulamanızın ve davranışının derin görünürlüğüne sahipsiniz. Bulutta bunu yapamazsınız. Tasarımınızın izleme, etki alanına özgü ve sistem durumu/sistem verileri koleksiyonunu içerdiğinden emin olun.
15 - Kimlik Doğrulaması/ Yetkilendirme	Başlangıçtan kimlik uygulayın. Genel bulutlarda kullanılabilen RBAC (rol tabanlı erişim denetimi) özelliklerini göz önünde bulundurun.

Bu bölümdeki ve kitaptaki 12'den fazla faktörden birçoğuna başvuracağız.

Azure Mimarisi İyi Tasarlanmış Çerçeve

Bulut tabanlı iş yüklerinin tasarlanması ve dağıtılması, özellikle de buluta özel mimariyi uygularken zor olabilir. Microsoft, sizin ve ekibinizin sağlam bulut çözümleri sunmanıza yardımcı olmak için endüstri standardı en iyi yöntemler sunar.

Microsoft İyi Tasarlanmış Çerçeve, bulutta yerel bir iş yükünün kalitesini artırmak için kullanılabilecek bir dizi kılavuz ilke sağlar. Çerçeve, mimari mükemmelliğinin beş yapı taşından oluşur:

Tenets	Açıklama
Maliyet yönetimi	Artımlı değeri erken oluşturmaya odaklanın. Yoğun sermaye gerektiren çözümlerden kaçınarak pazara çıkma süresini hızlandırmak için Build-Measure-Learn ilkelerini uygulayın. Kullandıkça öde stratejisini kullanarak, büyük bir yatırımı önceden sunmak yerine ölçeği genişleterek yatırım yapın.
Operasyonel mükemmellik	Hızı artırmak ve insan hatasını azaltmak için ortamı ve işlemleri otomatikleştirin. Sorun güncelleştirmelerini hızla geri alın veya ileri alın. İzleme ve tanılamayı baştan uygulayın.
Performans verimliliği	İş yüklerinize yönelik talepleri verimli bir şekilde karşılayın. Yatay ölçeklendirmeyi (ölçeği genişletme) tercih edin ve sistemlerinizde tasarlayın. Olası performans sorunlarını belirlemek için sürekli performans ve yük testi gerçekleştirin.
Güvenilirlik	Hem dayanıklı hem de kullanılabilir iş yükleri oluşturun. Dayanıklılık, iş yüklerinin hatalardan kurtulmasını ve çalışmaya devam etmelerini sağlar. Kullanılabilirlik, kullanıcıların iş yükünüz için her zaman erişmesini sağlar. Uygulamaları hataları bekleyecek ve onlardan kurtaracak şekilde tasarlar.
Güvenlik	Tasarım ve uygulamadan dağıtım ve işlemlere kadar bir uygulamanın yaşam döngüsünün tamamında güvenlik uygulayın. Kimlik yönetimi, altyapı erişimi, uygulama güvenliği ve veri hakimiyeti ile şifrelemeye çok dikkat edin.

Başlamak için Microsoft, geçerli bulut iş yüklerinizi iyi tasarlanmış beş yapı taşıyla değerlendirmenize yardımcı olacak bir dizi çevrimiçi değerlendirme sağlar.

Mikro hizmetler

Bulutta yerel sistemler, modern uygulamalar oluşturmaya yönelik popüler bir mimari stil olan mikro hizmetleri benimser.

Paylaşılan bir dokuyla etkileşim kuran küçük, bağımsız hizmetlerden oluşan dağıtılmış bir küme olarak oluşturulan mikro hizmetler aşağıdaki özellikleri paylaşır:

• Her birinin daha büyük bir etki alanı bağlamında belirli bir iş özelliği vardır.

• Her biri otonom olarak geliştirilmiştir ve bağımsız olarak dağıtılabilir.

• Her biri kendi veri depolama teknolojisini, bağımlılıklarını ve programlama platformunu kapsayan bağımsızdır.

• Her biri kendi işleminde çalışır ve HTTP/HTTPS, gRPC, WebSockets veya AMQP gibi standart iletişim protokollerini kullanarak başkalarıyla iletişim kurar.

• Bir uygulama oluşturmak için birlikte oluştururlar.

Şekil 1-4, monolitik uygulama yaklaşımını mikro hizmetler yaklaşımıyla karşıttır. Monolitenin tek bir işlemde yürütülen katmanlı bir mimariden nasıl oluştuğunu unutmayın. Genellikle ilişkisel bir veritabanı tüketir. Ancak mikro hizmet yaklaşımı, işlevselliği bağımsız hizmetlere ayırır ve bunların her biri kendi mantığına, durumuna ve verilerine sahiptir. Her mikro hizmet kendi veri deposunu barındırıyor.

Şekil 1-4. Monolitik ve mikro hizmetler mimarisi karşılaştırması

Mikro hizmetlerin, bölümün önceki bölümlerinde ele alınan On İki Öğeli Uygulama'dan İşlemler ilkesini nasıl yükselteceklerine dikkat edin.

Faktör #6 , "Her mikro hizmet, çalışan diğer hizmetlerden yalıtılmış olarak kendi işleminde yürütülmelidir" ifadesini belirtir.

Neden mikro hizmetler?

Mikro hizmetler çeviklik sağlar.

Bölümün önceki bölümlerinde monolith olarak oluşturulmuş bir e-Ticaret uygulamasını mikro hizmetlerle karşılaştırdık. Örnekte bazı net avantajlar gördük:

• Her mikro hizmetin otonom bir yaşam döngüsü vardır ve bağımsız olarak gelişebilir ve sık sık dağıtılabilir. Yeni bir özellik veya güncelleştirme dağıtmak için üç aylık sürümü beklemeniz gerekmez. Canlı bir uygulamanın küçük bir alanını, sistemin tamamını kesintiye uğratma riski daha az olacak şekilde güncelleştirebilirsiniz. Güncelleştirme, uygulamanın tam yeniden dağıtımı olmadan yapılabilir.

• Her mikro hizmet bağımsız olarak ölçeklendirilebilir. Uygulamanın tamamını tek bir birim olarak ölçeklendirmek yerine, yalnızca istenen performans düzeylerini ve hizmet düzeyi sözleşmelerini karşılamak için daha fazla işlem gücü gerektiren hizmetlerin ölçeğini genişletebilirsiniz. Ayrıntılı ölçeklendirme, sisteminizin daha fazla denetimini sağlar ve her şeyi değil, sisteminizin bölümlerini ölçeklendirdikçe genel maliyetleri azaltmaya yardımcı olur.

Mikro hizmetleri anlamak için mükemmel bir başvuru kılavuzu .NET Mikro Hizmetleri: Kapsayıcılı .NET Uygulamaları mimarisidir. Kitap, mikro hizmetler tasarımına ve mimarisine ayrıntılı bir şekilde göz atıyor. Microsoft'tan ücretsiz indirme olarak sunulan tam yığın mikro hizmet başvuru mimarisi için bir yardımcıdır.

Mikro hizmetler geliştirme

Mikro hizmetler herhangi bir modern geliştirme platformunda oluşturulabilir.

Microsoft .NET platformu mükemmel bir seçimdir. Ücretsiz ve açık kaynak, mikro hizmet geliştirmeyi basitleştiren birçok yerleşik özelliğe sahiptir. .NET platformlar arasıdır. Uygulamalar Windows, macOS ve Linux'un çoğu sürümünde derlenebilir ve çalıştırılabilir.

.NET yüksek performansa sahiptir ve Node.js ve diğer rakip platformlara göre iyi puan almıştır. İlginç bir şekilde TechEmpower, birçok web uygulaması platformunda ve çerçevesinde kapsamlı bir performans karşılaştırması kümesi yürüttü. .NET, Node.js ve diğer rakip platformların çok üstünde ilk 10'da puanlandı.

.NET , Microsoft ve GitHub'da .NET topluluğu tarafından korunur.

Mikro hizmet zorlukları

Dağıtılmış buluta özel mikro hizmetler çok büyük çeviklik ve hız sağlasa da birçok zorluk sunar:

İletişim

Ön uç istemci uygulamaları arka uç çekirdek mikro hizmetleriyle nasıl iletişim kuracak? Doğrudan iletişime izin verecek misiniz? Alternatif olarak, arka uç mikro hizmetlerini esneklik, denetim ve güvenlik sağlayan bir ağ geçidi cephesi ile soyutlayabilir misiniz?

Arka uç temel mikro hizmetleri birbiriyle nasıl iletişim kuracak? Eşleştirmeyi artırabilen ve performansı ve çevikliği etkileyebilecek doğrudan HTTP çağrılarına izin verecek misiniz? Veya kuyruk ve konu teknolojileriyle ayrılmış mesajlaşmayı göz önünde bulundurabilir misiniz?

İletişim, Buluta özel iletişim desenleri bölümünde ele alınmıştır.

Dayanıklılık

Mikro hizmetler mimarisi, sisteminizi işlem içi ağ iletişiminden işlem dışı ağ iletişimine taşır. Dağıtılmış mimaride, B Hizmeti A hizmetinden gelen bir ağ çağrısına yanıt vermediğinde ne olur? Veya C Hizmeti geçici olarak kullanılamaz duruma geldiğinde ve onu çağıran diğer hizmetler engellendiğinde ne olur?

Dayanıklılık, Bulutta yerel dayanıklılık bölümünde ele alınmıştır.

Dağıtılmış Veriler

Tasarım gereği, her mikro hizmet kendi verilerini kapsülleyerek işlemleri genel arabirimi aracılığıyla kullanıma sunar. Bu durumda, verileri nasıl sorgular veya birden çok hizmette işlem uygularsınız?

Dağıtılmış veriler, Buluta özel veri desenleri bölümünde ele alınmıştır.

Gizli Diziler

Mikro hizmetleriniz gizli dizileri ve hassas yapılandırma verilerini güvenli bir şekilde nasıl depolayacak ve yönetecek?

Gizli diziler, bulutta yerel güvenlik ayrıntılarıyla ele alınmıştır.

Dapr ile Karmaşıklığı Yönetme

Dapr dağıtılmış, açık kaynak bir uygulama çalışma zamanıdır. Takılabilir bileşenlerin mimarisi sayesinde dağıtılmış uygulamaların arkasındaki tesisatı önemli ölçüde basitleştirir. Uygulamanızı Dapr çalışma zamanından önceden oluşturulmuş altyapı özelliklerine ve bileşenlerine bağlayan dinamik bir tutkal sağlar. Şekil 1-5'de 20.000 fitten Dapr gösterilmektedir.

Şekil 1-5. Dapr 20.000 fitte.

Şeklin en üst satırında, Dapr'ın popüler geliştirme platformları için dile özgü SDK'ları nasıl sağladığına dikkat edin. Dapr v1. .NET, Go, Node.js, Python, PHP, Java ve JavaScript desteği içerir.

Dile özgü SDK'lar geliştirici deneyimini geliştirirken, Dapr platformdan bağımsızdır. Dapr'ın programlama modeli, standart HTTP/gRPC iletişim protokolleri aracılığıyla özellikleri kullanıma sunar. Herhangi bir programlama platformu Yerel HTTP ve gRPC API'leri aracılığıyla Dapr'ı çağırabilir.

Şeklin ortasındaki mavi kutular, Dapr yapı taşlarıdır. Her bir uygulama, uygulamanızın kullanabileceği dağıtılmış bir uygulama özelliği için önceden oluşturulmuş tesisat kodunu kullanıma sunar.

Bileşenler satırı, uygulamanızın kullanabileceği önceden tanımlanmış büyük bir altyapı bileşeni kümesini temsil eder. Bileşenleri yazmak zorunda olmadığınız altyapı kodu olarak düşünün.

Alt satırda Dapr'ın taşınabilirliği ve üzerinde çalışabileceği çeşitli ortamlar vurgulanır.

İleriye baktığımızda Dapr, bulutta yerel uygulama geliştirme üzerinde derin bir etkiye sahip olma potansiyeline sahiptir.

Kapsayıcılar

Herhangi bir bulutta yerel konuşmada bahsedilen kapsayıcı terimini duymak doğaldır. Bulutta Yerel Desenler adlı kitapta yazar Cornelia Davis, "Kapsayıcılar buluta özel yazılımların büyük bir etkinleştiricisi" olduğunu gözlemlemektedir. Cloud Native Computing Foundation, buluta özel yolculuğuna başlayan kuruluşlara yönelik rehberlik olan Buluta Özel İz Haritası'nda mikro hizmet kapsayıcılarını ilk adım olarak yerleştirir.

Mikro hizmeti kapsayıcılı hale getirme basit ve basittir. Kod, bağımlılıkları ve çalışma zamanı kapsayıcı görüntüsü olarak adlandırılan bir ikili dosyaya paketlenir. Görüntüler, görüntüler için depo veya kitaplık işlevi gören bir kapsayıcı kayıt defterinde depolanır. Kayıt defteri geliştirme bilgisayarınızda, veri merkezinizde veya genel bir bulutta bulunabilir. Docker, Docker Hub aracılığıyla bir genel kayıt defteri tutar. Azure bulutu, kapsayıcı görüntülerini çalıştıracak bulut uygulamalarının yakınında depolamak için özel bir kapsayıcı kayıt defterine sahiptir.

Bir uygulama başlatıldığında veya ölçeklendirildiğinde, kapsayıcı görüntüsünü çalışan bir kapsayıcı örneğine dönüştürürsiniz. Örnek, bir kapsayıcı çalışma zamanı altyapısının yüklü olduğu herhangi bir bilgisayarda çalışır. Kapsayıcılı hizmetin gerektiği kadar örneğine sahip olabilirsiniz.

Şekil 1-6'da, her biri kendi kapsayıcısında, tümü tek bir konakta çalışan üç farklı mikro hizmet gösterilmektedir.

Şekil 1-6. Kapsayıcı konağı üzerinde çalışan birden çok kapsayıcı

Her kapsayıcının birbirinden farklı olabilecek kendi bağımlılık kümesini ve çalışma zamanını nasıl koruduğuna dikkat edin. Burada, aynı konakta çalışan Product mikro hizmetinin farklı sürümlerini görüyoruz. Her kapsayıcı temel konak işletim sisteminin, belleğin ve işlemcinin bir dilimini paylaşır, ancak birbirinden yalıtılır.

Kapsayıcı modelinin Twelve-Factor Application'dan Bağımlılıklar ilkesini ne kadar iyi benimsemiş olduğunu unutmayın.

Factor #2, "Her mikro hizmet, tüm sistemi etkilemeden değişiklikleri benimseyarak kendi bağımlılıklarını yalıtıp paketler" ifadesini belirtir.

Kapsayıcılar hem Linux hem de Windows iş yüklerini destekler. Azure bulutu her ikisini de açıkça benimser. İlginç bir şekilde, Azure'daki en popüler işletim sistemi haline gelen Windows Server değil Linux'tır.

Birkaç kapsayıcı satıcısı varken Docker, aslanların pazardaki payını yakaladı. Şirket, yazılım kapsayıcısı hareketini yönlendirdi. Buluta özel uygulamaları paketlemek, dağıtmak ve çalıştırmak için de facto standart haline gelmiştir.

Neden kapsayıcılar?

Kapsayıcılar taşınabilirlik sağlar ve ortamlar arasında tutarlılık sağlar. Her şeyi tek bir pakette kapsülleyerek mikro hizmeti ve bağımlılıklarını temel alınan altyapıdan yalıtmış olacaksınız.

Kapsayıcıyı Docker çalışma zamanı altyapısını barındıran herhangi bir ortama dağıtabilirsiniz. Kapsayıcılı iş yükleri ayrıca çerçeveler, yazılım kitaplıkları ve çalışma zamanı altyapıları ile her ortamı önceden yapılandırma masrafını ortadan kaldırır.

Temel alınan işletim sistemi ve konak kaynakları paylaşılarak kapsayıcı, tam bir sanal makineden çok daha küçük bir ayak izine sahiptir. Daha küçük boyut, belirli bir konağın aynı anda çalıştırabileceği yoğunluğu veya mikro hizmet sayısını artırır.

Kapsayıcı düzenleme

Docker gibi araçlar görüntüler oluşturur ve kapsayıcıları çalıştırırken, bunları yönetmek için araçlara da ihtiyacınız vardır. Kapsayıcı yönetimi, kapsayıcı düzenleyicisi adı verilen özel bir yazılım programıyla gerçekleştirilir. Çok sayıda bağımsız çalışan kapsayıcıyla büyük ölçekte çalışırken düzenleme önemlidir.

Şekil 1-7'de kapsayıcı düzenleyicilerinin otomatikleştirmiş olduğu yönetim görevleri gösterilmektedir.

Şekil 1-7. Kapsayıcı düzenleyicileri ne yapar?

Aşağıdaki tabloda yaygın düzenleme görevleri açıklanmaktadır.

Görevler	Açıklama
Zamanlama	Kapsayıcı örneklerini otomatik olarak sağlayın.
Benzeşim/benzeşim karşıtı	Yakınlardaki veya birbirinden uzak kapsayıcılar sunarak kullanılabilirlik ve performansa yardımcı olun.
Sistem durumunu izleme	Hataları otomatik olarak algılayın ve düzeltin.
Yük devretme	Başarısız bir örneği iyi durumdaki bir makineye otomatik olarak yeniden sağlama.
Ölçeklendirme	Talebi karşılamak için kapsayıcı örneğini otomatik olarak ekleyin veya kaldırın.
Ağ	Kapsayıcı iletişimi için ağ katmanını yönetme.
Hizmet Bulma	Kapsayıcıların birbirini bulmasını sağlayın.
Sıralı Yükseltmeler	Artımlı yükseltmeleri sıfır kapalı kalma süresi dağıtımıyla koordine edin. Sorunlu değişiklikleri otomatik olarak geri alma.

Kapsayıcı düzenleyicilerinin, Twelve-Factor Uygulaması'ndan Disposability ve Concurrency ilkelerini nasıl benimsemiş olduğunu unutmayın.

Factor #9, "Hizmet örneklerinin atılabilir olması gerektiğini, ölçeklenebilirlik fırsatlarını artırmak için hızlı başlangıçları ve sistemi doğru durumda bırakmak için düzgün kapatmaları tercih ettiğini" belirtir. Docker kapsayıcıları ve bir düzenleyici bu gereksinimi doğal olarak karşılar."

Faktör #8, "Hizmetler, kullanılabilir en güçlü makinede tek bir büyük örneğin ölçeğini artırmanın aksine çok sayıda küçük özdeş işlem (kopya) genelinde ölçeği genişletir" ifadesini belirtir.

Çeşitli kapsayıcı düzenleyicileri mevcut olsa da Kubernetes, buluta özel dünya için olgu standardı haline gelmiştir. Kapsayıcılı iş yüklerini yönetmeye yönelik taşınabilir, genişletilebilir, açık kaynak bir platformdur.

Kendi Kubernetes örneğinizi barındırabilirsiniz, ancak daha sonra kaynaklarını sağlamak ve yönetmek sizin sorumluluğunuzdadır; bu karmaşık olabilir. Azure bulutu, yönetilen hizmet olarak Kubernetes'i içerir. Hem Azure Kubernetes Service (AKS) hem de Azure Red Hat OpenShift (ARO), kubernetes'i yükleyip bakımını yapmak zorunda kalmadan yönetilen hizmet olarak özelliklerinden ve gücünden tam olarak yararlanmanızı sağlar.

Kapsayıcı düzenlemesi, Bulutta Yerel Uygulamaları Ölçeklendirme bölümünde ayrıntılı olarak ele alınmıştır.

Yedekleme hizmetleri

Bulutta yerel sistemler veri depoları, ileti aracıları, izleme ve kimlik hizmetleri gibi birçok farklı yardımcı kaynağa bağlıdır. Bu hizmetler, yedekleme hizmetleri olarak bilinir.

Şekil 1-8'de bulutta yerel sistemlerin tükettiği birçok yaygın yedekleme hizmeti gösterilmektedir.

Şekil 1-8. Yaygın yedekleme hizmetleri

Kendi yedekleme hizmetlerinizi barındırabilirsiniz, ancak daha sonra bu kaynakları lisanslama, sağlama ve yönetme sorumluluğu size aittir.

Bulut sağlayıcıları, yönetilen yedekleme hizmetlerinin zengin bir yelpazesini sunar. Hizmete sahip olmanız yerine yalnızca bunu tüketirsiniz. Bulut sağlayıcısı, kaynağı büyük ölçekte çalıştırır ve performans, güvenlik ve bakım sorumluluğunu üstlenir. İzleme, yedeklilik ve kullanılabilirlik, hizmette yerleşik olarak bulunur. Sağlayıcılar hizmet düzeyi performansını garanti eder ve yönetilen hizmetlerini tam olarak destekler. Bir bilet açar ve sorununuzu çözerler.

Buluta özel sistemler, bulut satıcılarının yönetilen yedekleme hizmetlerini destekler. Zaman ve emek tasarrufu önemli olabilir. Kendi barındırma ve sorun yaşamanın operasyonel riski hızlı bir şekilde pahalıya ulaşabilir.

En iyi yöntem, bir yedekleme hizmetini dış yapılandırmada depolanan yapılandırma bilgileri (URL ve kimlik bilgileri) ile dinamik olarak bir mikro hizmete bağlı ekli bir kaynak olarak ele almaktır. Bu kılavuz, bölümün önceki bölümlerinde ele alınan Twelve-Factor Application'da açıklandı.

Factor #4 , destek hizmetlerinin "adreslenebilir bir URL aracılığıyla kullanıma sunılması gerektiğini belirtir. Bunun yapılması, kaynağı uygulamadan ayrıştırarak değiştirilebilir olmasını sağlar."

Faktör #3 , "Yapılandırma bilgileri mikro hizmetten taşınır ve kodun dışındaki bir yapılandırma yönetim aracı aracılığıyla dışlanır" ifadesini belirtir.

Bu düzende, bir yedekleme hizmeti kod değişikliği olmadan eklenebilir ve ayrılabilir. Mikro hizmeti Soru-Cevap'tan hazırlama ortamına yükseltebilirsiniz. Mikro hizmet yapılandırmasını hazırlamadaki yedekleme hizmetlerine işaret etmek için güncelleştirir ve ayarları bir ortam değişkeni aracılığıyla kapsayıcınıza eklersiniz.

Bulut satıcıları, kendi özel destek hizmetleriyle iletişim kurmanız için API'ler sağlar. Bu kitaplıklar, özel tesisat ve karmaşıklığı kapsüller. Ancak, bu API'lerle doğrudan iletişim kurmak kodunuzu belirli bir destek hizmetiyle sıkı bir şekilde ilişkilendirecektir. Satıcı API'sinin uygulama ayrıntılarını yalıtmak yaygın olarak kabul edilen bir uygulamadır. Hizmet kodunuz için genel işlemleri ortaya çıkartarak bir aracı katmanı veya ara API tanıtın ve satıcı kodunu içine sarmalayın. Bu gevşek bağlantı, ana hat hizmet kodunda değişiklik yapmanıza gerek kalmadan bir yedekleme hizmetini başka bir destek hizmetiyle değiştirmenizi veya kodunuzu farklı bir bulut ortamına taşımanızı sağlar. Daha önce ele alınan Dapr, bu modeli önceden oluşturulmuş yapı taşları kümesiyle birlikte izler.

Son bir düşünceyle, destek hizmetleri bölümün önceki bölümlerinde ele alınan Twelve-Factor Application'ın Statelessness ilkesini de teşvik eder.

Faktör #6 şunu belirtir: "Her mikro hizmet, çalışan diğer hizmetlerden yalıtılmış olarak kendi işleminde yürütülmelidir. Gerekli durumu dağıtılmış önbellek veya veri deposu gibi bir yedekleme hizmetiyle dışlaştır."

Yedekleme hizmetleri, Buluta özel veri desenleri ve Bulutta yerel iletişim desenleri konularında ele alınıyor.

Otomasyon

Gördüğünüz gibi buluta özel sistemler hız ve çeviklik elde etmek için mikro hizmetleri, kapsayıcıları ve modern sistem tasarımını benimser. Ama bu hikayenin sadece bir parçası. Bu sistemlerin üzerinde çalıştığı bulut ortamlarını nasıl sağlarsınız? Uygulama özelliklerini ve güncelleştirmelerini hızla nasıl dağıtabilirsiniz? Resmin tamamını nasıl yuvarlarsın?

Kod olarak Altyapı veya IaC'nin yaygın olarak kabul edilen uygulamasını girin.

IaC ile platform sağlama ve uygulama dağıtımlarını otomatikleştirirsiniz. Temel olarak DevOps uygulamalarınıza test ve sürüm oluşturma gibi yazılım mühendisliği uygulamaları uygularsınız. Altyapınız ve dağıtımlarınız otomatik, tutarlı ve yinelenebilir.

Altyapıyı otomatikleştirme

Azure Resource Manager, Azure Bicep, HashiCorp'tan Terraform ve Azure CLI gibi araçlar, ihtiyacınız olan bulut altyapısını bildirimli olarak betik olarak yazmanızı sağlar. Kaynak adları, konumlar, kapasiteler ve gizli diziler parametreli ve dinamiktir. Betik sürümü oluşturulur ve kaynak denetimine projenizin yapıtı olarak iade edilir. Betiği çağırarak soru-cevap, hazırlama ve üretim gibi sistem ortamlarında tutarlı ve yinelenebilir bir altyapı sağlarsınız.

IaC, arka planda aynı betiği yan etkiler olmadan tekrar tekrar çalıştırabileceğiniz anlamına gelir. Ekibin değişiklik yapması gerekiyorsa betiği düzenler ve yeniden çalıştırır. Yalnızca güncelleştirilmiş kaynaklar etkilenir.

Kod Olarak Altyapı Nedir? makalesinde Yazar Sam Guckenheimer, "IaC'yi uygulayan ekipler kararlı ortamları hızlı ve uygun ölçekte sunabilir. Ortamların el ile yapılandırılmasını önler ve kod aracılığıyla ortamlarının istenen durumunu temsil ederek tutarlılığı zorlar. IaC ile altyapı dağıtımları tekrarlanabilir ve yapılandırma kaymasından ve bağımlılıkların eksik kalmasından kaynaklanan çalışma zamanı sorunları önlenir. DevOps ekipleri, uygulamaları ve destekleyici altyapılarını hızlı, güvenilir ve uygun ölçekte sunmak için birleşik bir dizi uygulama ve araçla birlikte çalışabilir."

Dağıtımları otomatikleştirme

Daha önce açıklanan Twelve-Factor Application, tamamlanmış kodu çalışan bir uygulamaya dönüştürürken ayrı adımlar için çağrıda bulunur.

Factor #5 şu ifadeyi belirtir: "Her sürüm, derleme, sürüm ve çalıştırma aşamaları arasında katı bir ayrım uygulamalıdır. Her birinin benzersiz bir kimlikle etiketlenmesi ve geri alma özelliğini desteklemesi gerekir."

Modern CI/CD sistemleri bu ilkenin yerine getirilmesine yardımcı olur. Kullanıcılara hazır tutarlı ve kaliteli kod sağlamaya yardımcı olan ayrı derleme ve teslim adımları sağlar.

Şekil 1-9 arasında dağıtım işlemi arasındaki ayrım gösterilmektedir.

Şekil 1-9. CI/CD İşlem Hattında dağıtım adımları

Önceki şekilde, görevlerin ayrılmasına özellikle dikkat edin:

1. Geliştirici, geliştirme ortamında kod, çalıştırma ve hata ayıklamanın "iç döngüsü" olarak adlandırılan öğeyi yineleyerek bir özellik oluşturur.
2. Tamamlandığında, bu kod GitHub, Azure DevOps veya BitBucket gibi bir kod deposuna gönderilir .
3. Gönderme işlemi, kodu ikili yapıta dönüştüren bir derleme aşamasını tetikler. Çalışma bir Sürekli Tümleştirme (CI) işlem hattı ile uygulanır. Uygulamayı otomatik olarak derler, test eder ve paketler.
4. Yayın aşaması ikili yapıtı alır, dış uygulama ve ortam yapılandırma bilgilerini uygular ve sabit bir sürüm oluşturur. Sürüm, belirtilen bir ortama dağıtılır. Çalışma bir Sürekli Teslim (CD) işlem hattı ile uygulanır. Her sürüm tanımlanabilir olmalıdır. "Bu dağıtım uygulamanın Sürüm 2.1.1'ini çalıştırıyor" diyebilirsiniz.
5. Son olarak, yayımlanan özellik hedef yürütme ortamında çalıştırılır. Sürümler sabittir ve herhangi bir değişikliğin yeni bir sürüm oluşturması gerektiği anlamına gelir.

Bu uygulamaları uygulayan kuruluşlar, yazılım gönderme yöntemlerini kökten geliştirmişlerdir. Birçoğu üç aylık sürümlerden isteğe bağlı güncelleştirmelere geçmiştir. Amaç, geliştirme döngüsünün erken dönemlerinde düzeltilmesi daha düşük maliyetli olan sorunları yakalamaktır. Tümleştirmeler arasındaki süre ne kadar uzun olursa, sorunların çözülmesi o kadar pahalı olur. Tümleştirme sürecinde tutarlılık sayesinde ekipler kod değişikliklerini daha sık işleyebilir ve daha iyi işbirliği ve yazılım kalitesi sağlar.

Kod olarak altyapı ve dağıtım otomasyonu ile GitHub ve Azure DevOps, DevOps'ta ayrıntılı olarak ele alınıyor.

Geriİleri