Microservices Series
12 (The Twelve) Factor App Uygun Geliştirme Nedir?
12 Factor App Nedir? Codebase, Dependencies, Config, Backing Services, Build Release Run, Processes, Port Binding, Concurrency, Disposability, Dev/Prod Parity, Logs, Admin Processes
Ölçeklenebilir SaaS uygulamalar yazabilmek için 2012 yılında Heroku’nun kurucularından Adam Wiggins tarafından ortaya atılmış bir manifestodur.
- Projeye yeni katılan geliştiricilerin ortamlarını hızlı ve ucuz maliyetli bir şekilde ortamlarını kurabilmeleri ve otomasyonlarını sağlayabilmeleri için Declerative Format’ların kullanılması
- Alttaki işletim sistemi ile Clean Contract sağlanarak, çalışan ortamlar arasında Maximum Portability (Taşınabilirlik) sağlanabilmesi
- Üzerine WebApp/SaaS uygulamalar deploy edilebilecek modern Cloud Platformları sayesinde sunucu ve sistem yöneticiliği ile uğraşmamak
- Continues Deployment ile geliştirme ve canlı ortam arasındaki farklılaşmanın engellenmesi.
FACTORS
1. Codebase
Codebase kaynak kod ve dosyaların yönetimini sağlayan araçtır. Örneğin: Git, Subversion, Mercurial vb..
Uygulamanızın dev, staging, production olsun bir tane Codebase içersinde olması. Environment ile ilgili config bilgilerinin ilgili environment ortamında bulunması.
Staging ortamına commit edilmemiş dev geliştirmeleri veya production ortamına commit edilmemiş staging geliştirmeleri olabilir. Tüm bu versiyonlara ait kodun tek bir codebase üzerinden kontrol edilebilmesi gerekmektedir.
2. Dependencies
Projenizin bağımlılıklarını, bağımlı olduğu diğer kütüphaneleri projenizin içerisine statik olarak eklememek, açık bir şekilde bir dosyada belirterek ve bir paket yöneticisinin ilgili bağımlılıkları getirmesini sağlatarak gerçekleştirmelisiniz. Bunun için farklı dillere yönelik farklı paket yöneticileri bulunuyor.
- RubyGems / Bundler (Ruby)
- PIP / PyPI (Python)
- Composer (PHP)
- NPM (Node.JS)
- Bower (JS, CSS, HTML)
- CocoaPods (Objective-C)
- Maven (Java)
- Lein (Clojure)
Bu sayede Codebase içerisindeki bir dosyada bağımlılıklarınızın ismini, versiyonunu tutmanız yeterli.
3. Config
Projenize ait konfigürasyon bilgilerini kodunuzun içerisinde statik olarak tutmayın. Çünkü test, staging, prod veya başka bir durum için ortamı klonlandığında Bu konfigürasyon bilgilerinin güncellenmesi gerekecektir. Konfigürasyon bilgileri;
- Veritabanı, MemCache ve diğer Backend servislerine erişim bilgilerini içerebilir.
- Dışarıdaki başka servislere erişim için Credentials(AWS, Twitter, Facebook vb)
- Deploy edilen hostname ile ilgili konfigürasyon bilgilerini içerebilir.
Bu tip konfigürasyon bilgilerinin env variable olarak saklanması. Kodun ortamdan bağımsız olmasını sağlayacaktır.
4. Backing Services
Arka planda çağrılan servisleri mikro-servis olarak kullanması. Bir kaynak olarak kullanılması. İlgili kaynağa erişebilmek için gerekli DNS adresinin ve Credentials bilgisinin yeterli olması. En önemli terimlerden birisi Loose Coupling olması
Bu sayede sistemin arkaplanında kullanılan servisleri kod değişikliği yapılmadan sadece konfigürasyon güncellemesi ile değiştirilebilir.
5. Build, Release Run
Build, Relase ve Run işlemlerinin birbirinden ayrılması. Deployment araçları, otomasyon araçlarının bu işleri birbirinden ayırarak tüm süreçleri oluşturması beklenir.
- Code Güncellemesi
- Build
- Release (Config bilgilerinin eklenmesi)
- Run Time Deploy’u
6. Processes
Stateless (State tutmayan) process geliştirin. State veya veri tutma ihtiyacınız var veritabanı gibi stateful backend servislerinde bu bilgileri tutun. Bu sayede 1..n Process uygulamanızı çalıştırabilirsiniz. Burada bellekte tutulan sticky session yerine bunları Redis/Memcached saklayarak servis olarak kullanmak Process sayınızı kolay bir şekilde arttırabilmenizi sağlar.
7. Port Binding
Servislerin dışarıya port binding sayesinde belli URL ve portlar üzerinden erişilebilir hale gelmesi. Bu sayede istediğiniz servise bu IP ve Portlar üzerinden erişebilirsiniz.
Müşteri Servisi https://192.162.12.16:5555
Ürün Katalog Servisi https://23.123.15.17:5000
8. Concurrency
Çalışan process ölçeklendirilme ihtiyaçlarına göre eş zamanlı şekilde tasarlanması ve duruma göre klonlanması ve restart edilebilmelidir. Bu sayede Req/Resp yük çoğaldı ise Web modülü işleme kısmında bir gecikme var is Worker modülü ölçeklendirilebilecektir (Yatay ölçeklendirme).
9. Disposibility
Servisler hızlı şekilde başlatılabilmeli ve kapatılabilmelidir. Servislerin tek kullanımlık oluşturulup yok edilebilmelidir. Bunun maliyeti oldukça düşük olmalı. Docker/Container yapıları bunlara uygun örneklerdir. Aynısı AWS Lambda ortamı içinde söyleyebiliriz.
10. Dev/Prod Paritiy
Geliştirme ve Canlı ortam arasında oluşacak boşluğu(gap) kapatmayı amaçlar. Bu boşluklar/farklılaşmalar neden ortaya çıkar ?
- Zaman Farkı: Geliştirme ortamına Push saatte bir gerçekleşirken, production ortamına Push işlemi haftalar aylar alabilir.
- Personel Farkı: Geliştirme(Dev) ve Deploy(Ops) işlemlerinin farklı kişiler tarafından yapılması, geliştirme işleminin bitmesine rağmen deploy süresini daha ileriye atabilir.
- Tools(Araçlar) : Geliştirme ve Canlı ortamda kullanılan araçların farklı olması. Örneğin geliştirme ortamında Tomcat, Canlı ortamda Weblogic kullanılması vb..
Geleneksel Uygulama ile Twelve-factor App arasındaki olması istenen farkları aşağıda listelemiş.
11. Logs
Logları dosyaya statik yazılan bir log cümleleri olarak tutmak yerine. Dağıtık sistemde event-stream oluşturularak başka servislerin bunları yakalayıp, görüntülemesi, debugging, üzerinde arama yapabilmesine izin veren Hadoop, ElasticSearch sistemlerinin kurulu olmasını bekler.
Çünkü sistemin gerçek zamanlı/geçmişe yönelik görüntülemenin en iyi yöntemi log tur.
12. Admin Processes
Tek seferlik yapılan admin ve yönetim görevlerinin scriptler ile gerçekleştirilmesi. Örneğin.
- Veritabanı migration işlemlerinin çalıştırılması
- Tek seferlik scriptlerin çalıştırılması
- Console üzerinden bazı kodların çalıştırılması
- vb..
Referanslar
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
