Bulması zor boş zamanlarımda klasik motosikletleri tamir edip tamir ediyorum. Motosiklet tamircisinden daha iyi bir bulut mimarı olduğum için, her marka, model ve motosiklet türü için tasarım modellerine başka bir kişiden daha fazla odaklanıyorum. Ya da daha iyi ifade etmek gerekirse, aynı hedeflere ulaşmak için motosiklet markalarının ve modellerinin aynı şeyleri hem karmaşık hem de basit olarak nasıl farklı şekilde yaptığına bakıyorum.
Bisikletlerimden birinin 20 hareketli parçaya sahip ön tekerlek frenlerine sahip olduğunu ve diğerlerinin yalnızca 5’e sahip olduğunu fark ediyorum. Her iki sistem de bisikleti durduruyor, ancak daha karmaşık çözümün kırılma olasılığı daha yüksek ve düzeltilmesi daha zor. Aşırı mühendisliktir. Aynı hedeflere ancak farklı maliyet ve risk seviyelerinde ulaşır. Belki de aynı şey bulut bilişim tasarımı ve dağıtım alanında gerçekleşiyor.
Aşırı mühendislik, bir problemi daha karmaşık tasarımla aynı verimliliği ve etkinliği gösterebilen daha basit bir çözüme kıyasla ayrıntılı veya karmaşık bir şekilde çözme eylemidir.
Yakın tarihli bir Deloitte çalışması bulut bilişim bütçeleri hakkında bazı ilginç gerçekleri ortaya çıkardı. Bütçelerin, işletmelerin bulut bilişimden nasıl etkili bir şekilde yararlandığı konusunda temel bir fark yaratacağını düşünürdünüz, ancak bunlar başarıyı tahmin etmek için iyi göstergeler değildir. Bu pek çok şeyi gösterebilse de, paranın bulut bilişimle değerle ilişkili olmadığından şüpheleniyorum.
Çoğu durumda, bunun nedeni, çoğu işletmenin aradığı optimize edilmiş değere ulaşmak için daha basit ve daha uygun maliyetli yaklaşımların daha iyi çalıştığı aşırı karmaşık bulut çözümlerinin tasarımı ve dağıtımı olabilir.
Mühendislere çözümü neden bu şekilde tasarladıklarını sorarsanız (aşırı mühendislik olsun ya da olmasın), yaklaşımlarını kendilerinden başka kimsenin anlamadığı bir neden veya amaç etrafında savunacaklar. Temel bir bulut mimarisine veya bu konudaki herhangi bir çözüm tasarımına indiğinizde, fikir ve önyargı ortaya çıkar. Üstelik birçok mühendis, çalıştığı sürece nasıl tasarlandığını kimin umursadığını tartışır.
Yazdıklarımı okuyorsanız, tam olarak optimize edilmiş bulut mimarilerine kafayı taktığımı zaten anlamışsınızdır, bu da en uygun maliyetli çözümü bulmak anlamına gelir. Normalde bu, en az bileşeni kullanarak, aşırı mühendislik veya aşırı yüklenme olmayan en basit çözümü seçmek anlamına gelir. Bu, birçoğunun aksine Rube Goldberg zar zor çalışan ve üç ila dört kat daha pahalıya mal olan bulut mimarileri var.
Bu, artık çok az sayıda nitelikli bulut mimarımız olduğu için ortaya çıkan sistemik bir sorundur. Şirketler, bir satıcının mimari sertifikasyonunu geçmiş olabilecek birine razı oluyorlar, bu da onları yalnızca çok dar bir teknoloji grubunda yetkin yapıyor ve çoğu zaman büyük resmi dikkate almıyor.
Kuruluşlar çoğu zaman, yalnızca bir şeyin işe yaraması için teknolojiyi soruna atarak hızlı ve aşırı mühendislik çözümleri kullanmaya zorlanan yanlış bulut çözümleri mimarlarını işe alır. Daha da kötüsü, aynı hedefe giden daha az karmaşık ve daha az maliyetli yollar olup olmadığını belirlemek için kritik sorular sormazlar ve çözümü akran incelemesi yapmazlar.
Ayrıca, bu kişiler genellikle basit, optimize edilmiş bir çözüm elde etmekten ziyade dağıtım hızına ve günlük scrum toplantılarına odaklanır. Bu, çalıştırılması ve güvenliği zor olan ve dağıtılması ve çalıştırılması gerekenden çok daha pahalıya mal olan daha karmaşık bulut çözümleriyle sonuçlanır. Bahse girerim şu anda kendi şirketinde bunlardan birini düşünüyorsundur.
Tamam, şimdi sorunu bildiğimize, hatta belki de bunun bir sorun olduğu konusunda hemfikir olduğumuza göre, bu konuda ne yapacağız?
Bir bulut bilişim çözümü tasarlarken hızın nihai hedef olması gerektiğinden emin değilim. En optimize edilmiş bir çözüm aramalı ve bunu yapmak için en verimli yoldan gitmeliyiz. Birçok şirketin hızı her şeyin önüne koyduğunu görüyorum. Elbette bu, pandeminin buluta çılgınca koşuşturması sırasında sık sık meydana geldi.
Yine sorun, aşırı mühendislik çözümlerinin tipik olarak işe yaraması ve bu nedenle, yetenekli bir mimar, yaklaşımın maliyetinin dört katı olduğunu ve iş için yanlış anlaşılan bir yük olacağını tam olarak anlasa bile, bir başarı olarak ilan edilmesidir.
Sizi zor soruları sormaya ve kötü tasarlanmış olduğuna inandığınız çözümlere meydan okumaya çağırıyorum. Bunların çok fazla olması işinizi öldürür; Bunu ilk elden gördüm. Bunu yapmazsanız, tıpkı benim motosikletlerim gibi, arızaların daha sık olduğunu ve tamir edilmesinin çok zaman gerektirdiğini göreceksiniz.
Telif Hakkı © 2022 IDG Communications, Inc.
Kaynak : https://www.infoworld.com/article/3668657/dont-overengineer-your-cloud-architecture.html#tk.rss_all