- "Monolith > apps > services > microservices"
- Birincisi, bu bir kural değil; sadece benim böyle düşündüğüm anlamına geliyor. Büyük ölçekli dağıtık sistemler kurmuş olan herkes bunun gerçekte bu kadar düz işlemediğini ve uyum sağlamak gerektiğini bilir
- İkincisi, aşamalar önemlidir
- 5-50 kişilik bir şirketseniz, doğrudan Monolith ile gidin
- 10 bin kişilik bir şirketseniz, yukarıdakilerin hepsine sahip olursunuz. Ama geçmişe kıyasla değişen düşüncelerimden bahsedecek olursam..
Önce tanımlar (Definition)
- monolith - xyz.com
- apps - abc.xyz.com
- services - uygulamaları/monolith'i destekler, temel altyapı, temel uyumluluk işlevleri; uygulama ekibi tarafından yazılmayabilir (altyapı tarafından bakım yapılır)
- microserivces - birkaç yüz satırlık kod, çoğu tek seferlik; kütüphane veya SDK olabilir/olmalıdır (
could/should)
Neden? : Temelde "Speed & Risk" yüzünden
- #1 Tüm geliştirme ekibinin tek bir büyük uygulama üzerinde (tüm sitenin bir Rails uygulaması olduğunu düşünün) geliştirme yapması daha kolaydır
- #2 Büyüdüğünüzde kaçınılmaz olarak sahip olacağınız dağıtık sistemler, kendi başına riskli yüzlerce mikroservis olmasa bile zaten akıl yürütmesi zor yapılardır
- #3 Tamamen mikroya giderseniz, kontrolsüz ölçeklenmeyi ele almak için yeni kavramlar eklemek zorunda kalırsınız
- #4 Özel yapım (Bespoke) altyapı servisleri veya mikroservisler, borcun en uç biçimidir. Kod da bir borçtur ama servis bunun daha da uç bir versiyonudur. Bunun ne anlama geldiğini düşünün. Bunun bir kaldıraç noktası olmasını sağlayın
- Dağıtık sistem mühendisleri tekrar eden şeylerden hoşlanmadığı için, bir şey birden fazla yerde yapılıyorsa "bunu dışarı çıkarıp bir mikroservis yapalım" diye düşünür
- Teoride bu doğrudur ve 10-20 taneye kadar sorun olmaz. Ama onlarcayı geçince veya büyük bir şirket genelinde kullanılınca, bu artık teknik değil organizasyonel bir sorun hâline gelir
- Anlattıklarım yanlış bir ikilik gibi gelebilir ama gerçekte mikroservislerin teknik zorlukları vardır ve daha da fazla organizasyonel sorun yaratırlar
Benim endişelendiğim şeyler
- #1 (İstisnai olarak CEO'nun IT kökenli olduğu durumlar dışında) altyapı her zaman öncelik sıralamasında geri planda kalır
- #2 Servis sayısı çok arttığında genellikle sahiplik ve sınır problemleri ortaya çıkar
- #3 Çok sayıdaki mikroservisi yönetebilmek için daha fazla araç devreye alınır
- #4 En önemlisi, aslında kütüphane ya da SDK olması gereken her mikroservis üretim ortamında risk yaratır
Genel olarak benim önerim
- #1 Mümkünse Monolith'i olabildiğince uzun süre koruyun
- #2 Servisleri uygulama geliştirme tarafından değil, altyapının ihtiyaçlarından başlatın
- #3 Mono'yu parçalamak zorundaysanız, küçük servisler yerine büyük uygulamalara ayırın
- #4 Her yeni uygulamayı şirket içindeki sanal bir duvar gibi düşünün
- #5 Mümkünse mikroservis yerine kütüphane tercih edin
13 yorum
Son kısımdaki endişe ve öneri bölümlerine katılıyorum.
Aslında şirketin ölçeği de hizmetin ölçeği de benzer bir bağlamda; bölmek zorunda kalınacak an mutlaka gelecektir, ama buna önceden hazırlanmak için isabetli bir muhakeme gerektiğini düşündüm.
Şirket ölçeğine göre değil, sistem ölçeğine göre değişmesi gerekmiyor mu? Ben MSA'yı yanlış mı anlamışım?
Yukarıdaki yorumlardan birinde yer alan
Sorun mikroservislerin kendisi değil, hizmetlerin kontrolsüzce genişlemesi olabilir mi?
görüşüne öncelikle katılıyorum; ayrıca şirket büyüdükçe dağıtım sorunları + branch yönetimi gibi monolitin kendi dezavantajları da fazlasıyla net ortaya çıktığı için, maliyet ve üretkenlik arasındaki trade-off'u iyi seçmek gerekiyor gibi görünüyor.
Çok güzel bir yazı. Teşekkür ederim.
Tasarım desenlerinin önemi tartışmasıyla benzer gibi geliyor bana.
Tasarım deseni denen şey, çeşitli sorunları çözme sürecinde ortaya çıkarılmış kod kalıpları sonuçta....
Nihayetinde bunlar da duruma göre, ihtiyaç doğrultusunda uyarlanıp uygulanmalı.....
Ama sanki örnek doğru cevapmış gibi, tasarım desenleri zorunluymuş gibi ona fazlasıyla kapılan insanlar zaman zaman oluyor...
Bugünlerde MSA konusunda da benzer bir durum var; ne olursa olsun MSA... diyen insanların arttığını düşünüyorum.
Bu, tavuk mu önce yumurta mı önce demek gibi geliyor.
Sorun mikroservislerin kendisi değil, hizmetlerin kontrolsüzce genişlemesi değil mi?
Uygun bir dengenin önemli olduğunu düşünüyorum.
Mikroservislere geçildiğinde, yeni özellik = yeni mikroservis sonucuna varılabilmesi nedeniyle,
zamanla yönetimin giderek daha zor hale gelmesi muhtemel gibi görünüyor.
Daha önce Segment teknik blogunda yayımlanan
Goodbye Microservicesbaşlıklı yazı aklıma geliyor.Segment de bir CDP olarak çok büyük miktarda veriyi gerçek zamanlı işlemesine rağmen, Microservices'ten Monolith yapısına geçerken bunun nedenlerini blogunda derlemişti. Bence bu yazıyla da belirli ölçüde örtüşüyor :)
https://segment.com/blog/goodbye-microservices/
Genel olarak benim düşüncemle örtüşüyor.
Şirketimizde 5 geliştirici var, bu yüzden şimdilik monolith (RubyOnRails) yaklaşımını sürdürmenin doğru olduğunu düşünüyorum.
Yukarıdaki yazıdaki gibi aynı anda 50'den fazla kişinin geliştirdiği bir proje hâline gelirse, o zaman ikinci bir monolith geliştireceğimizi sanıyorum.
5-50 kişilik bir şirketseniz, doğrudan Monolith ile gidin << burada kastedilen geliştirici sayısı değil, toplam çalışan sayısı olmalı, değil mi?
Sanırım şirket ölçeğinden bahsediyor~
Mümkünse Monolith'i olabildiğince uzun süre korumak < buna son derece katılıyorum. Ayırdıkça bakım maliyetinin artması ciddi oluyor
MSA'nın dogmalaşmasına karşı bir tepki olarak yazılmış bir metin gibi görünüyor ve bu açıdan anlamlı olduğunu düşünüyorum.