Erik Gfesser, SPR Veri Uygulamasının Baş Mimarısı – 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 kurumsal mimariye uzmanlaşmış, ayrıca PoC’ler, prototipler ve MVP’ler oluşturmayı da içermektedir.

Siz makine öğrenmesine ilk olarak ne zaman ilgi duydunuz?

Uygulamaların sürekli öğrenmesini sağlayan bir özelliği olmasıdır. Veri analisti olarak kariyerime başladığım zaman, bir küresel pazar araştırma şirketinde SPSS kullanarak çalışmaya başlamıştım ve daha sonra müşteriler için Drools adlı bir iş kuralları motoru kullanarak uygulamalar geliştirmiştim, ancak tüm bu çalışmaların çıktısı esasen statikti.

Daha sonra iş süreci iyileştirme eğitimine katıldım ve eğitmenler, istatistik ve diğer yöntemler kullanarak müşterilerinin iş süreçlerini nasıl iyileştirebileceklerini ayrıntılı olarak gösterdiler, ancak bu çalışmaların çıktısı da esasen zaman noktalarına odaklanıyordu. Aynı dönemde geliştirdiğimiz bir sağlık ürünü üzerindeki deneyimlerim, sürekli öğrenmenin neden gerekli olduğunu gösterdi, ancak o zamanlar mevcut kaynaklar yoktu.

İlginç bir şekilde, makine öğrenmesine olan ilgim tam da burada düğümleniyor, çünkü yüksek lisans danışmanım, o zamanlar yapay zeka olarak adlandırılan alana uzmanlaşmama karşı uyardı, çünkü o zamanlar yapay zeka kışası vardı. Bunun yerine, daha az çağrışım yapan terimlere başvurmayı tercih ettim, çünkü AWS bile AI hizmetleri katmanının aslında ML hizmetleri katmanının üzerine inşa edilmiş bir üst düzey soyutlama olduğunu kabul etmektedir. Makine öğrenmesinin bazı vaatleri gerçekçi olmayabilir, ancak geliştiriciler için güçlü olanaklar sağlar, tabii ki bu geliştiricilerin, makine öğrenmesinin sağladığı değerin, işlenen verilerin kalitesine bağlı olduğunu kabul etmeleri koşuluyla.

Açık kaynak savunucususunuz, açık kaynağın neden önemli olduğunu anlatır mısınız?

Açık kaynak hakkında yıllarca yöneticilere açıklamak zorunda kaldığım bir husus, 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 ihtiyaçlarına göre değiştirebilir ve önerilen değişiklikler onaylanırsa, bunları diğer geliştiricilere sunabilir. Aslında, açık kaynaklı yazılımların arkasındaki hareket, ticari şirketlerin ürünlerine yapılan değişiklikleri beklemekte olan geliştiriciler tarafından başlatıldı, bu nedenle geliştiriciler, aynı işlevselliğe sahip yazılımları kendileri yazmaya karar verdiler ve bunları diğer geliştiricilerin geliştirmesine açtılar.

Ticari açık kaynak, bu avantajlardan yararlanarak, birçok modern ürünün altında açık kaynak kullandığını, ticari varyantlarının genellikle açık kaynak sürümünün bir parçası olarak bulunmayan ek bileşenler sunduğunu ve farklılaştırıcılar ve destek sağladığını gösteriyor.

İlk açık kaynak deneyimlerim, daha önce bahsettiğim sağlık ürününü geliştirirken yaşandı, Apache Ant gibi araçları kullanarak yazılım geliştirdik ve o zamanlar erken bir DevOps ürünü olan Hudson’u (sonradan Jenkins oldu) kullandık. Bu açık kaynak ürünlerini kullanma kararımızın temel nedeni, ticari alternatiflere göre daha iyi çözümler sunmaları veya ticari şirketlerin sunmadığı yenilikçi çözümler sunmaları, ayrıca bazı ürünlerin ticari lisanslarının çok kısıtlayıcı olması ve lisans maliyetleri nedeniyle gereksiz bürokrasi yaratmasıydı.

