ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

12factor apps

•Download as PPTX, PDF•
•
Dilaver Demirel
Dilaver Demirel

12 faktör nedir ,uygulamalarda neden 12 factörü sağlamalıyız.

1 of 16
Download to read offline
ï‚—The Twelve-Factor App ddemirel / 24.07.2018 https://12factor.net
Nedir? Ölçeklenebilir cloud tabanlı/SaaS uygulamalar geliştirebilmek için 2012 yılında Heroku’nun kurucularından olan Adam Wiggins tarafından ortaya atılmış bir manifestodur. On iki faktör uygulaması herhangi bir programlama dili ile yazılmış uygulamalara uygulanabilir. «Bizim motivasyonumuz, modern uygulama geliştirmesinde gördüğümüz bazı sistemik problemlerin farkındalığını arttırmak, terimlerle birlikte geniş kavramsal çözüm setleri sağlamak ve bu problemleri tartışmak için ortak bir kelime sunmakdır.» https://12factor.net
Amaç? • 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 direktiflerin kullanılması • Çalışma ortamları arasında maksimum taşınabilirlik sunan temel işletim sistemi ile şifresiz iletişim vardır • Üzerine WebApp/SaaS uygulamalar deploy edilebilecek modern Cloud Platformları sayesinde sunucu ve sistem yöneticiliği ile uğraşmamak • İşlem, mimari veya geliştirme uygulamalarında önemli değişiklikler olmaksızın ölçekleyebilmek
12 Factor Apps
1. Codebase • Uygulamanızın dev, pre-prod, production için bir tane Codebase olması. Environment ile ilgili config bilgilerinin ilgili environment ortamında bulunması . • Pre-prod ortamına commit edilmemiş dev geliştirmeleri veya production ortamına commit edilmemiş pre-prod 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 gömerek değilde, 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) • Packagist / 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 konfigurasyon bilgilerini kodunuzun içerisinde statik olarak tutmayın. Çünkü test, preprod, prod veya başka bir durum için ortamı klonlandığında bu konfigurasyon bilgilerinin güncellenmesi gerekecektir. Konfigurasyon 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 konfigurasyon bilgilerini içerebilir. • Bu tip configurasyon bilgilerinin env variable olarak saklanması. Kodun ortamdan bağımsız olmasını sağlayacaktır.
4. Backing Services • Arka planda çağrılan servisleri microservis 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 arka planında kullanılan servisleri kod değişikliği yapılmadan sadece konfigurasyon güncellemesi 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. 1. Code Güncellemesi 2. Build 3. Release (Config bilgilerinin eklenemesi) 4. Run Time Deploy’u
6. Processes • Stateless (State tutmayan) process’ler 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. • Bu sayede servislerinizi kolayca scale edebilirsiniz
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. • Servislerin belirli kurallara göre dışarıya açılıp açılmayacağını belirleyedek erişim güvenliği de sağlanmış olur Müşteri Servisi https://192.162.12.16:5555 Ürün Katalog Servisi https://23.123.15.17:5000
8. Concurrency • Çalışan processlerin ö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ü, eğerki işleme kısmında bir gecikme var is Worker modülü ölçeklendiribilecektir (Yatay ölçeklendirme).
9. Disposability • Hızlı şekilde başlatılabilmeli ve hızlı şekilde kapatılabilmeli. Servislerin tek kullanımlık oluşturulup yok edilebilmeli. Bunun maliyeti oldukça düşük olmalı. Dockerlar bunun için uygun örnekler . AWS Lambdalarda bunun için iyi bir örnek • Örn. FaaS(Function as a Service, Serverless)
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-streamleri oluşturularak başka servislerin bunları yakalayıp, görüntülemesi, debugging, üzerinde arama yapılamabilmesine 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 logları kullanmaktır.
12. Admin Processes • Tek seferlik yapılan admin ve yönetim görevlerinin gerçekleştirilmesi. • Veritabanı migrationlarının çalıştırılması • Tek seferlik scriptlerin çalıştırılması • Console üzerinden bazı kodların çalıştırılması • vb..

More Related Content

