Monolith v/s Microservices dünyasında devam eden pek çok tartışma var. İlk kariyerimin çoğu yekpare yapılar inşa etmekle geçti ve elbette hizmet odaklı mimariler kök salmaya başladıkça, onları büyük bir başarı ölçüsüyle benimsedik.

Benim deneyimim

Burada havalı görünmeme ve insanlara Conway yasası gibi şeyler söylememe gerek yok. Sınırlı deneyimim bana, belirli bir modülden açıkça sorumlu olan bireylere, küçük ekiplere ve büyük ekiplere sahip olduğumuzu öğretti (isterseniz buna hizmet diyebilirsiniz). Sorumluluklarının bir parçası olarak, aşağıdakileri yapmak zorundaydılar:

• sahip olmak zorundaydılar
• sürdürmek zorundaydılar
• Bu konuda iletişim kurmaları gerekiyordu.
• Sözleşmeleri yerine getiren birlikte çalışabilir API'ler oluşturun
• Kendi yazılımlarını test edin
• Entegrasyon testlerine dikkat edin
• Öğelerini ortamlarda nasıl konuşlandıracaklarını belirtebilme
• Bir aramanın hatalarını ayıklayın ve daha da önemlisi genel şemada izleyin.

Monolith veya Microservices ile ilgili değil

Gerçekten sihirli değnek yok. Mikro hizmetlere gitmenin veya bir monolitle gitmenin kesin bir açısı yoktur. Şu ya da bu şekilde gitmekten bahseden herhangi birinin sizi etkilemek gibi bir niyeti yok ama saygısızlık etmek istemem ama her organizasyon ve onun geliştirme ekipleri farklı olacak, gereksinimleri farklı olacak, nasıl gelişmeleri ya da desteklenmeleri gerektiği yeni hizmetler/cihazlar farklı olacaktır. Büyük bir şirketin veya etkileyicinin herhangi bir görüşünü körü körüne benimsemeden önce kendi kuruluşunuzu anlamada sürücü koltuğunda olmanız gerekecek.

Hiçbir kuruluş, insan ekiplerini yönetme, ona bir düzen getirme, otomasyon, test etme, ekiplere araç seçme özgürlüğü ve esnekliği verirken aynı zamanda onları disiplinli tutma ve daha fazlasını yapma ihtiyacını hiçbir noktada hafife almamalıdır.

Monolitler ve mikro hizmetler konusunu bir an için bir kenara bırakın. Ekip iletişimi, hiyerarşiler, karar verme, yazılım mühendisliği disiplini ve hijyen, test kapsamı, otomasyon, özerklik ve daha fazlası gibi temel konuları ele alıyor musunuz? Bunu bir an için düşünün.

Ne tavsiye ederim?

Kitabımda, bir uygulamaya bütünüyle bakmayı tercih ederim ve temelde neden ilk etapta var? Bu yanıtları aldıktan sonra, kullanıcıların uygulamanızla etkileşimde bulunduğu kullanım durumlarının veya müşteri kullanıcı yolculuklarının neler olduğuna bakın. Benim için, sonunda aşağıdakilere gelir:

1. Uygulamanızı çeşitli ortamlarda geliştirmek ve dağıtmak ve sürümleri bunlar arasında taşıyabilmek için verimli bir sürece (tamamen otomatik olsun veya olmasın) ihtiyacınız var.
2. Kaynak kodu değişikliklerinizi üretimde dağıtılanlara göre izlemek için verimli bir sürece ihtiyacınız var.
3. Son olarak ve en önemlisi, bir bok olduğunda ve ne olacağı, neler olup bittiğini izleme ve izleme, soruna neden olan bileşeni bulma, etkin bir şekilde hata ayıklama ve temel nedeni anlama ve ardından piyasaya sürmek için bir sürece sahip olma beceriniz var mı? etkilenen kullanıcıları azaltmak için değişiklikler.

Şimdi, kuruluşunuzun kısıtlamaları göz önüne alındığında, yekpare yapılar ve/veya mikro hizmetler mimarisi bunu ele almanıza yardımcı olabilirse, bununla devam edin. Siz Google, Facebook, Microsoft, Amazon değilsiniz ve onlar da siz değilsiniz. Kendinizi daha akıllı, çevik veya bu özelliklerden herhangi biri olabilecek diğer kuruluşlarla hemen karşılaştırmanıza bile gerek yok.

Yapmanız gereken tek şey, gerçek bir ruhla, organizasyonunuzda tartışmaya açık ve DORA'nın tavsiyelerini ölçmeye başlayan sağlıklı bir kültür oluşturmaktır :

• Hizmeti Geri Yükleme Zamanı
• Başarısızlık Oranını Değiştir
• Değişiklikler için Teslim Süresi
• Dağıtım Sıklığı.

Son sözüm, yazılımınızı verimli bir şekilde sunmanızı sağlayan şeylere (maliyet, işlemler ve her şey dahil) odaklanmaktır. Diğer her şey bir 21:00 Haber tartışması gibidir.