Zaman içinde, açık kaynak tekliflerinin nasıl evrimleştiğini gördüm ve birçok ihtiyaç duyulan yeniliği sağladı. Örneğin, sağlık ürününü geliştirirken karşılaştığımız birçok sorun, daha sonra kullandığımız bir açık kaynak Java ürünü olan Spring Framework tarafından çözüldü, bu ürün on yıldan fazla bir süredir devam ediyor ve ilk olarak sunduğu bazı yenilikler artık yaygın olarak kullanılıyor, Örneğin, bağımlılık enjeksiyonu.

Açık kaynak kullanarak PoC’ler, prototipler ve MVP’ler geliştirdiniz. Bu ürünlerin arkasındaki hikayeyi paylaşabilir misiniz?

Bir müşteriye sunduğum rehber ilkelerde belirttiğim gibi, veri platformu için yapılan çalışmalar, zaman içinde gerekli olduğu şekilde yinelemeli olarak yapılmalıdır. Bu platformun bileşenleri, statik olarak kalmamalıdır, çünkü ihtiyaçlar değişir ve yeni bileşenler ve özellikler zamanla sunulur.

Platform işlevselliğini oluştururken, her zaman minimal olarak viable olanı başlangıç olarak alın, sonra gereksiz çan ve çanların eklenmesinden kaçının, bazen bu, yapılandırmanın bile dahil edilmesini içerir. İşlevsel olanı başlatın, onu anlayın ve sonra geliştirin. Gereksiz zaman ve para harcamayın, düşük olasılıkla kullanılacak şeyleri inşa etmek için, ancak gelecekteki ihtiyaçların önüne geçmek için çaba gösterin.

Bu ürün için inşa edilen MVP, ek kullanım durumları üzerine inşa edilebilecek şekilde açıkça inşa edilmeliydi, ancak tek bir kullanım durumu uygulamasıyla birlikte geldi, yani masraf anomali tespiti. Daha önceki bir ürün, benim geliyorumdan önce bir geçmişe sahipti. Bu durumda, paydaşlar, nasıl yaklaşacaklarını üç yıl tartışmışlardı (!). Bir müşteri yöneticisi, beni, özellikle de internal tartışmaları aşmam için getirdi, çünkü inşa etmek istediği ürün, ilgili organizasyonların hiyerarşisini memnun etmeliydi.

İç savaşların, müşterinin, iştiraklerinin ve dış müşterilerinin sahip olduğu verilerle ilgili olduğunu keşfettim, bu nedenle ürün backlog’u, tek bir kullanım durumu oluşturmak için bu verilerin nasıl alınacağı, depolanacağı, güvenliğinin sağlanacağı ve tüketileceğiyle ilgiliydi.

Kariyerimin başlarında, bir mimari kalitenin, “kullanılabilirlik” olarak adlandırılanın, yalnızca son kullanıcılar için değil, aynı zamanda yazılım geliştiricileri için de sınırlı olmadığını anlamıştı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ün kullanılabilir olabilmesi için, geliştiricilerin ne yapmak istediklerini göstermek için PoC’ler inşa edilmelidir, özellikle de teknoloji seçimlerine ilişkin olarak. Ancak PoC’ler sadece başlangıçtır, ürünler zaman içinde evrimleşmelidir. Görüşüme göre, bir MVP’nin temeli, geliştiricilerin devam ettirebileceği şekilde istikrar gösteren prototipler üzerine inşa edilmelidir.

‘Machine Learning at Enterprise Scale’ kitabını incelemişsiniz ve ‘açık kaynaklı ürünlerin, çerçevelerin ve dillerin kullanımı, açık ve ticari bileşenlerin karışımı olan esnek bir mimari ile birlikte, birçok firmanın ihtiyaç duyduğu ancak başlangıçta farkına varmadığı esnekliği sağlar’ demişsiniz. Açık kaynak kullanan firmaların neden daha esnek olduğuna açıklamada bulunabilir misiniz?

