Erik Gfesser, SPR’nin Veri Uygulama Bölümünün Baş Mimarı – Röportaj Serisi

Erik, 2018 yılında SPR‘nin Yeni Teknoloji Grubu’nun veri uygulamasına Baş Mimar olarak katıldı.

Erik, verilere, Java kullanarak açık kaynak geliştirme ve pratik entreprise mimarisi konusunda uzmanlaştı, bunların arasında PoC’ler, prototipler ve MVP’lerin oluşturulması da yer alıyor.

Siz machine learning’e ilk olarak neler çekti?

Uygulamaların sürekli öğrenmesini sağlayan bir özelliği vardı. Geliştirme kariyerime bir global pazar araştırma şirketinde senior veri analisti olarak SPSS kullanarak başlamıştım ve daha sonra müşteriler için inşa ettiğim uygulamalara Drools adlı bir iş kuralları motorunu entegre etmiştim, ancak tüm bu çalışmaların çıktısı esasen statikti.

Daha sonra, işleyiş iyileştirme eğitimine katıldım, bu eğitimde eğitmenler, istatistik ve diğer yöntemler kullanarak müşterilerinin kullandığı iş süreçlerini nasıl iyileştirebildiklerini ayrıntılı olarak anlattılar, ancak burada da çıktı büyük ölçüde zaman noktalarına odaklanıyordu. Aynı dönemde inşa ettiğimiz bir sağlık ürününü geliştirmeye çalışırken, sürekli öğrenmenin neden gerekli olduğu ortaya çıktı, ancak o zaman mevcut olmayan kaynaklar şimdi mevcuttur.

İlginç bir şekilde, machine learning’e karşı ilginim tam da burada düğümleniyor, çünkü yüksek lisans danışmanım, o zamanlar yapay zeka olarak adlandırılan bir alanda uzmanlaşmama karşı uyarıda bulundu, çünkü o zamanlar yapay zeka kışası vardı. Bunun yerine, ML gibi terimlerin kullanımına yöneldim, çünkü bunlar daha az çağrışım içeriyor ve AWS, AI hizmetleri katmanının aslında ML hizmetleri katmanının üzerine inşa edilmiş daha yüksek bir soyutlama olduğunu kabul ediyor. ML ile ilgili bazı abartılı iddialar olsa da, geliştiriciler açısından güçlü olanaklar sunuyor, ancak aynı zamanda bu olanakların değeri, işlenen verilerin kalitesine bağlı olarak değişiyor.

Açık kaynak savunucususunuz, açık kaynağın neden bu kadar önemli olduğunu tartışabilir misiniz?

Açık kaynakla ilgili olarak yıllardır yöneticilere açıklamak zorunda kaldığım bir yön, açık kaynaklı yazılımların birincil avantajının parasal maliyet olmaması değil, kaynak kodlarının ücretsiz olarak sunulmasıdır.

Ayrıca, bu kaynak kodunu kullanan geliştiriciler, bunu kendi kullanımına göre değiştirebilir ve önerilen değişiklikler onaylanırsa, bunları diğer geliştiricilerle paylaşabilir. Aslında, açık kaynaklı yazılımların arkasındaki hareket, geliştiricilerin lisansladığı ürünlerde değişiklikler yapmak için ticari şirketlere uzun süre beklemelerinden kaynaklandı, bu nedenle geliştiriciler, aynı işlevselliğe sahip yazılımları yazmaya ve bunları diğer geliştiriciler tarafından geliştirilebilecek şekilde açmaya başladılar.

Ticari açık kaynak, bu avantajlardan yararlanıyor, gerçeklik ise birçok modern ürünün altında açık kaynak kullandığı, genellikle ticari varyantlarının açık kaynaklı sürümünün bir parçası olmayan ek bileşenler sunması ve farklılaştırıcılar ve gerektiğinde destek sağlaması.

Açık kaynakla olan ilk deneyimim, daha önce bahsettiğim sağlık ürününü inşa ederken yaşandı, o zamanlar Apache Ant gibi yazılımları ve o zamanlar bir DevOps ürünü olan Hudson’u (kod tabanı daha sonra Jenkins oldu) kullandık. Bu açık kaynaklı ürünleri kullanma kararımızın temel nedeni, bunların ya ticari alternatiflere göre daha iyi çözümler sunması, ya da ticari şirketler tarafından sunulmayan yenilikçi çözümler olması, ayrıca kullandığımız bazı ürünlerin ticari lisanslarının çok kısıtlayıcı olması ve lisans maliyetleri nedeniyle gerektiğinde daha fazla lisans almak için fazla bürokrasi olması.

