Photo by Alexander Schimmeck on Unsplash

As a part of the web ecosystem, our main concern is how to create an application that handles more, many more requests and how to keep it afloat. Am I wrong?

Whatever you have, such as monolith, microservices, or functions you need to create ways to deal with the concern. You can add a new machine into your infrastructure (please don’t say, “ok boomer”, I’m not!) or watch the actions from your monitoring systems and click the red button: auto-deploy the new instance and split the traffic! …


Henüz Let’s Encrypt gibi, ücretsiz TLS sertifikaları üreten ve periyodik olarak yenileyen — dolayısıyla hem zamandan hem de bütçeden tasarruf sağlayan — sistemleri henüz kullan(a)mıyorsanız, sertifika isteme/temin etme ve uygulama adımlarında geleneksel yöntemleri izliyor olmanız olası. Bu “el feneri” yazısında da Istio Gateway ile yönettiğimiz trafiği güvenli hale getirmek için izlememiz gereken yolu tarif etmeye çalışacağım.

Fotoğraf, Marcos Mayer tarafından çekilmiş ve Unsplash üzerinde yayınlanmıştır.

Istio — Trafik Yönetimi

Kısayola geçmeden önce genel bilgi mahiyetinde, Istio’nun trafiği yönetmek için kurguladığı mimariden bahsetmekte fayda var.

OSI (Open Systems Interconnection) modeline göre; trafiğin hangi protokolde gerçekleşeceği (TCP, UDP, RDP, SCTP, vb.), ne kadar veri taşınacağı, verinin nereye taşınacağı (Layer 4 — Transport); bahsi geçen trafikteki…


Bu yazı tam olarak “Writing Your First Kubernetes Operator” tadında bir yazı olmayacak, “What is Kubernetes Operator” konulu olacağını söylemek de yanlış olacaktır. Ne olduğunu söylemiyorsun, nasıl yazılacağını da anlatmıyorsun. O halde neden devam edeyim? dediğinizi duyar gibiyim. Onu da aşağıdaki girizgah ile özetleyeceğim ki çok vaktinizi almayayım.

Fotoğraf, Dan Lohmar tarafından çekilmiş ve Unsplash üzerinde yayınlanmıştır.

Hikayenin Başlangıç Noktası

Haftasonu, sevgili Gökhan Şengün’ün “Kubernetes Native Uygulama Geliştirme” konulu bir etkinliği vardı. Etkinliğin bir noktasında, iş süreçlerine özel bazı ihtiyaçlar konusunda Kubernetes’in native objelerinin tam olarak cevap veremediğinden dem vuruldu. Bunun üzerine ise ortaya “Kubernetes Operator” başlığı çıktı.

İş süreçlerine özel bazı ihtiyaçlar tam olarak neyi ifade eder?

In-memory bir storage uygulaması geliştirdiğimizi düşünelim. Uygulamanızın temel mimarisinde bir master ve {N} replika…


Yeni bir projeye başladığımızda öncelikle klasör hiyerarşimizi hazırlarız. Sonrasında bu klasörlere ihtiyaç duyulan proje nesnelerini ekler, GIT repository’imizi oluştururuz. .gitignore dosyamızı da ekleriz ki repository’de yer almasını istemediğimiz kritik — ya da geliştiriciye özel — bilgileri, dosyaları public olarak sunmayalım. Bunun yanı sıra, projemizi containerize edeceksek bir de son olarak Dockerfile ekleriz. Hemen hemen docker image’ımızın ilk versiyonu için hazır gibiyiz: docker build -t selcukusta/proje:1.0.0

Ve sonrasında mikro mikro uygulamalar, bir çok image. Hepsi de çalışıyor, boyutları da oldukça ideal denilebilir. Belki de şikayet etttiğimiz tek nokta şu olabilir: Bu build neden bu kadar uzun sürüyor?


Geçtiğimiz haftalarda yapmış olduğumuz geçişin kısa öyküsünü paylaşmıştım. Bu geçişin de bir başlangıç olduğunu ve karşılaşacağımız sorunlar/ihtiyaçlar doğrultusunda peyderpey geliştirmelere — ve gelişmeye — devam edeceğimiz üzerine de bir not bırakmıştım.

Geçiş sonrası oluşan en temel ihtiyaç, her web uygulamasında olduğu gibi bu uygulamamızda da “header manipulation” konusu oldu.

Hasıl olan ihtiyaç neydi?

Son kullanıcıya dönecek olan cevabın header’ına bir takım bilgileri dahil etmek olarak özetlenebilir. Aslına bakarsanız bu iş Istio özelinde zor bir iş değil. Bir VirtualService tanımlarken aşağıdaki görselde de göreceğiniz üzere spec.http.match.route.destination.headers alanına,request başlığı ile upstream’e gönderilecek header bilgilerini; response başlığı ile de client’e gönderilecek header bilgilerini ekleyebiliyoruz.

Dinamik konfigürasyonlara ihtiyaç duyarsak?

İhtiyacımız bir adım…