Çok sayıda ticari veri ürünü, altında açık kaynaklı bileşenler kullanır ve geliştiricilerin popüler programlama dillerini kullanmasına olanak tanır. Bu ürünleri oluşturan firmalar, seçtikleri açık kaynaklı bileşenlerin, topluluk tarafından yaygın olarak kullanılan bileşenler olduğunu bilirler.

Açık kaynaklı bileşenlerin güçlü toplulukları, satışı kolaylaştırır, çünkü bunlar, masaya getirdikleri tanıdıklık nedeniyle daha kolaydır. Çoğunlukla kapalı kaynak veya yalnızca belirli ticari ürünler tarafından kullanılan açık kaynaklı ticari ürünler, genellikle eğitim veya lisans gerektirir.

Ayrıca, bu tür bileşenlerin belgeleri genellikle kamuoyuna açık değildir, bu da geliştiricilerin bu firmalara bağımlılıklarını sürdürmelerine neden olur. Genellikle kabul gören açık kaynaklı bileşenler, örneğin Apache Spark, merkezi odak olduğunda, birçok öğe zaten toplulukta mevcuttur, bu da geliştirme ekiplerinin ticari varlıklara bağımlı olması gereken kısımları en aza indirir.

Ayrıca, Apache Spark gibi bileşenler, endüstri standardı araçlar olarak kabul edildiğinden, bu ürünlerin ticari uygulamaları arasında kod kolayca taşınabilir. Firmalar, rekabet avantajı olarak gördükleri şeyi dahil etmeye eğilimlidir, ancak birçok geliştirici, tamamen yeni ürünler kullanmak istemez, çünkü bu, firmalar arasında taşınmayı zorlaştırır ve güçlü topluluklardan kopmaya neden olur.

Kişisel deneyimim, böyle ürünlerle çalıştığım zaman, yetkin destek almak zor olabilir. Bu, firmaların ürünlerini, destek sağlanacağı beklentisiyle sattıkları ironik bir durumdur. Açık kaynaklı bir projeye bir çekme talebi gönderdim ve aynı gün içinde derleme içine alındı, 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ğlamasıdır. Bu topluluklar ne kadar büyük ve neler yapar?

Açık kaynaklı bir ürünün etrafındaki geliştirici topluluğu, yüz binlerce kişiye ulaşabilir. Benim için bir topluluğun güçlü olması, sağlıklı tartışma ve etkili belgeleme üretmesi ve aktif geliştirme yapılması anlamına gelir.

Bir mimar veya kıdemli geliştirici, hangi ürünleri dahil edeceğini seçerken, birçok faktör devreye girer, yalnızca ürün kendisi ve topluluğuyla ilgili değil, aynı zamanda geliştirme ekibi ve geliştirilen ekosistemle ilgili faktörler de önemlidir.

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 startup’lara kadar çeşitli müşteriler için teknoloji projeleri sunar. Custom yazılım geliştirme, kullanıcı deneyimi, veri, bulut altyapısı, DevOps koçu, yazılım testi ve proje yönetimi gibi çeşitli teknoloji yetenekleri kullanarak uçtan uca dijital deneyimler inşa ediyoruz.

SPR’deki sorumluluklarınız nelerdir?

Baş mimar olarak, ana sorumluluğum, müşteriler için çözüm teslimatını yönlendirmek, projeler için mimari ve geliştirme liderliği yapmak, bu da genellikle ürün sahibi gibi diğer şapkalarda da bulunmayı gerektirir, çünkü ürünlerin nasıl inşa edildiğini anlama yeteneği, özellikle sıfırdan inşa edildiğinde, nasıl önceliklendirileceği konusunda büyük bir etkiye sahiptir.

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 projeleri ve teknolojiyi takip etmeleri hakkında görüşmek üzere devam eden bir dizi oturum başlattı.