Zaman içinde, açık kaynaklı tekliflerin devam ettiği ve çok ihtiyaç duyulan yenilikler sağladığını gördüm. Örneğin, sağlık ürününü inşa ederken karşılaştığımız birçok sorun, daha sonra kullandığımız bir açık kaynaklı Java ürünü olan Spring Framework tarafından çözüldü, bu ürün on yıldan fazla bir süredir devam ediyor ve ekosistemi, ilk olarak sunduğu bazı yeniliklerin çok ötesine geçti, artık ortak kabul gören şeyler gibi görünen bağımlılık enjeksiyonu gibi.

Açık kaynak kullanarak PoC’ler, prototipler ve MVP’ler inşa ettiniz. Bu ürünlerin arkasındaki yolculuğunuzu paylaşabilir misiniz?

Bir müşteriye sunduğum rehber ilkelerle ilgili olarak, veri platformunun inşa edilmesi, zaman içinde gerektiği şekilde sürekli olarak yapılmalıdır. Bu platform için inşa edilen bileşenler, statik kalması beklenmemelidir, çünkü ihtiyaçlar değişir ve yeni bileşenler ve bileşen özelliklerinin sunulması gerekir.

Platform işlevselliğinin inşa edilmesi sırasında, önce minimal olarak uygulanabilir olanı inşa edin, sonra gereksiz çan ve çanaklar eklemeyin, bu bazen yapılandırma dahil olmak üzere bazı durumlarda da yapılır. İşlevsel olanı inşa edin, anlayın ve sonra geliştirin. Kullanılması düşük olasılıkla olan şeyleri inşa etmek için zaman ve para harcamayın, ancak gelecekteki ihtiyaçların önüne geçmeye çalışın.

Bu ürün için inşa ettiğimiz MVP, ek kullanım durumları üzerine inşa edilebilecek şekilde açık bir şekilde inşa edilmeliydi, ancak yalnızca bir kullanım durumu için uygulanması paketlenmişti, masraf anomali tespiti için. Daha önce inşa ettiğim bir ürün, benim katılmamdan önce bir geçmişe sahipti. Bu durumda, paydaşlar, inşa etmek istedikleri ürüne nasıl yaklaşacaklarına dair üç yıl (!) boyunca tartışmışlardı. Bir müşteri yöneticisi, beni bu iç tartışmaların ötesine geçmemde yardımcı olmak için getirdiğini söyledi, özellikle de ürünün, ilgili organizasyonların hiyerarşisini memnun etmesi gerektiği için.

Bu ürünün tüm ürün geri bildirimi, müşterinin, iştiraklerinin ve dış müşterilerinin sahip olduğu verilerin nasıl alınacağı, depolanacağı, güvence altına alınacağı ve tüketileceğiyle ilgiliydi, bu nedenle tek bir kullanım durumu için ağ oluşturma Analizleri için sağlık hizmeti sağlayıcıları inşa ediyorduk.

Kariyerimin başlarında, bir mimari kalite olan “kullanılabilirlik”in yalnızca son kullanıcılar için değil, yazılım geliştiricileri için de sınırlı olmadığını anladım. Bunun nedeni, yazılan kodun, kullanıcı arayüzlerinin son kullanıcılar tarafından kullanılabilir olması gibi kullanılabilir olmasıdır. Bir ürün kullanılabilir hale gelmesi için, geliştiricilerin yapmak istediklerini yapabileceklerini göstermek için kavram kanıtları inşa edilmelidir, özellikle de yaptıkları belirli teknoloji seçimlerine ilişkin olarak. Ancak kavram kanıtları sadece başlangıçtır, ürünler zaman içinde geliştirildikçe en iyisidir. Görüşüme göre, bir MVP’nin temeli, geliştiricilerin bunu devam ettirebileceği şekilde稳 bir şekilde inşa edilmiş prototipler üzerine inşa edilmelidir.

