Google'ın Kelsey Hightower'ı, BT uygulamalarının nasıl merkezileştirileceği ve geliştirileceği konusunda ipuçları sunar

Yorum: Google gibi çalışamayacak olsanız da, diğerlerinin onun mühendislik başarısını taklit etmelerinin önemli bir yolu var.

Resim: metamorworks, Getty Images / iStockphoto

Kurumsal BT tutarlılığıyla ilgili sorun (yani, kaosa düzeni getirecek kuruluş genelinde tek bir yazılım yığını uygulamak), kurumsal BT'nin statik olmamasıdır. Çünkü teknoloji statik değil. Gibi Google'ın Kelsey Hightower'ı Comcast'in baş yazılım mimarı Jon Moore ile yaptığı bir röportajda, “Çoğu kuruluş zamanla öğreniyor. Yani bugün (varsayılan yığın) olarak ne inşa ederseniz edin, yeni öğrenmelere dayalı olarak dallanacaktır.”

Öyleyse bir işletme nasıl standart hale getirilmeli, böylece maliyet tasarrufu ve üretkenlik kazanımları elde edilmelidir? Hayır, dedi Hightower. En azından, bir kez ve herkes için değil: “Yapabildiğiniz yerde standartlaştırın, ancak şeylerin parçalanmasına izin verin ve sonra bu şeyleri yeniden standartlaştırın ve sadece evrim yolunu izleyin.”

Ama nasıl standartlaştırılır? Soru bu.

GÖRMEK: Sistem yöneticilerinin öğrenmesi için en iyi 5 programlama dili (ücretsiz PDF) (TechRepublic)

Bazı şeyler tartışmaya açık değil

Elbette her şeyin sürekli akış halinde olması gerekmiyor. Moore'un işaret ettiği gibi, BT'nin bazı alanlarında “herkesin ihtiyaç duyduğu çok iyi anlaşılmış yetenekler vardır … aynı şey (bol miktarda) oldukça olgun seçeneklerle ilgili.” Bu tür alanlarda, Hightower'ın ifadesini ödünç almak için tek bir ekibin “parçalanmasına” gerçekten gerek yoktur. Bu tür alanlarda şirket genelinde tutarlılık olması, bir kişinin ekipler arasında hareket edebileceği ve tıpkı bir CI / CD Daha önce kullandıkları sistem.

Bazı kişiler veya ekipler yine de kendi yollarına gitmeyi tercih edebilir, ancak şirketler kurumsal olarak ayrılmayı zorlaştırabilir. Google'ın kendi BT uygulamalarına atıfta bulunan Hightower şunları açıkladı:

(Google'da) yakalamamız yaklaşık 20 yılımızı alan pek çok ortak nokta var … Bir şeyi üretime hazır hale getiren her şey, o teslimat hattının parçası olan pek çok çerçeveye sahibiz. Bunlar pek tartışmaya açık olmayan alanlar… Dahili olarak Blaze adında bir ana yapı sistemimiz var. Ve muhtemelen bunu kullanacaksınız çünkü Google'da dahili olarak bir oluşturma aracına sahip olmak için gerekenler için artık çıta o kadar yüksek ki belki birisi “Evet, elbette kendi işinizi yapın. Ama bu şeyin yapması gerekiyor bu 75.000 şey, kendinizi bayıltın. ”

Google gibi bir yerde bu tür şeylere güçlü bir çekim gücü çekiliyor çünkü bunu daha kolay hale getiren birçok şeyi merkezileştirdiler. geliştiriciler organizasyon genelinde üretken olmak. (Hightower: “Tüm birim testlerini çalıştırabilir ve sahiplerin kim olduğunu bilir. Ve bir değişiklik yapmak ve tüm entegrasyon testlerinin çalıştığından emin olmak için doğru olay sırasını bilir.”) Hayır, sahip değilsiniz bu standarda uymak için, ancak Google kuruluşun başka bir yerinde güvenlikten ödün vermenize izin vermeyeceği için, ya yukarıda belirtilen “75.000 şeyi” temizlemeniz ya da sadece borg'u olduğu gibi benimsemeniz gerekir.

Bu, takımların sonsuza dek aynı şeyi yapmakta kaldığı anlamına gelmez. Hightower'ın açıklamaya devam ettiği gibi, farklı ekipler dahili, varsayılan araçları bir araya getirmek için özel iş akışları kullanabilir. Bu tür iş akışları, deneme ve yenilik için bol miktarda alan bırakır. Daha büyük kuruluşlar için anahtar, kullanılabilecek her bir yazılım veya donanım parçasını tanımlamaktan çok, birlikte çalışabilirliği sağlamak için sistemler arasındaki arayüzleri tanımlamaktır.

Yerçekimi çekmeleri

Google Three gibi bir monorepo (şirketin kodu ve dokümantasyonu barındırmak için kullandığı dahili bir Google aracı) her kuruluş için işe yaramayabilirken, hayatı herkes için kolaylaştıran merkezi sistemlere sahip olmanın gerçek değeri vardır. Oraya ulaşmak gerçekten CIO'nun “Java kullanacaksın” demesiyle ilgili değil. Bunun yerine, Hightower, bir şirketin “gerçek bir bağlılığa” ihtiyacı olduğunu söyledi. Bu taahhüt muhtemelen 100 mühendisle başlamıyor. Bunun yerine, daha küçük başlar – belki de küçük bir avuç mühendis başkalarını üretken kılacak araçlar geliştirir. Zamanla, bu tür merkezi sistemler için çekim kuvveti, şirketin öngördüğü şekilde inşa etmeyi ne kadar kolaylaştırdıklarına paralel olarak artacaktır.

Buna Moore, bu merkezi ekibin çalışmaları için ters ibrazlar yayınlamasının mantıklı olduğunu, bu sayede büyümelerini finanse etmelerine izin verirken aynı zamanda hizmet ettikleri ekiplere karşı sorumlu tutmalarını da ekledi (“fonları, kullanıldıkları miktarla orantılı olarak büyüyor”) . Bu şekilde, standartlar bir organizasyon içinde kireçlenmeden büyür.

Hightower'ın belirttiği gibi, teknoloji / endüstri değiştikçe standartların da gelişmesi doğru ve uygundur. Ancak, bu akışkanlığın, küçük bir başlangıç ​​yatırımı olan bir şirket tarafından dövülebilen sağlam bir çekirdekten akması da mantıklıdır. Küçük başlayın, geliştiricileri dahili olarak üretken hale getirin ve merkezi yatırımın C düzeyindeki bir fiat değil, yardımcı programı sayesinde büyüdüğünü izleyin.

Açıklama: AWS için çalışıyorum, ancak burada ifade edilen görüşler benimdir.

Ayrıca bakın

Source link

İlk yorum yapan olun

Bir yanıt bırakın

E-posta hesabınız yayımlanmayacak.


*