Duyuru
Yaklaşık bir hafta önce hakkında birçok geri bildirim aldığım bir blog yazısı yazdım: “Mükemmel (mikro)hizmet mimarisi için 12 kural”. Bu belgede, son yıllarda Native Web GmbH'de mikro hizmetlerin konsepti, tasarımı ve geliştirilmesi konusunda bizim için etkili olduğu kanıtlanmış on iki kuralı sundum. Ayrıca çok açık bir şekilde şunu da söyledim: “Kilometreniz değişebilir”, yani bu kuralların geçerli olduğu gerçeği Biz kanıtlanmış olması bunların size, ekibinize ve ihtiyaçlarınıza 1:1 aktarılabileceği anlamına gelmez.
Ayrıca mikro hizmetlerin tek gerçek mimari yaklaşım olduğunu iddia etmedim. Ancak mikro hizmet mimarisiyle ilgili bir blog yazısında, doğal olarak metnin öncelikle mikro hizmetlerin fikri, tasarımı ve geliştirilmesiyle ilgilenen kişiler veya en azından gelecekte bunlarla ilgilenecek kişiler tarafından okunacağını varsayıyorum.
Dikkat dikkat! Lütfen mikro hizmetlerden uzak durun!
Bu nedenle yorumların yaklaşık yarısının – burada Haberler Developer'da, YouTube'da, e-posta yoluyla veya kişisel bir görüşmede – mikro hizmetlerin kullanımını şu anlamda sorgulamasına şaşırdım: evet, her şeyi yapabilirsiniz, ancak her şeyden önce Mikro hizmetlerin iyi bir fikir olup olmadığını kendinize dikkatlice sormalısınız. Şaşırdım çünkü bir yandan mimari bir prensibin uygunluğunun önceden kontrol edilmesi gerektiğinin açık olduğunu düşünüyorum, diğer yandan bu sorunun blog yazısının konusu olmadığını düşünüyorum.
Önerilen editoryal içerik
İzniniz doğrultusunda harici bir YouTube videosu (Google Ireland Limited) buraya yüklenecektir.
Her zaman YouTube videolarını yükle
YouTube videosunu şimdi indirin
Mikro hizmetler neden projenizi mahvedebilir?
Görünüşe göre mikro hizmetlerin kullanımına karşı uyarmak gerekiyor çünkü insanlar onlarla “zaten kötü deneyimler yaşamış”. Aynı durumun monolitler, istemci-sunucu veya eşler arası gibi diğer mimari yaklaşımlar için de geçerli olduğu sıklıkla gözden kaçırılıyor. Mikro hizmetlerden söz edildiğinde bu tepkinin çok sık görülmesini ilginç buluyorum. İkimizin de mikro hizmetlerle ilgili kötü deneyimler yaşadığını inkar etmek istemiyorum – konu mikro hizmetler olduğunda bunun bu kadar hararetle vurgulanmasına şaşırdım.
Bu nedenle mikro hizmetlerin ne zaman iyi bir fikir, ne zaman kötü bir fikir olduğu sorusunu sormanın anlamlı olabileceğini düşündüm. Başka bir deyişle: Bir projenin aslında başarısızlıkla sonuçlanmaması için mikro hizmetlere güvenmeden önce hangi hususları düşünmeye değer?
Ve her durumda, Amazon'un bile artık mikro hizmetler olmadan idare edeceğini iddia etmeden önce: Bu söylenti hakkında bir süre önce zaten yorum yapmıştım. Bu iddiayı desteklemek istiyorsanız, “Mikro hizmetler aptalca mı diyor Amazon?” videosunu izleyin. İLE.
Konu no. 1: Mimari karmaşıklık
Şimdi mikro hizmetlere karşı sıklıkla bahsedilen ilk argümana, yani mimarinin önemli ölçüde daha karmaşık olmasına geliyoruz. Tanım gereği mikro hizmetler dağıtılmış bir mimaridir, dolayısıyla hizmet tabanlı bir uygulama da dağıtılmış bir sistemdir. Amerikalı bilgisayar bilimcisi Andrew S. Tanenbaum böyle bir sistemi şu şekilde tanımladı:
“Dağıtılmış sistem, kendilerini kullanıcıya tek bir sistem olarak sunan bağımsız bilgisayarlar topluluğudur.”
Aslında bu tanımın mizahi bir versiyonu da var:
“Dağıtılmış sistem, varlığından haberdar olmadığınız veya bir şey için önemli olmadığını bilmediğiniz bir bilgisayar bozulduğu için yapması gerekeni yapmayan bir sistemdir.”
Ancak şaka bir yana: Dağıtılmış sistemlerin teknik olarak dağıtılmamış sistemlerden daha karmaşık olduğu açıktır. Bu esas olarak ilgili taraflar arasındaki iletişim sorunlarıyla, yani tutarlılık, senkronizasyon, kullanılabilirlik vb. konularla ilgilidir.
Bu bağlam aynı zamanda (basit bir ifadeyle) şunu ifade eden CAP teoremini de içerir: Dağıtılmış bir sistemde bir ağ arızası meydana gelirse ve bu bir bölümlemeye (“P”ye karşılık gelir) neden olursa, o zaman bunu isteyip istemeyeceklerini seçebilirsiniz. tutarlılığı (yani “C”) veya kullanılabilirliği (yani “Kullanılabilirlik” anlamına gelen “A”) korumak için. İkisi bir arada mümkün değil.
Bu, dağıtılmış sistemlerde tutarlılığı ve kullanılabilirliği nasıl yöneteceğiniz konusunda daha fazla düşünmeniz gerektiği anlamına gelir; bu da çok fazla bilgi ve deneyim gerektirir. Ancak dağıtılmış bir sistem için her şeyden önce bir şeye ihtiyacınız vardır: her şeyden önce, bir sistemi neden dağıtılmış bir sistem olarak tasarlamak istediğinize dair iyi bir neden. Bunu “ilginç göründüğü” veya “ilginç göründüğü” için yapmamalısınız.
Bir sistemi dağıtılmış bir sistem olarak tasarlamayı istemenin muhtemelen ana nedeni (ve bu aynı zamanda Andrew S. Tanenbaum'un tanımında da vardır), teknik, organizasyonel ve operasyonel açıdan, özellikle de bireysel parçalar arasında yüksek düzeyde bir bağımsızlığın aranmasıdır. bölüm teknik açıdan. Dahası, sıklıkla bir teknolojinin sistemle alakalı olmasını istemediğiniz, mikro hizmetlerin daha fazla esneklik ve daha iyi uyarlanabilirlik sağlayacağı, dağıtılmış bir sistemi daha hedefe yönelik bir şekilde ölçeklendirebileceğiniz vb. söylenir, ancak bağımsızlık aslında dağıtılmış sistemlerin arkasındaki gücün itici gücü. Ve eğer ihtiyaç yoksa, daha merkezi bir yaklaşım büyük olasılıkla çok daha uygundur.
Bu nedenle kendimize şu soruyu sormalıyız: Teknik, organizasyonel ve hepsinden önemlisi mesleki bağımsızlığa ihtiyacınız var mı?
Konu no. 2: dağıtım ve altyapı
Mikro hizmetlere karşı sıklıkla bahsedilen ikinci argümana, yani dağıtım ve altyapıya geçelim. Mikro hizmetlerin daha karmaşık uygulamaları içerdiği açıktır, bunun nedeni kısmen uygulanacak daha fazla şeyin olmasıdır. Elbette, tek bir sunucuda tek bir örnekle çalışan basit bir monolitin XCOPY dağıtımı önemli ölçüde daha basittir.
Ancak mikro hizmetlerin uygulanması, uygulamadan bağımsız olarak aslında her zaman benzer şekilde çalışır. Bu, “kullanıma hazır” teknik bilgiyi kolayca satın alabileceğiniz anlamına gelir. Çok fazla deneme yapmanıza veya çok fazla şey keşfetmenize gerek yok; yalnızca bunu daha önce yapmış ve ilgili teknolojilere aşina birine ihtiyacınız var. Öncelikle konteynerler, Docker ve Kubernetes.
Şahsen ben bu argümana pek ikna olmadım, çünkü evet, karmaşıklık daha büyük, ancak gözle görülür derecede daha büyük değil – ve bunun karşılığında bireysel hizmetlerin teknik özelliklerinde çok daha düşük bir karmaşıklık düzeyi elde ediyorum. Bu, önemli ölçüde daha küçük ve daha yönetilebilir olduğundan her bir hizmetin geliştirilmesinin daha kolay hale geldiği anlamına gelir. Ve bu tam olarak hemen satın alamayacağım nokta olduğundan, buradaki tasarruflar dağıtım sırasında maruz kalacağım potansiyel ek maliyetlerden çok daha değerlidir. Çünkü evet, bir yandan basit, standart ve hep aynı olan bir görev biraz daha karmaşık hale gelirken, diğer yandan zaten zor, zahmetli, zaman alıcı ve bireysel olan şeyler için çok daha az karmaşıklık elde edersiniz. Ve kişisel olarak bana göre bu gerçekten iyi bir anlaşma gibi görünüyor.
Bu karşı argüman elbette sizin konteynırlaştırma, Docker, Kubernetes & Co. konularında bilgi sahibi olduğunuz varsayımına dayanmaktadır. Bugün hala çıplak metal üzerinde kabuk komut dosyaları kullanan herkes, mikro hizmetleri verimli bir şekilde dağıtmakta zorluk çekecektir. Ancak deneyimler bunun diğer tüm istihdam türleri için de geçerli olduğunu göstermektedir. Konteynerizasyon ve benzeri konular siz ve ekibiniz için hâlâ yeni bir alansa, o zaman bu, en azından web ve bulut endüstrisinde çalışıyorsanız, mümkün olan en kısa sürede değiştirmeniz gereken bir şeydir. Başlamak için, bazı devam filmleri ve Kubernetes'te ayrı bir derin dalışı da olan Docker'a ücretsiz derin dalışımızı önerebilirim.
Yaklaşık bir hafta önce hakkında birçok geri bildirim aldığım bir blog yazısı yazdım: “Mükemmel (mikro)hizmet mimarisi için 12 kural”. Bu belgede, son yıllarda Native Web GmbH'de mikro hizmetlerin konsepti, tasarımı ve geliştirilmesi konusunda bizim için etkili olduğu kanıtlanmış on iki kuralı sundum. Ayrıca çok açık bir şekilde şunu da söyledim: “Kilometreniz değişebilir”, yani bu kuralların geçerli olduğu gerçeği Biz kanıtlanmış olması bunların size, ekibinize ve ihtiyaçlarınıza 1:1 aktarılabileceği anlamına gelmez.
Ayrıca mikro hizmetlerin tek gerçek mimari yaklaşım olduğunu iddia etmedim. Ancak mikro hizmet mimarisiyle ilgili bir blog yazısında, doğal olarak metnin öncelikle mikro hizmetlerin fikri, tasarımı ve geliştirilmesiyle ilgilenen kişiler veya en azından gelecekte bunlarla ilgilenecek kişiler tarafından okunacağını varsayıyorum.
Dikkat dikkat! Lütfen mikro hizmetlerden uzak durun!
Bu nedenle yorumların yaklaşık yarısının – burada Haberler Developer'da, YouTube'da, e-posta yoluyla veya kişisel bir görüşmede – mikro hizmetlerin kullanımını şu anlamda sorgulamasına şaşırdım: evet, her şeyi yapabilirsiniz, ancak her şeyden önce Mikro hizmetlerin iyi bir fikir olup olmadığını kendinize dikkatlice sormalısınız. Şaşırdım çünkü bir yandan mimari bir prensibin uygunluğunun önceden kontrol edilmesi gerektiğinin açık olduğunu düşünüyorum, diğer yandan bu sorunun blog yazısının konusu olmadığını düşünüyorum.
Önerilen editoryal içerik
İzniniz doğrultusunda harici bir YouTube videosu (Google Ireland Limited) buraya yüklenecektir.
Her zaman YouTube videolarını yükle
YouTube videosunu şimdi indirin
Mikro hizmetler neden projenizi mahvedebilir?
Görünüşe göre mikro hizmetlerin kullanımına karşı uyarmak gerekiyor çünkü insanlar onlarla “zaten kötü deneyimler yaşamış”. Aynı durumun monolitler, istemci-sunucu veya eşler arası gibi diğer mimari yaklaşımlar için de geçerli olduğu sıklıkla gözden kaçırılıyor. Mikro hizmetlerden söz edildiğinde bu tepkinin çok sık görülmesini ilginç buluyorum. İkimizin de mikro hizmetlerle ilgili kötü deneyimler yaşadığını inkar etmek istemiyorum – konu mikro hizmetler olduğunda bunun bu kadar hararetle vurgulanmasına şaşırdım.
Bu nedenle mikro hizmetlerin ne zaman iyi bir fikir, ne zaman kötü bir fikir olduğu sorusunu sormanın anlamlı olabileceğini düşündüm. Başka bir deyişle: Bir projenin aslında başarısızlıkla sonuçlanmaması için mikro hizmetlere güvenmeden önce hangi hususları düşünmeye değer?
Ve her durumda, Amazon'un bile artık mikro hizmetler olmadan idare edeceğini iddia etmeden önce: Bu söylenti hakkında bir süre önce zaten yorum yapmıştım. Bu iddiayı desteklemek istiyorsanız, “Mikro hizmetler aptalca mı diyor Amazon?” videosunu izleyin. İLE.
Konu no. 1: Mimari karmaşıklık
Şimdi mikro hizmetlere karşı sıklıkla bahsedilen ilk argümana, yani mimarinin önemli ölçüde daha karmaşık olmasına geliyoruz. Tanım gereği mikro hizmetler dağıtılmış bir mimaridir, dolayısıyla hizmet tabanlı bir uygulama da dağıtılmış bir sistemdir. Amerikalı bilgisayar bilimcisi Andrew S. Tanenbaum böyle bir sistemi şu şekilde tanımladı:
“Dağıtılmış sistem, kendilerini kullanıcıya tek bir sistem olarak sunan bağımsız bilgisayarlar topluluğudur.”
Aslında bu tanımın mizahi bir versiyonu da var:
“Dağıtılmış sistem, varlığından haberdar olmadığınız veya bir şey için önemli olmadığını bilmediğiniz bir bilgisayar bozulduğu için yapması gerekeni yapmayan bir sistemdir.”
Ancak şaka bir yana: Dağıtılmış sistemlerin teknik olarak dağıtılmamış sistemlerden daha karmaşık olduğu açıktır. Bu esas olarak ilgili taraflar arasındaki iletişim sorunlarıyla, yani tutarlılık, senkronizasyon, kullanılabilirlik vb. konularla ilgilidir.
Bu bağlam aynı zamanda (basit bir ifadeyle) şunu ifade eden CAP teoremini de içerir: Dağıtılmış bir sistemde bir ağ arızası meydana gelirse ve bu bir bölümlemeye (“P”ye karşılık gelir) neden olursa, o zaman bunu isteyip istemeyeceklerini seçebilirsiniz. tutarlılığı (yani “C”) veya kullanılabilirliği (yani “Kullanılabilirlik” anlamına gelen “A”) korumak için. İkisi bir arada mümkün değil.
Bu, dağıtılmış sistemlerde tutarlılığı ve kullanılabilirliği nasıl yöneteceğiniz konusunda daha fazla düşünmeniz gerektiği anlamına gelir; bu da çok fazla bilgi ve deneyim gerektirir. Ancak dağıtılmış bir sistem için her şeyden önce bir şeye ihtiyacınız vardır: her şeyden önce, bir sistemi neden dağıtılmış bir sistem olarak tasarlamak istediğinize dair iyi bir neden. Bunu “ilginç göründüğü” veya “ilginç göründüğü” için yapmamalısınız.
Bir sistemi dağıtılmış bir sistem olarak tasarlamayı istemenin muhtemelen ana nedeni (ve bu aynı zamanda Andrew S. Tanenbaum'un tanımında da vardır), teknik, organizasyonel ve operasyonel açıdan, özellikle de bireysel parçalar arasında yüksek düzeyde bir bağımsızlığın aranmasıdır. bölüm teknik açıdan. Dahası, sıklıkla bir teknolojinin sistemle alakalı olmasını istemediğiniz, mikro hizmetlerin daha fazla esneklik ve daha iyi uyarlanabilirlik sağlayacağı, dağıtılmış bir sistemi daha hedefe yönelik bir şekilde ölçeklendirebileceğiniz vb. söylenir, ancak bağımsızlık aslında dağıtılmış sistemlerin arkasındaki gücün itici gücü. Ve eğer ihtiyaç yoksa, daha merkezi bir yaklaşım büyük olasılıkla çok daha uygundur.
Bu nedenle kendimize şu soruyu sormalıyız: Teknik, organizasyonel ve hepsinden önemlisi mesleki bağımsızlığa ihtiyacınız var mı?
Konu no. 2: dağıtım ve altyapı
Mikro hizmetlere karşı sıklıkla bahsedilen ikinci argümana, yani dağıtım ve altyapıya geçelim. Mikro hizmetlerin daha karmaşık uygulamaları içerdiği açıktır, bunun nedeni kısmen uygulanacak daha fazla şeyin olmasıdır. Elbette, tek bir sunucuda tek bir örnekle çalışan basit bir monolitin XCOPY dağıtımı önemli ölçüde daha basittir.
Ancak mikro hizmetlerin uygulanması, uygulamadan bağımsız olarak aslında her zaman benzer şekilde çalışır. Bu, “kullanıma hazır” teknik bilgiyi kolayca satın alabileceğiniz anlamına gelir. Çok fazla deneme yapmanıza veya çok fazla şey keşfetmenize gerek yok; yalnızca bunu daha önce yapmış ve ilgili teknolojilere aşina birine ihtiyacınız var. Öncelikle konteynerler, Docker ve Kubernetes.
Şahsen ben bu argümana pek ikna olmadım, çünkü evet, karmaşıklık daha büyük, ancak gözle görülür derecede daha büyük değil – ve bunun karşılığında bireysel hizmetlerin teknik özelliklerinde çok daha düşük bir karmaşıklık düzeyi elde ediyorum. Bu, önemli ölçüde daha küçük ve daha yönetilebilir olduğundan her bir hizmetin geliştirilmesinin daha kolay hale geldiği anlamına gelir. Ve bu tam olarak hemen satın alamayacağım nokta olduğundan, buradaki tasarruflar dağıtım sırasında maruz kalacağım potansiyel ek maliyetlerden çok daha değerlidir. Çünkü evet, bir yandan basit, standart ve hep aynı olan bir görev biraz daha karmaşık hale gelirken, diğer yandan zaten zor, zahmetli, zaman alıcı ve bireysel olan şeyler için çok daha az karmaşıklık elde edersiniz. Ve kişisel olarak bana göre bu gerçekten iyi bir anlaşma gibi görünüyor.
Bu karşı argüman elbette sizin konteynırlaştırma, Docker, Kubernetes & Co. konularında bilgi sahibi olduğunuz varsayımına dayanmaktadır. Bugün hala çıplak metal üzerinde kabuk komut dosyaları kullanan herkes, mikro hizmetleri verimli bir şekilde dağıtmakta zorluk çekecektir. Ancak deneyimler bunun diğer tüm istihdam türleri için de geçerli olduğunu göstermektedir. Konteynerizasyon ve benzeri konular siz ve ekibiniz için hâlâ yeni bir alansa, o zaman bu, en azından web ve bulut endüstrisinde çalışıyorsanız, mümkün olan en kısa sürede değiştirmeniz gereken bir şeydir. Başlamak için, bazı devam filmleri ve Kubernetes'te ayrı bir derin dalışı da olan Docker'a ücretsiz derin dalışımızı önerebilirim.