Açık kaynaklı ürünlerin, çerçevelerinin ve dillerinin yanı sıra açık ve ticari bileşenlerin karışımından oluşan esnek bir mimari kullanılmasıyla ilgili olarak, şirketlerin birçok firmanın hemen gerçekleştiremediği bir çeviklik sağladığını belirttiniz. Açık kaynak kullanan şirketlerin neden daha çevik olduğuna ilişkin detayları paylaşabilir misiniz?

Birçok ticari veri ürünü, altında açık kaynaklı bileşenler kullanıyor ve geliştiricilerin popüler programlama dillerini kullanmasını sağlıyor. Bu ürünleri inşa eden şirketler, kullandıkları açık kaynaklı bileşenlerin, topluluk tarafından zaten yaygın olarak kullanılan bir başlangıç noktası sağladığını biliyorlar.

Güçlü topluluklara sahip açık kaynaklı bileşenler, satmak daha kolaydır, çünkü bunlar masaya getirdikleri tanıdıklık nedeniyle. Büyük ölçüde kapalı kaynak veya yalnızca belirli ticari ürünler tarafından kullanılan açık kaynaklı bileşenlerden oluşan ticari olarak उपलबdurulan ürünler, genellikle bu ürünlerin satıcıları tarafından eğitim veya lisans gerektirir.

Ayrıca, bu bileşenlerin belgeleri genellikle kamuoyuna açık değildir, bu nedenle geliştiricilerin bu şirketlere bağımlılığını sürdürmesi gerekir. Genellikle kabul gören açık kaynaklı bileşenler, Apache Spark gibi, merkezi odak noktası olduğunda, Databricks Birleşik Analitik Platformu gibi ürünlerde, bu öğelerin çoğu zaten toplulukta mevcuttur, bu nedenle geliştirme ekiplerinin ticari varlıklara bağımlı olması gereken kısımlar minimize edilir.

Ayrıca, Apache Spark gibi bileşenler, endüstri standardı araçlar olarak kabul edildiğinden, kod bu ürünlerin ticari uygulamaları arasında kolayca taşınabilir. Şirketler, rekabet avantajı olarak gördüklerini dahil etmeye eğilimlidir, ancak birçok geliştirici, tamamen yeni ürünler kullanmak istemez, çünkü bu, firmalar arasında geçiş yapmak için zorluklara neden olur ve güçlü topluluklardan beklentilerini karşılar.

Kişisel deneyimim, böyle ürünlerle çalıştığım zamanı içerir ve yetkin destek almak zor olabilir. Ve bu, ironiktir, çünkü bu şirketler ürünlerini, destek sağlanacağı beklentisiyle satıyorlar. Açık kaynaklı bir projeye bir çekme talebi gönderdim ve aynı gün derlemeye dahil edildi, ancak ticari bir projede çalıştığım hiçbir zaman böyle bir deneyim yaşamadım.

Açık kaynakla ilgili olarak inandığınız bir başka şey, güçlü geliştirici topluluklarına erişim sağladığıdır. Bu toplulukların büyüklüğü nedir ve neleriyle etkili olurlar?

Bir açık kaynaklı ürünün etrafındaki geliştirici toplulukları, yüz binleri bulabilir. Benim için bir topluluğun güçlü olması, sağlıklı tartışma ve etkili belgelendirmenin üretildiği ve aktif geliştirmenin yapıldığı zaman gerçekleşir.

Bir mimar veya kıdemli geliştirici, hangi ürünleri inşa ettikleriyle ilgili olarak seçim yaparken, birçok faktör devreye girer, ürünün kendisinden, topluluğun görünümünden, geliştirme ekiplerinin bu ürünleri benimsemesinden, bu ürünlerin inşa edilen ekosisteme uyup uymadığından, yol haritasından ve bazen de ticari destek gerekip gerekmediğinden bahsedilir. Ancak bu yönler, güçlü geliştirici topluluklarının отсутствı durumunda genellikle göz ardı edilir.

100’lerce kitabın incelemesini yaptınız, okuyucularımıza önermek için üç kitabın adını verebilir misiniz?

Şimdi çok fazla programlama kitabı okumuyorum ve istisnalar olsa da, gerçeklik, bu kitapların genellikle çok nhanh bir şekilde eskidiği ve geliştirici topluluğunun genellikle tartışma forumları ve belgeler aracılığıyla daha iyi alternatifler sunduğudur. Şimdi okuyacağım kitapların çoğu, bana ücretsiz olarak gönderilir, ya teknoloji bültenlerine abone olduğum için, ya da yazarlar ve publicistler bana ulaştıkları için, ya da Amazon’un bana gönderdiği kitaplar.

