46 puan yazan xguru 2024-03-11 | 9 yorum | WhatsApp'ta paylaş
  • Wave, 70 mühendise sahip 1,7 milyar dolarlık (2,3 trilyon won) bir şirket (Afrika için mobil bankacılık hizmeti sunuyor)
  • Postgres tabanlı bir Python monoliti olan standart bir CRUD uygulaması mimarisine sahip
  • Basit bir mimariyle başlayıp sorunları karmaşıklığı en aza indirerek çözdükleri için, mühendisler kullanıcıya değer sunan işlere odaklanabildi
  • Stackoverflow, tek parça yapıyı (monolith) ölçekleyerek 1,8 milyar dolara satın alınacak kadar başarılı biçimde büyüdü

Basit mimarinin verimliliğine rağmen medyanın çoğu karmaşık mimarileri seviyor

  • Teknik konferanslarda karmaşık mikroservis tabanlı mimariler hakkında çok sayıda sunum var, ancak basit monolitler hakkında sunum yok
  • Birçok şirket, küçük ölçekli uygulamalar olmasına rağmen karmaşık teknolojileri taklit ediyor ve bununla konferanslarda ve HN'de ilgi görüyor
  • Kullandığımız mimari o kadar basit ki mimari diyagram çizmeye bile gerek yok

Basitliği korumanın yolları

  • Wave senkron Python kullanıyor; bu da sunucu sürecinin I/O beklerken bloklandığı anlamına geliyor
  • Eventlet gibi asenkron framework'leri denediler, ancak çok fazla hata olduğu için bunun maliyetinin operasyonel acıya değmeyeceğine karar verdiler
  • Karmaşıklığı artırmak yerine, uzun çalışma süresi gerektiren işleri kuyruklara ayırarak işliyorlar
  • Veri yerleşimi düzenlemelerine uymak için bazı ülkelerde şirket içinde veri merkezleri işletmek gerekiyor
    • Senegal/Fildişi Sahili buluttaydı, ancak Uganda ve diğer bazı ülkeler düzenlemeler nedeniyle on-premise gerektiriyordu
    • Bu gibi durumlarda basit bir mimari, karmaşık bir mimariye göre çok daha kolay

Satın almak yerine inşa etmek

  • Küçük bir ekip oldukları için başlangıçta yazılım satın almayı tercih ettiler, ancak kritik hataları çözemeyen durumlarda kendi araçlarını geliştirdiler
  • Kendi araçlarını inşa etmek, üstlenmek istemedikleri bir karmaşıklık; ancak bazı ürün kategorilerinde oldukça kapsamlı araştırmalardan sonra bile kendilerine uygun ürün sunabilecek bir tedarikçi bulamadılar
  • Temel yetkinliklerin dışında da bazen kendi araçlarını geliştirmek ve kurum içi uzmanlığı sürdürmek gerekiyor

Yeniden değerlendirilen seçimler

  • RabbitMQ, Celery, SQLAlchemy, Python gibi teknoloji seçimlerini yeniden değerlendiriyorlar; çünkü bunlar karmaşıklığı artırabiliyor veya bakım yükünü yükseltebiliyor
  • Yeni bir kod tabanına başlasalardı bu teknoloji seçimlerini daha dikkatle düşünürlerdi

Memnun oldukları seçimler

  • GraphQL, özel taşıma protokolü, Kubernetes gibi seçimlerden memnunlar
  • GraphQL'in kendi kendini belgeleme, kod üretimi, GraphiQL etkileşimli gezgini gibi avantajları var.
  • GraphQL kullanmanın avantajlarının dezavantajlardan daha ağır bastığını düşünüyorlar
    • Avantajlar
      • Kesin dönüş tipleri için kendi kendini belgeleme
      • Kesin dönüş tipleri için kod üretimi sayesinde istemciler daha güvenli hale geliyor
      • GraphiQL etkileşimli gezginiyle üretkenlik artıyor
      • Çeşitli uygulamaların (kullanıcı uygulaması, destek uygulaması, Wave ajan uygulaması vb.) çoğu tek bir API'yi paylaşabildiği için karmaşıklık azalıyor
      • Yapılandırılabilir bir sorgu dili sayesinde istemciler, çok sayıda özel amaçlı endpoint oluşturmadan ihtiyaç duydukları veriyi tek bir paket gidiş-dönüşüyle tam olarak alabiliyor
      • RESTful API sayılacak şeyler üzerine yapılan bikeshedding'i (önemli konuları erteleyip daha az önemli şeyleri uzun uzun tartışarak zaman harcamayı) ortadan kaldırıyor
    • Dezavantajlar
      • GraphQL kütüphaneleri, GraphQL'i benimsedikleri dönemde çok iyi değildi
      • Varsayılan GQL kodlaması yinelenen yapıda ve birçok müşteri düşük bant genişliği kullandığı için boyut sınırlarına çok dikkat ediyorlar
  • Kubernetes, ülke bazında veri merkezi işletme gereksinimlerini karşılamak için kullanılıyor

Sonuç

  • Uygulama mimarisini mümkün olduğunca basit tutarak karmaşıklık (ve insan kaynağı) bütçesini işe gerçekten yarayan karmaşıklığın olduğu yerlere harcayabiliyorlar
  • Karmaşıklık eklemek için güçlü bir neden olmadıkça işleri olabildiğince basit yapma anlayışı sayesinde, genelde zor bir iş kolu sayılan Afrika finans sektöründe faaliyet göstermelerine rağmen çok fazla mühendise ihtiyaç duymadan oldukça büyük bir iş kurabildiler

