Monolitikten mikroservis mimariye geçiş serüvenim
Yıllarını Java ekosisteminde ve monolitik mimarili sistemlerde geçirmiş bir yazılım mühendisi olarak, Yolda.com’da sunucusuz (serverless) mikroservis mimariye geçiş serüvenimden bahsetmek istiyorum. Benzer süreçleri yaşayan, genelde mikroservis mimaride, özelde Amazon AWS ekosisteminde çalışmayı planlayan arkadaşlara ne ile karşılaşacakları konusunda bir nebze yardımcı olacağını umuyorum. Bunlara ek olarak, alışkın olduğumuz problem çözme yöntemlerinin AWS karşılıklarına da değinmeye çalışacağım.
Old School Java Developer
Yolda.com’dan önceki tecrübe birikimimden bahsedecek olursak, çoğunlukla Java ekosisteminde çalıştım. Spring, Spring Boot, Hibernate gibi teknolojilerle oldukça içli dışlı oldum. Çalıştığım uygulamalar monolitik mimarideydi ve bir sürüm çıkmak demek en nihayetinde komple projenin derlenip bir adet artifact oluşturmak ve devreye almak demekti. Kurumsal uygulama geliştirme ihtiyaçlarında artık bir sektör standardı haline gelmiş Spring / Spring Boot gibi framework’lerin sunduğu problem çözme yöntemlerine oldukça alışmıştım. Yolda.com’da ise yine Java’da çalıştığımız projeler olmakla birlikte daha çok Node.js / Typescript ağırlıklı geliştirme yapıyoruz. Mikroservis mimarideki API projelerimizde yaptığımız geliştirmeleri birbirinden bağımsız şekilde hızlıca devreye alabiliyoruz. Yazılım altyapı ihtiyaçlarını mümkün olduğunca kendimiz geliştirmek yerine bulut bilişimin hizmetlerinden faydalanıp enerjimizi ürüne katma değer katmaya ayırıyoruz. Bunu yaparken de çok fazla yeni teknoloji ve kavramla tanışma fırsatı buluyoruz.
Yeni kavramlar yeni dünyalar
Yolda.com serüvenimde dünya için değil ama benim için yeni olan kavramlarla karşılaştım. Serverless, mesela. Kodlar havada çalışmıyor tabii ki, sonuçta bir sunucuda çalışıyor. Ancak o sunucunun kurulması, yönetilmesi, idame edilmesi ile biz ilgilenmiyoruz. Biz sadece işimizi görecek, derdimizi anlatacak kadar kod yazıyoruz ve o kodun derlenmesinden tutun da production ortamında hizmet vermesine kadarki süreçlerle hizmet aldığımız Amazon ilgileniyor.
Mikroservis de üzerinde çalışma fırsatı bulduğum yeni kavramlardan. Kendine özgü geliştirme ve devreye alma süreçleri olan, farklı takımlar tarafından minimum etkileşim gerektirerek geliştirilebilen yazılım çözümleri aslında. Contract Test kavramını da bu listeye ekleyebilirim. Çalışan bir sistem kurmak başarıdır. O sistemi büyüdükçe, dallanıp budaklandıkça çalışır halde tutmak daha önemli bir başarıdır. Biri diğerini çağıran, birbirinden bağımsız geliştirilen o kadar çok API endpoint oluyor ki bu servislerin başarıyla çalışır halde kaldığından emin olmak için contract testler olmazsa olmaz durumdalar. NoSQL veritabanı çözümü olarak kullandığımız MongoDB de burada üzerinde çalışma fırsatı bulduğum benim için yeni olan teknolojilerden.
Start-up olmanın getirdiği dinamiklikle veri yapımızda istediğimiz değişiklikleri hızlıca yapabiliyoruz. İlişkisel veritabanı sistemlerindeki tablolara kolon ekleme çıkarma gibi işlemlere nazaran NoSQL koleksiyonlarına yeni alanlar eklemek daha kolay yapılabiliyor. Hatta henüz collection tanımlı bile değil iken, ilk insert işleminde otomatik olarak tanımlı hale geliyor.
Şirketteki takım yapımızdan da bahsetmek istiyorum. Takımlarımız ürünün belli bölümlerinin geliştirilmesinden uçtan uca sorumlu ürün yöneticisinden frontend / backend geliştiricisine her şey dahil squad dediğimiz yapılardan oluşuyor. Bunun yanında teknik çalışanların yardımlaşmasını, bilgi alışverişini kolaylaştıran yatay yapıda takımlaşma da söz konusu. Örneğin, bir geliştirici ürünle ilgili “shipment” takımında olabildiği gibi şirketteki tüm backend geliştiricilerle birlikte “backend” takımında bulunuyor diyebiliriz.
Alışılagelmiş Inhouse çözümlerin AWS karşılıkları
İş hayatına serverless mimaride başlayanlar için olmasa da geleneksel mimariden AWS’ye geçmeyi planlayanlar için yaklaşık olarak ne neye karşılık geliyoru anlatmak istiyorum.
● Firewall çözümü olarak Amazon WAF servisini sunuyor.
● Kullanıcı yönetimini, sign-in, sign-up, token üretme, verify etme gibi standart işleri Amazon’a devretmek için AWS Cognito servisi bulunuyor.
● Servisler arası asenkron mesajlaşma için Apache Kafka, RabbitMQ gibi teknolojilerin karşılığı olarak düşünebileceğimiz AWS SNS ve SQS servisleri bulunuyor.
● Kodların versiyon takibi, CI / CD süreçleri için, Gitlab, Bitbucket, karşılığı olarak AWS CodeCommit bulunuyor. Jenkins karşılığı olarak da AWS CodePipeline ve CodeDeploy çözümleri bulunuyor.
● Veritabanı çözümleri için AWS birçok seçenek sunuyor. RDBS veya NoSQL AWS tarafından yönetilen geleneksel (PostgreSql, MongoDB vs.) db çözümleri kullanabileceğiniz gibi tamamen Amazon ürünü olan DynamoDB de işinizi görebilir.
● Spring dünyasında bir Controller’ın bir endpoint metodu AWS dünyasında Lambda denilen kendi hayat döngüsü olan, istek geldiğinde ayağa kalkan, gerektiğinde kendi kendine ölçeklenen, işi bitince tekrar kapatılan kod parçacıklarına karşılık geliyor.
● Spring’de @Scheduled ile çözdüğümüz veya cron job tanımlayarak çözdüğümüz otomatik periyodik kod çalıştırma problemine AWS Step Functions ile çözüm sunuyor.
● Logların detaylı takibi ve arama kabiliyeti için ELK (Elasticsearch Logstash Kibana) alternatifi olarak düşünebileceğimiz AWS CloudWatch servisi bulunuyor.
Infrastructure as code (IaC) yapısı
Görüldüğü gibi her probleme farklı bir servis ile çözüm sunulduğunda bu sefer de bunların bir araya getirilip helva yapılması sorunu ortaya çıkıyor. Tüm bu servisler AWS arayüzü üzerinden konfigüre edilebilir, fakat hepsine birden hakim olmak, değişiklikleri takip etmek gibi de yeni bir problem ortaya çıkarıyor. Bu sorun için de Infrastructure as code (IaC) anlayışı ortaya çıkmış. Tüm AWS çözümlerimizi kod olarak tanımlıyoruz ve Git ile versiyon takibi yapılabiliyoruz. Herhangi bir t anında tüm sistemimizi birkaç konfigürasyon değişikliği ile AWS’de başka bir ortamda veya hesapta tekrar ayağa kaldırabilir oluyoruz. IaC çözümü için AWS CDK kütüphanesi bulunuyor.
Sadece Amazon değil de diğer bulut bilişim sağlayıcılarını (örneğin Microsoft Azure) da aynı anda kullanmak isteyenler için de HashiCorp Terraform güzel bir çözüm olabilir.
Her şey toz pembe mi?
Daha fazla AWS reklamı yapmadan biraz da negatif şahsi düşüncelerime geçelim.
“‘Ne kadar az hareketli parça, o kadar iyi. Gerçekten. Mühendislik alanında bundan daha doğru bir söz henüz söylenmedi.” — Christian Cantrell
Her mühendislik kararında olduğu gibi monolitik veya mikroservis mimari tercihi de bir şeyleri bir şeylere feda etmektir. AWS’ye özgü olmamakla birlikte, mikroservis mimarinin getirdiği karmaşıklığa hazır olmak gerekiyor. Monolitik ortamda geliştirme yapmanın basitliğine alışanlar için, mikroservis’te bir kullanım senaryosu test ederken bağımlı olduğunuz n tane servisi de teste uygun hale getirme karmaşıklığına alışmak biraz zaman alabilir. Ayrıca yazılım çözümlerinde teknik olarak esnekliği negatif etkileyen konuların arasında framework bağımlılığından bahsedilirdi. Projenize eklediğiniz her 3rd party kütüphane sizi, o kütüphanenin / framework’ün öngördüğü anlayışla kodunuzu yazmaya zorlar.
Genel olarak serverless mimaride veya özel olarak AWS’de ürettiğiniz çözümlerde de yukarıda anlattığıma benzer bir bağımlılıktan bahsedebiliriz. Yazdığınız kodlar kullandığınız serverless çözümlerle etle tırnak gibi iç içe geçmekte. AWS mühendislerinin teknik tasarım kararlarına %100 uymak durumundasınız. Aksi takdirde sisteminize gelen isteklerin AWS tarafından error ile sonuçlandırıldığını görebilirsiniz. Örnek olarak, AWS Lambda’lara gelen isteklerin belirli bir süre içinde cevap dönmesi zorunluluğundan bahsedebiliriz.
Sonuç
Yeni bir projeye başlayacaksınız diyelim. Peki projeyi monolitik mi yoksa mikroservis mimaride mi kurgulayacaksınız? Trend olmanın getirdiği rüzgarla artık neredeyse tüm projelere mikroservis ile başlanıyor. Ancak mikroservis’in de beraberinde getirdiği kendine özgü problemlerin farkında olarak işe girişmekte fayda var. Ben, sektörde bu yöndeki hızlı yönelişten dolayı bu alanı da merak ediyor ve tecrübe etmek istiyordum. Yolda.com’da bu fırsatı buldum.
Ekibe yeni sayılacak bir süre önce katıldım. Ekip içi yardımlaşmanın üst düzeyde olduğu, sürekli yeni teknolojiler ve problemlere yaklaşım yöntemleri öğrenebildiğim keyifli bir çalışma ortamı olduğunu söyleyebilirim. Bu ekipten daha birçok teknik içerikli paylaşım olacağının müjdesini vererek takipte kalmanızı tavsiye ediyorum.
Güncel iş ilanlarımızı ise buradan takip edebilirsiniz.