(1) O’Reilly’den önerdiğim bir kitap, “Veritabanı Nirvanası Arayışında”. Yazar, bir veri sorgu motorunun, iş yüklerini desteklemek için karşılaştığı zorlukları, bir uçta OLTP’den diğer uçta analitik işlemlere kadar, ortada işlemsel ve iş zekası işlemleriyle birlikte, ayrıntılı olarak ele alır. Bu kitap, bir veritabanı motorunu veya sorgu ve depolama motorlarının bir karışımını, iş yükü gereksinimlerini karşılamak için bir rehber olarak kullanılabilir. Ayrıca, yazarın son yıllarda “veritabanı sallanan sarkacı”nı ele alması özellikle iyi yapılmıştır.

(2) Veri alanında son birkaç yılda çok şey değişmiş olsa da, “Bozucu Analitik” son 50 yılın analitikteki yeniliklerin kısa ve ulaşılabilir bir tarihini sunuyor ve analitik değer zincirindeki ve analitikle endüstriyi bozan iki tür bozucu yenilikten bahsediyor. Başlangıç şirketleri ve analitik uygulayıcıları açısından, başarı, endüstrilerini bozmakla sağlanır, çünkü bir ürünü ayırt etmek için analitiği kullanmak, bir iş modelini bozmak veya yeni pazarlar yaratmak için bir yoludur. Bir organizasyon için analitik teknolojisine yatırım yapmak açısından, bekleyip görmek mantıklı olabilir, çünkü risk altında olan teknolojiler, kısaltılmış kullanım süreleri nedeniyle riskli yatırımlardır.

(3) Okuduğum en iyi teknoloji iş metinlerinden biri, Research Board’un (Gartner tarafından satın alındı) kurucularından biri tarafından yazılmıştır, bu düşünce kuruluşu, bilgisayar dünyasındaki gelişmeleri ve şirketlerin nasıl adapte olması gerektiğini araştırır. Yazar, birçok iş lideriyle yaptığı konuşmalardan çok ayrıntılı notlar sunuyor ve deneyimlerinden关于 analizler yapıyor. İncelememde belirttiğim gibi, bu kitabı diğer ilgili çalışmalardan ayıran iki özellik, endüstri genelinde genişlik ve yüz yüze etkileşim aracılığıyla elde edilen samimiyettir.

SPR’nin veri uygulamasının Baş Mimarısınız. SPR’nin ne yaptığını açıklayabilir misiniz?

SPR, Chicago bölgesinde bulunan bir dijital teknoloji danışmanlık şirketidir ve Fortune 1000 şirketlerinden yerel başlangıçlara kadar çeşitli müşteriler için teknoloji projeleri sunar. Özel yazılım geliştirme, kullanıcı deneyimi, veri ve bulut altyapısından DevOps koçu, yazılım testi ve proje yönetimine kadar bir dizi teknoloji yeteneği kullanarak uçtan uca dijital deneyimler inşa ediyoruz.

SPR’deki sorumluluklarınız nelerdir?

Baş mimar olarak, benim ana sorumluluğum, müşteriler için çözüm teslimatını sürmek, mimari ve geliştirme için projeleri yönetmektir, bu genellikle ürün sahibi gibi diğer şapka takmayı da gerektirir, çünkü ürünlerin nasıl inşa edildiğini anlamanın, özellikle sıfırdan inşa edilirken, nasıl önceliklendirilmesi gerektiği konusunda önemli bir etkisi vardır. Ayrıca, uzmanlığım gereken potansiyel müşterilerle görüşmelere çekiliyorum ve şirket, yakın zamanda veri uygulamasındaki diğer mimarlarla, müşteri projeleri, yan projeler ve teknolojiyi takip etmek için neler yaptıklarını tartışmak üzere bir dizi oturum başlatmamı istedi.

Kariyerimin büyük部分inde, açık kaynaklı geliştirme kullanarak Java ve pratik entreprise mimarisi konusunda uzmanlaştım, bunların arasında PoC’ler, prototipler ve MVP’lerin oluşturulması da yer alıyor.

