Mikroservis Dönüşüm Yolculuğu — E01: Mikroservis Tasarım Komitesi
Intertech’te bir uygulamanın Mikroservis yolculuğu Mikroservis Tasarım Komitesi (MSTK) ile başlar. MSTK, tasarım ve gözden geçirme olarak en az 2 defa düzenlenir.
Komitenin amaçları:
- Standardın korunması
- Tasarımların gözden geçirilmesi
- Genel mimariye uyum
- Yan teknolojilerin belirlenmesi
- Yeni özelliklerin yaygınlaştırılması
Komitenin ana katılımcıları:
- DevStudio & Kurumsal Mimari (Organizatör)
- Yazılım altyapı mimarları
- Garaj Yazılım Alan Liderleri
- Güvenlik Ekipleri
- Uygulama Yönetimi
- DevOps temsilcisi
- DBA
Bunlara ek olarak komite özelinde proje ekibi ve ilgili projenin alan ustaları dahil olur.
Geliştirme Öncesi
Komitenin yazılım yaşam döngüsündeki yerinden bahsedecek olursak, her Mikroservis projesinin geliştirme öncesi komiteye alınabilmesi için Jira proje sürecinde kontroller yapıyoruz. Mikroservis projesinin analiz adımında otomatik olarak MS tipinde paralel bir task oluşturulur ve projenin yazılım ekibine atanır. Proje ekibi hazırladığı tasarım dokümanını ekler ve DevStudio & Kurumsal Mimari ekibine atar. Aynı MS taskı projenin UAT adımı öncesi tekrar oluşur ve Gözden Geçirme Komitesi düzenlenir. Eğer proje kapsamlıysa ya da proje ekibinin danışmak istediği konular olursa sadece DevStudio & Kurumsal Mimari katılımı ile ara komiteler yapılabilir.
Tasarım Dokümanı
Bu doküman 6 ana başlıktan oluşur.
- Problem
- Bağlam
- Hedefler
- Kapsam Dışı
- Tasarım Seçenekleri
- Karar
Bu başlıkların tümü Kurumsal Mimari ekibi için önemli olsa da komitenin geneli için en önemli kısım Tasarım Seçenekleri bölümü, burada ekip farklı dizaynlar üzerinden seçenekleri sıralar ve artı/eksilerini anlatır. Komiteye getirilen örnek bir şema alttaki şekildedir:
Komite bir kontrol listesi ile mimari standartları kontrol eder. Burada henüz geliştirme başlamadığı için ana bileşenleri doğru konumlandırmak oldukça önemlidir.
Kontrol Listesi:
- Surface (Intertech’in React ile geliştirdiği Mikro Önyüz platformu)
- WebUIGateway (Surface ekranlarının Api iletişimi için JWT doğrulaması yapan GW)
- ApiGateway (Monolith uygulamalardan gelen istekleri karşılamak InterAuth kontrolleri ile karşılamak için)
- ACL (Mikroservis dönüşüm boyunca uygulamanın kendi legacy uygulaması ile haberleşmek için)
- ProxyApi (Monolith uygulamalardaki servisleri çağırmak için)
- DB (Mikroservis özelinde yeni bir DB oluşturulmuş mu?)
- Redis (Cache, Session vb yönetimler için değerlendirildi mi?)
- Elastic (aetherBusinessLogger ile ELK değerlendirildi mi?)
- AlwaysOn (ReadOnly işlemler için MsSQL AlwaysOn değerlendirildi mi?)
- EventConsumer (Event olarak oluşabilecek durumlar için değerlendirildi mi?)
Geliştirme Boyunca
Komitenin kararına göre ekip geliştirme sürecine başlar ve geliştirme boyunca takıldığı noktaları DevStudio & Kurumsal Mimari ekibi ile paylaşır, ürün kullanıcı testlerine başlamadan önce aynı doküman üzerinden Gözden Geçirme Komitesi düzenlenir ve geliştirme sürecinde çıkan farklılıklar dokümana işlenir.
Geliştirme Sonrası
Bu doküman ürüne eklenecek her MVP için güncel tutulur ve versiyonlanır. İş biriminden bir istek geldiğinde açılan Jira MVP kaydı için yine otomatik MS task’ı oluşacaktır ve ekip güncel teknik tasarım dokümanını güncelleyerek yeni bir komite talebinde bulunabilir. MVP ile gelen talep tasarıma etki etmiyorsa sadece DevStudio ile görüşülerek komite yapılmadan ilerlenebilir, bu durumda mevcut teknik tasarım dokümanı MVP MS Task’ına eklenir.
Bir sonraki yazı, bir Mikroservis uygulamasını nasıl oluşturuyor ve geliştiriyoruz, kullanabileceğimiz yardımcı kütüphaneler ve yazılım geliştirme prensiplerimiz hakkında olacak.
Okuduğunuz için teşekkürler.