9 yorum

 
secret3056 2024-03-18

Bence "satın almak yerine inşa et" değil, "inşa etmek yerine satın al" daha doğru gibi görünüyor.

Bir başka alan da satın almak yerine inşa etmek zorunda kaldığımız yazılımlar.

 
xguru 2024-03-18

Ah, vurgulamak isterken başlık tuhaf bir hale gelmişti. Düzelttim. Teşekkürler.

 
savvykang 2024-03-12

Ekonomik döngülere göre trendler mi değişiyor? Trendlerden bağımsız olarak monolitle başlamak, sabit maliyetleri azaltma ve bakım açısından daha avantajlıdır.

 
aer0700 2024-03-12

Anlaşılması kolay bir mimarinin bakımı da kolaydır.

 
mhj5730 2024-03-12

Bana göre hangi hizmet olursa olsun monolitik olarak başlamak daha iyi görünüyor. En baştan MSA ile girerseniz para israfı olur.

 
dhlee0305 2024-03-11

"Karmaşıklık arttıkça maliyetler (para, insan, zaman...) da artar"
"Basit bir mimariyle çözülebilecek bir problemi karmaşık bir mimariyle çözmeye çalışma."

 
xguru 2024-03-11

Hacker News görüşleri

  • Mikroservislerle ilgili mühendislik tavsiyesi

    • Mikroservisler performansı artırma stratejisi değil, potansiyel bir maliyet azaltma stratejisi ve mühendislik koordinasyonu stratejisidir.
    • Yatay olarak ölçeklenebilen monolitik uygulamalar ile mikroservisler arasında, belirli bir işlevi küçültmek istemediğiniz sürece büyük bir fark yoktur.
    • Monolitik bir uygulamada uygulamanın yalnızca bir kısmını küçültmek mümkün değildir.
    • Maliyet azaltımı büyük ölçekte anlamlı hale gelir ve bunun için en az 3 kopya gerekir.
    • Çoğu şirkette asıl fayda mühendislik koordinasyonundadır.
    • Tek depoya sahip bir monolitte bir ekip sahiplik ve yönetim üstlenebilir; ancak paylaşılan monolitikte kimse sahiplik almadığı için yönetmek zorlaşır.
  • Mikroservisler hakkında bir konuşma

    • Genel teknoloji konferanslarında mikroservis mimarisinin karmaşıklığı ve yan etkileri hakkında birçok sunum vardı, ancak basit bir monolit inşa etme hakkında sunum yoktu.
    • David Schmitz'in mikroservislerde başarısız olma ipuçlarını ele alan konuşması etkileyiciydi ve mizahi sunum tarzı çok çekiciydi.
  • Bilişsel önyargı ve sadelik

    • İnsanlar çoğu zaman bir şey eklemeye odaklanır ve basit çözümleri gözden kaçırır.
    • Araştırmalar, Lego yapılarında tuğla eklemek yerine çıkartarak problemi çözmenin daha iyi bir çözüm olduğunu gösteriyor.
  • Aşırı mühendislik ve deneyim eksikliği

    • Mimari, "yeterince basit ama gerektiği kadar karmaşık" olmalıdır; ancak bunu başarmak deneyim gerektirir.
    • BT sektörü deneyim eksikliğine yatkındır ve deneyim zaman alır.
    • Deneyimsiz mühendisler ve yöneticiler çoğu zaman gereksiz teknoloji veya metrikler kullanır.
  • İş-yaşam dengesine önem veren şirketler

    • Ürünü iyileştirmeye odaklanıp kalan zamanı kişisel yaşama ayırmak isteyen bir şirket aranıyor.
  • Dan Luu ile ilgili kişisel deneyim

    • Dan Luu, blog hayranlarıyla iletişimde cömerttir ve yazılım ile donanım arasındaki sınır konusunda uzmanlığa sahiptir.
    • İçgörülerini ve uzmanlığını paylaşma konusunda eli açıktır; ondan öğrenmek çok keyifli bir deneyimdir.
  • Basit mimarinin önemi

    • Çoğu durumda gereken mimari; SSL destekli bir yük dengeleyici, birden fazla uygulama sunucusu, shard edilmiş bir veritabanı, mesaj kuyruğu gibi temel bileşenlerden oluşur.
  • Mimari ve mühendislik ekiplerinin sosyal yapısı

    • Mimari, mühendislik ekiplerinin sosyal yapısını yansıtmalıdır; bu göz ardı edilirse karışıklık ve verimsizlik ortaya çıkabilir.
    • Büyük monolitik depolar ve basit mimariler yönetmesi zor olabilir; Google ve Meta gibi şirketler de içeride çok sayıda araç geliştirir.
    • Mimari, ekipler arası iş birliğini destekleyebilir ya da engelleyebilir; bu nedenle teknik liderliğin bunu dikkate alması gerekir.
  • Basit mimari tercihi

    • Basit mimari ve monolit çoğu durumda uygundur, ancak senkron IO'nun yol açtığı sorunların ortaya çıkmamasına dikkat edilmelidir.
    • Veri bütünlüğü hataları, finansal sistemlerde kaçınılması gereken önemli bir problemdir.
 
dangyup 2024-03-18

"David Schmitz'in mikroservislerin başarısızlığına dair ipuçlarını ele alan konuşmasının" bağlantısını rica edebilir miyim.