Bu üç uzmanlık alanı, birbirleriyle örtüşür ve birbirini dışlamaz. Son birkaç yıldır, teknoloji endüstrisinin geleneksel olarak çizdiği, yazılım geliştirme ve veri işleri arasındaki çizginin artık iyi tanımlı olmadığını yöneticilere açıkladım, kısmen çünkü bu iki alan arasındaki araçlar birbirine yaklaştı ve kısmen de bu birleşmeden dolayı, veri işleri büyük ölçüde bir yazılım geliştirme çabası haline geldi. Ancak geleneksel veri uygulayıcılarının genellikle yazılım geliştirme geçmişine sahip olmadığını ve tersini de doğru olduğunu gören, bu boşluğu kapatmaya yardımcı oluyorum.

Şu anda SPR ile çalıştığınız ilginç bir proje var mı?

Çok yakın zamanda, ekibimle birlikte inşa ettiğimiz veri platformu hakkında bir dizi caso çalışması serisinin ilk yazısını yayınladım, bu platform Chicago merkezli bir global danışmanlık şirketinin CIO’su için AWS’de sıfırdan inşa edildi. Bu platform, veri boru hatları, veri gölü, kanonik veri modelleri, görselleştirmeler ve makine öğrenimi modellerini içeriyor ve şirketin kurumsal departmanları, uygulamaları ve son müşterileri tarafından kullanılacaktır.

Bu platformun çekirdeği, kurumsal BT organizasyonu tarafından inşa edilecekti, ancak hedef, bu platformun, şirket genelinde merkezi veri varlıkları ve veri analizi için ortak bir mimari oluşturmak için kurumsal BT dışı diğer organizasyonlar tarafından da kullanılabilmesi ve üzerine inşa edilmesiydi.

Kurumsal birimlerin ve danışmanlık uygulamalarının birbirinden izole edildiği ve her birinin farklı süreçler ve araçlar kullandığıEstablished şirketlerde olduğu gibi, Microsoft Excel’in kullanımı yaygındı, elektronik tablolar şirket içinde ve şirketler arası olarak ve şirketler ve dış müşteriler arasında dağıtılıyordu. Ayrıca, bir diğer hedef, veri sahipliği kavramını uygulamak ve şirketler arası güvenli ve tutarlı bir şekilde veri paylaşımını sağlamaktı.

Açık kaynak, SPR veya üzerinde çalıştığınız başka bir proje hakkında paylaşmak istediğiniz başka bir şey var mı?

Bir başka proje (hakkında burada ve burada okuyun), yakın zamanda yönettiğim, büyük bir sigorta şirketinin veri mühendisliği direktörünün Databricks Birleşik Analitik Platformu’nu başarıyla uygulamak ve Azure HDInsight’tan (bir Hadoop dağıtımı) makine öğrenimi modellerinin çalıştırılmasını bu platforma taşımak oldu.

Tüm bu modeller, çeşitli sigorta ürünlerinde beklenen tüketici benimsemesini öngörme amacını taşıyordu, bazıları birkaç yıl önce SAS’den taşınmıştı ve o zaman HDInsight kullanılmaya başlanmıştı. En büyük zorluk, veri kalitesinin kötü olmasıydı, ancak diğer zorluklar da vardı, bunlar arasında kapsamlı sürüm oluşturma, kabilesel bilgi ve eksik belgelendirme ve Databricks’in o zamanlar yeni genel olarak sunulan Azure uygulamasına ilişkin belgelendirme ve destek eksikliği (R kullanımı ile ilgili) yer alıyordu.

Bu ana zorlukları gidermek için, uygulamamızın ardından, otomasyon, yapılandırma ve sürüm oluşturma, veri endişelerinin ayrılması, belgelendirme ve veri, platform ve modelleme ekipleri arasında gerekli hizalamalar konusunda önerilerde bulundum. Çalışmamız, başlangıçta çok şüpheci olan Baş Veri Bilimcisini, Databricks’in doğru seçim olduğuna ikna etti, amaçları kalan modelleri mümkün olduğunca nhanh bir şekilde Databricks’e taşımak oldu.

Bu, açık kaynak hakkında çok şey öğrendiğim ilginç bir röportaj oldu. Daha fazla bilgi öğrenmek isteyen okuyucular, SPR kurumsal web sitesini veya Erik Gfesser’in web sitesini ziyaret edebilir.