Kariyerimin büyük部分inde, Java kullanarak açık kaynak geliştirme ve pratik kurumsal mimariye uzmanlaşmıştım. Ayrıca, meslektaşlarımla birlikte “pratik” veya “pragmatik” kurumsal mimari olarak adlandırdığımız şeyi yapıyorum, bu da, sadece konuşmak veya çizimler yapmak yerine, inşa edilecek şeyin bağlamında mimari görevlerini gerçekleştirmek ve aslında inşa etmek anlamına gelir.

Görüşüme göre, bu üç uzmanlık alanı birbirleriyle çakışır ve birbirini dışlamaz. Son birkaç yıldır, teknoloji endüstrisinin geleneksel olarak çizdiği, yazılım geliştirme ile veri işleri arasındaki çizginin artık net olmadığını yöneticilere açıkladım, kısmen because araçlar arasındaki farklılıklar ortadan kalktı ve kısmen de veri işlerinin kendisi 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 olmaması ve tersi de doğru olduğundan, bu boşluğu doldurmak için çalışıyorum.

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

Çok yakın zamanda, Chicago merkezli bir küresel danışmanlık şirketinin CIO’su için geçen yıl ekibimle birlikte AWS’de sıfırdan inşa ettiğimiz veri platformu hakkında bir dizi vaka çalışması yayınladım.

Bu platform, veri boru hatları, veri gölü, kanonik veri modelleri, görselleştirmeler ve makine öğrenimi modellerini içerir ve şirketin kurumsal departmanları, uygulamaları ve son müşterileri tarafından kullanılacaktır. Platformun çekirdeği, müşterinin kurumsal IT organizasyonu tarafından inşa edilmeliydi, ancak platformun, şirket genelinde merkezi bir mimari üzerine inşa edilerek, her organizasyonun kendi kullanım durumu ihtiyaçlarını karşılayabilmesi için kullanılabilmesi hedefleniyordu.

Çoğu kuruluşta olduğu gibi, Microsoft Excel’in kullanımı yaygındı, şirket içinde ve şirketler arası olarak dağıtılan elektronik tablolar vardı. Ayrıca, iş birimleri ve danışmanlık uygulamaları, birbirlerinden ve müşterilerden ayrılmıştı, her biri farklı süreçler ve araçlar kullanıyordu. Bu nedenle, veri varlıklarını ve veri analizlerini merkezi olarak birleştirmenin yanı sıra, organizasyonlar arası güvenli ve tutarlı bir şekilde veri paylaşımını da uygulamayı hedefledik.

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

Şimdiye kadar yüzlerce kitap inceledim ve okuyucularımıza önerilebilecek üç kitap önerebilirim.

(1) O’Reilly’den önerdiğim bir kitap, “Veritabanı Nirvanası Arayışında”. Yazar, bir veri sorgu motorunun, iş yükünün spektrumunun bir ucunda OLTP’den diğer ucunda analitik verilere kadar desteklenmesi için karşılaştığı zorlukları ayrıntılı olarak ele alır. Bu kitap, bir veri tabanı motorunu veya sorgu ve depolama motorlarının bir kombinasyonunu, iş yükü gereksinimlerini karşılamak için değerlendirmek için bir rehber olarak kullanılabilir.

(2) Veri analitiği alanında son yıllarda çok şey değişse de, “Bozucu Analitik” adlı kitap, analitik değer zincirindeki ve analitikle endüstriyi bozan iki tür bozulma hakkında konuşuyor.

(3) Okuduğum en iyi teknoloji iş metinlerinden biri, “Stratejinin Sınırları” adlı kitaptır. Yazar, Research Board’un (Gartner tarafından satın alındı) kurucularından biri tarafından yazılmış ve şirketlerin, computing dünyasındaki gelişmelere nasıl uyum sağlayacağını araştıran bir düşünce kuruluşu hakkında çok ayrıntılı notlar sunuyor.

Bu röportaj, birçok konuyu ele alan ve açık kaynak hakkında çok şey öğrendiğim ilgi çekici bir sohbet oldu. Daha fazla bilgi edinmek isteyen okuyucular, SPR kurumsal web sitesini veya Erik Gfesser’in web sitesini ziyaret edebilir.