TL;DR — Tamamen müşterilerimiz tarafından kullanılan raporlama ve talep yönetimi uygulamamız, monolitik bir yapıda .NET Core çatısı üzerine kurulu olarak IIS üzerinde konumlanmaktaydı. Geçiş projemiz ile, uygulama içerisindeki modülleri fonksiyonel olarak gruplayarak RESTful servisler haline getirdik. Servislerimizi ve UI projemizi Dockerize ederek Kubernetes üzerinde konumlandırdık. Projenin mevcut monitoring, tracing ve logging altyapılarını da yeni sisteme adapte ederek olası sorunlar durumunda daha hızlı refleks gösterebilir bir ekip haline gelmeye yaklaştık.

Fotoğraf, Shripal Daphtary tarafından çekilmiş ve Unsplash üzerinde yayınlanmıştır.

En sonda söylenmesi gerekeni en başta söylemekte fayda var diye düşünüyorum. Bu geçiş hikayesinde kullanılan teknik ve teknolojiler bizim için bir reform noktası. Devam eden süreç içerisinde bazıları değişecek/yenilenecek ve bir…


Web uygulamaları geliştiren hemen hemen tüm geliştiricilerin bir şekilde yolunun düştüğü Varnish, en kaba tabiriyle backend çıktısını önbellekleyen ve sunan, aynı zamanda HTTP reverse proxy yeteneğine de sahip, açık kaynak kodlu güçlü — ve hızlı — bir ürün.

Hızlı ve stabil olmasının yanı sıra, ürünü güçlü kılan en önemli özelliklerinden bir tanesi genişletilebilir olması. VMOD adını verdikleri eklenti özelliği sayesinde; komünite tarafından (bireysel geliştiricilerin yanısıra NY Times gibi şirketler de bu ürün üzerinde çalışıyor ve eklentiler geliştiriyor) eklenen yeni özelliklerle birlikte, ürünün kullanım alanı gün geçtikte genişliyor.

Geliştirilmesi durmuş ama hala çalışan, hala geliştirilme aşamasında olan ve stabil olduğu kabul…


Şef muhtemelen ana yemeğe konsantre olduğu için, sizin aperitif yemek unutuldu sanırım!

Fotoğraf, Fabrizio Magoni tarafından çekilmiş, Unsplash’den indirilmiştir.

Uygulama geliştirirken de sıklıkla — ve refleks olarak — davrandığımız üzere; isteri karşılayacak olan algoritmayı ve algoritmayı sarmalayacak olan fonksiyonu tasarlarken davranışları gözardı ediyoruz. Oysa ki geçtiğimiz zamanlarda okuduğum (referansı hatırladığım an link ekleyeceğim) ve hala aklımda olan şu cümle çok önemli;

Fonksiyonları tasarlarken birincil endişe, algoritmalar değil davranışlar olmalıdır. Davranışlar ise algoritmaların seçimi konusunda sizi doğru kısıt ve yönlendirmelere itecektir.

Bu davranış sebebiyle de test yönelimli geliştirme (Test-Driven Development) kültürüne adaptasyonumuz zorlu oluyor, hatta bazen — ne yazık ki — olamıyor.

Test-Driven Development

Önce testi yaz, sonra fonksiyonu! yaklaşımı…


Konuya girmeden önce, şu “containerized application” kavramını Türkçeleştirebilenler varsa, geliştiriciler olarak yardıma muhtaç durumdayız, duyurulur :)

Fotoğraf, Markus Spiske tarafından çekilmiş, Unsplash’den indirilmiştir.

Cloud dünyası aldı başını gidiyor, malumumuz. Geliştirdiğimiz uygulamalar da bu dünyanın doğasına uygun bir biçimde evrilmeye başladı. Geleneksel, her parçanın tek bir merkezden yürütüldüğü uygulamalar; yerlerini yavaş yavaş küçük parçalara bölünmüş ve her biri kendinden sorumlu mikro — hatta nano — uygulamalara bırakmaya başladı. Bununla birlikte de yazılım kültürü ve teknolojiler, jargonlar değişmeye başladı haliyle. Bu adaptasyon sürecinde bazı tekniklerimiz hızla kaybolup gözden uzaklaşırken (Memory cache kullanmayalı o kadar zaman oldu ki…), bazıları uygulamanın tipinden (monolitik/mikro) bağımsız olarak varlığını sürdürüyor. …


Baştan söylemeliyim ki, konu hem MongoDB ürünü özelinde hem de — özellikler ve kavramlar değişse dahi — NoSQL sistemler genelinde deniz derya! Dokümantasyonlara, örneklere, blog yazılarına daldığımızda Casual Consistency, Eventual Consistency, Availability, Dirty Read, Replica Set, teoremler, pratikler, kullanım senaryoları gibi birbirinden kompleks durum ve kavramlarla karşılaşmamız an meselesi oluyor.

Bu yazıda ise mümkün olduğunca Keep It Simple, Stupid! prensibine uygun bir biçimde, bazı temel özelliklere değinip örneklemeler yoluyla, MongoDB’nin ilgili özelliklerini incelemeye çalışacağız. Belki konu konuyu açar ve diğer yazılarda diğer önemli detaylara da değinme fırsatı buluruz. Hazırsak başlayalım o halde.

Görsel Kaynağı

Eric Brewer’ın Kulaklarını Çınlatalım

NoSQL sistemlerle çalışan hemen hemen herkesin ilk günden…

Selçuk Usta

Software Development Manager (at) Rasyotek. Former trainer & consultant. Family member of C# and Python. Newbie on Unix. Articles are mostly about coding.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store