Önbellek (Cache), kullanıcı isteklerine daha hızlı cevap verebilmek, uygulama performansını arttırmak, oluşabilecek dar boğazları önlemek ve sistemlere gelen yükü minimuma indirmek gibi amaçlarla ihtiyaç duyulan verilerin geçici olarak depolandığı, hızlı erişim sağlanabilen yapılardır.
1. Dağıtık Önbellekleme (Distributed Caching) İhtiyacı
Geliştirmekte olduğumuz uygulama, birçok farklı modüle sahiptir. Bu modüllerin her biri, kendi veritabanını kullanmakta ve istenildiğinde her bir modülün backend servisleri ayrı deploy edilebilmektedir. Buradaki yaklaşım mikroservis ve mikro veritabanı gibi düşünülebilir.
Dağıtık bir uygulama söz konusu olduğunda, servisler aralarında haberleşmek için Event/Message Bus, Rest/RPC call gibi farklı araç ve teknolojiler kullanılmaktadır. Dağıtık bir uygulama, monolit yapıya göre daha fazla ağ trafiği oluşturmakta ve uygulama performansı (throughput)…
Uzun yıllardır yazılım geliştirirken kullandığım bir yönteme, “artık bu işin bi adını koymalıyım” fikri üzerine araştırma yapmaya başlamıştım ki bingo! Benzer bir yaklaşım on yıl kadar önce, MSDNSweden takımı tarafından Comment Driven Development olarak adlandırılmış olduğunu, daha geçmişe gittiğimde iseTODO-Driven Development gibi bir yaklaşımın varlığını gördüm. Bu iki yöntemi inceledikten sonra kendi kullandığım yöntemin ikisi ile de benzer yönlerinin olduğunu fakat bir o kadar da farklılıkları olması üzerine bu yöntemi yeni bir isim ile yani Comment First Development olarak adlandırmanın daha doğru olacağını düşündüm.
Todo Driven Development, yapılması gerekenlerin gelişi güzel koda sertpiştirildiği bir geliştirme yöntemi, Comment Driven Development ise…
Uygulamaların kesintisiz hizmet verebilmesi için; mimarinin doğru tasarlanması, geliştiricilerin de bu mimariye uygun ve hataya sebebiyet vermeyecek uygulamalar geliştirmesi gerekir. Ne yazık ki her zaman bunu başaramayabiliriz ve neyse ki kesintisiz hizmet verebilmek için uygulayabileceğimiz yaklaşımlar mevcut, bu yaklaşımların literatürdeki adı “Resilience Pattern” ’dır. Resilience Pattern’ları çözdüğü problem alanına göre farklı kategorilere ayırarak, ayrı başlık altında incelemek mümkün, fakat bu yazıda en çok ihtiyaç duyulan ve kullanılması elzem olan tasarım desenlerine bakacağız.
Mikroservis mimarisi üzerine çalışıyorsanız farkedeceksiniz ki en önemli problemlerden bir tanesi; geliştirilen mikroservisler arasındaki iletişim mimarisini kurgulamaktır. Monolitik ve *SOA mimaride geliştirilen uygulamalarda servisler arası iletişim gibi bir problem ihtiyacı genellikle yoktur, ihtiyaç olduğu durumlarda ise http request’ler veya internal event’ler ile kolaylıkla çözülebilmektedir.
Bu yazıda mikroservis mimaride iletişim yöntemlerini, örnek olarak tasarlayacağımız bir rezervasyon platformu ile öğreneceğiz. Bu platformun sahip olması gereken temel servisleri belirleyecek ve bu servisler arası iletişimin nasıl yapılabileceğini örnek senaryolar ile öğreneceğiz.
Mikroservisimizi Tasarlayalım
En temel işlevlere sahip bir rezervasyon platformu yapalım, örneğin; booking.com benzeri olsun. …
Helm Kubernetes kümesine kolay deployment yapılabilmesini sağlayan, Kubernetes paket yöneticisidir. Uygulamalarınızı Kubernetes kümesinde ayağa kaldırmak için yazmanız gereken tüm yapılandırma dosyalarını (deployment yml, ingress, persistent volumes, services, vb.) tek bir “dosya” ile yönetebilen, tüm yapılandırmaları versiyonlayabilen gerektiğinde versiyonlar arasında geçiş yapabilmenizi sağlayan bir araçtır.
Sıklıkla duyacağınız kavramlardan başlıcaları chart ve template’dir. Helm chart’lar Kubernetes’a deployment için yazılan tüm kaynak atamalarının yapıldığı yapılandırma dosyalarını ve helm şablonlarını barındıran pakettir. Template ise yapılandırma dosyaları için temel şablon sağlayan istediğiniz gibi taşımanızı değiştirmenizi veya başka geliştiriciler tarafından kullanılabilmesini sağlayan dosyalardır. Helm bunu sağlarken yapılandırma dosyalarındaki sabit tanımlamaları (port, ip, kullanıcı adı, parola, docker…
12faktör, Heroku’nun kurucu ortaklarından Adam Wiggins’ın kendi deneyimlerinden yola çıkarak, DevOps, teknoloji, programlama dili, mimari, vb. konuları kapsayacak şekilde oluşturulmuş olduğu on iki maddelik bir manifestodur. Bu manifesto, bulut odaklı uygulama geliştirilirken uygulanması gereken best practices’lere değinen bir kılavuz niteliği taşımaktadır.
12 Faktör kısaca aşağıdaki başlıklardan oluşmaktadır.
Codebase, dependencies, config, backing services, build-release-run, processes, port binding, concurrency, disposability, dev/prod parity, logs, admin processes
Kimler İçin
Yazılım geliştiriciler, yazılım mimarları ve DevOps mühendisleri bu yazının hedef kitlesidir. Adam Wiggins’e göre ise; servis odaklı uygulama geliştiren, dağıtan veya yöneten herkes bu manifestonun muhattabıdır.
1. Codebase
Kaynak kodlar versiyon kontrol sistemi (Git, SVN, TFS, vb.) üzerinde…
Bu rehberde, ASP.Net Core uygulaması ve bu uygulamanın Entity Framework Core ile birlikte kullanacağı bir SQL Server’ı Kubernetes kümesinde çalıştıracağız. Bunu yaparken uygulamamızı dockerize edeceğiz. Uygulamamız ve SQL Server dockerize edilmiş olarak ayrı podlarda çalışacaktır. ASP .Net Core uygulamasının yatay ölçeklenebilir olmasını istiyoruz fakat SQL Server’ın ise yatay olarak ölçeklenmesi yerine, tek bir pod olmasını ve tüm SQL Server podlarının merkezi paylaşımlı diski kullanmasını istiyoruz. Veritabanı podunun tek bir disk kullanması ile bu podun kapanması durumunda veri kaybının önüne geçilmiş olacaktır. .NET Core uygulaması Entity Framework Core kullanmakta ve veritabanı connection string ifadesini ise parametre olarak almaktadır. Yazılan deployment dosyaları…