12factor apps

  • 1. ï‚—The Twelve-Factor App ddemirel / 24.07.2018 https://12factor.net
  • 2. Nedir? Ölçeklenebilir cloud tabanlı/SaaS uygulamalar geliÅŸtirebilmek için 2012 yılında Heroku’nun kurucularından olan Adam Wiggins tarafından ortaya atılmış bir manifestodur. On iki faktör uygulaması herhangi bir programlama dili ile yazılmış uygulamalara uygulanabilir. «Bizim motivasyonumuz, modern uygulama geliÅŸtirmesinde gördüğümüz bazı sistemik problemlerin farkındalığını arttırmak, terimlerle birlikte geniÅŸ kavramsal çözüm setleri saÄŸlamak ve bu problemleri tartışmak için ortak bir kelime sunmakdır.» https://12factor.net
  • 3. Amaç? • 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 direktiflerin kullanılması • Çalışma ortamları arasında maksimum taşınabilirlik sunan temel iÅŸletim sistemi ile ÅŸifresiz iletiÅŸim vardır • Ãœzerine WebApp/SaaS uygulamalar deploy edilebilecek modern Cloud Platformları sayesinde sunucu ve sistem yöneticiliÄŸi ile uÄŸraÅŸmamak • Ä°ÅŸlem, mimari veya geliÅŸtirme uygulamalarında önemli deÄŸiÅŸiklikler olmaksızın ölçekleyebilmek
  • 5. 1. Codebase • Uygulamanızın dev, pre-prod, production için bir tane Codebase olması. Environment ile ilgili config bilgilerinin ilgili environment ortamında bulunması . • Pre-prod ortamına commit edilmemiÅŸ dev geliÅŸtirmeleri veya production ortamına commit edilmemiÅŸ pre-prod geliÅŸtirmeleri olabilir. Tüm bu versiyonlara ait kodun tek bir codebase üzerinden kontrol edilebilmesi gerekmektedir.
  • 6. 2. Dependencies • Projenizin bağımlılıklarını, bağımlı olduÄŸu diÄŸer kütüphaneleri projenizin içerisine statik olarak gömerek deÄŸilde, 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) • Packagist / 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.
  • 7. 3. Config • Projenize ait konfigurasyon bilgilerini kodunuzun içerisinde statik olarak tutmayın. Çünkü test, preprod, prod veya baÅŸka bir durum için ortamı klonlandığında bu konfigurasyon bilgilerinin güncellenmesi gerekecektir. Konfigurasyon 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 konfigurasyon bilgilerini içerebilir. • Bu tip configurasyon bilgilerinin env variable olarak saklanması. Kodun ortamdan bağımsız olmasını saÄŸlayacaktır.
  • 8. 4. Backing Services • Arka planda çaÄŸrılan servisleri microservis 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 arka planında kullanılan servisleri kod deÄŸiÅŸikliÄŸi yapılmadan sadece konfigurasyon güncellemesi deÄŸiÅŸtirilebilir.
  • 9. 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. 1. Code Güncellemesi 2. Build 3. Release (Config bilgilerinin eklenemesi) 4. Run Time Deploy’u
  • 10. 6. Processes • Stateless (State tutmayan) process’ler 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. • Bu sayede servislerinizi kolayca scale edebilirsiniz
  • 11. 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. • Servislerin belirli kurallara göre dışarıya açılıp açılmayacağını belirleyedek eriÅŸim güvenliÄŸi de saÄŸlanmış olur Müşteri Servisi https://192.162.12.16:5555 Ãœrün Katalog Servisi https://23.123.15.17:5000
  • 12. 8. Concurrency • Çalışan processlerin ö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ü, eÄŸerki iÅŸleme kısmında bir gecikme var is Worker modülü ölçeklendiribilecektir (Yatay ölçeklendirme).
  • 13. 9. Disposability • Hızlı ÅŸekilde baÅŸlatılabilmeli ve hızlı ÅŸekilde kapatılabilmeli. Servislerin tek kullanımlık oluÅŸturulup yok edilebilmeli. Bunun maliyeti oldukça düşük olmalı. Dockerlar bunun için uygun örnekler . AWS Lambdalarda bunun için iyi bir örnek • Örn. FaaS(Function as a Service, Serverless)
  • 14. 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ÅŸ.
  • 15. 11. Logs • Logları dosyaya statik yazılan bir log cümleleri olarak tutmak yerine. Dağıtık sistemde event-streamleri oluÅŸturularak baÅŸka servislerin bunları yakalayıp, görüntülemesi, debugging, üzerinde arama yapılamabilmesine 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 logları kullanmaktır.
  • 16. 12. Admin Processes • Tek seferlik yapılan admin ve yönetim görevlerinin gerçekleÅŸtirilmesi. • Veritabanı migrationlarının çalıştırılması • Tek seferlik scriptlerin çalıştırılması • Console üzerinden bazı kodların çalıştırılması • vb..