Turknet Noctools Mühendislik Ekibinde bir mikro hizmet dönüşümünün hikayesi
Turknet’te birkaç ay önce yeni monitoring ekosistemi Sauron’u hayata geçirdik. Bu yazımda bu mikro hizmet dönüşümünde yaşadıklarımızdan bahsedeceğim.
Motivasyon
Öncelikle şunu söylebilirim ki, monitoring bir şirkette her ekibin hatta tüm organizasyon seviyesinde dahi olması gereken bir araçtır. Yani liderlik ekiplerinin de baktığı borsa gibi izlediği ve şirketin hedeflerini belirleyebileceği bir ortak ekran mutlaka olmalıdır.
Bizim hikayemiz ise turknet’in network operation center takımlarının günlük , haftalık, aylık ve yıllık rutinlerini,çalışmalarını,bir sorun anında ki davranışlarını izlemek ve onların bu süreçlerini daha efektif hala getirmekti.
İlerde de bahsedeğimiz üzere site reliability engineering adı verilen bir alanı keşfettik aslında. 2007’den beri turknet noc ekiplerinde atılan adımlar genelde telco şirketinden beklenen vizyoner adımlar olmus . Yalnız hiç biri yazılım ekosistemini içeren bir adım olmamış.
“A software ecosystem is the interaction of a set of actors on top of a common technological platform that results in a number of software solutions or services.” Software Ecosystem: Understanding an Indispensable Technology and Industry by David G. Messerschmitt and Clemens Szyperski
Bahsedildiği üzere kompleks bir sistem aslında bir ekosistem olarak adlandırılır. Kendisine göre bir karakteri,süreci ve kültürü vardır. Öncelikli işimiz o patternleri anlamaktı.
Turknet’de dikey ürün ekipleri olarak ne yazık ki çalışmıyoruz. Açıkçası bu ürün ekiplerinin tamamı bağımsız birer startup olarak otonom olarak çalışamıyor. Hepsi build oldugunda bir şirket oluşmuyor. Bir ekibi var eden unsurlar aslında kendi başına çalışması gereken ekiplerden oluşuyor.
Örneğin; veri bilimi , qa , devops gibi ekip üyeleri squad ekiplerine dağılmış ve kendi bağlı ekipleri olan takımlar. Ama olması gereken ise bulundukları takımın üyeleri olmaları ve o domain’e gönül vermeleriydi. Bu mimarinin de kendi özgü faydaları var ama conwey law’a uygun olmadıgı aşikar. Bu da agile olunmasını engelleyen ana unsur diyebilirim. Kendi verdiğimiz isimle açıklayacak olursak “Enterprise Agile” 🙂
Bu zarar gibi gözüksede bu durumun faydalarını da çok gördük diyebilirim. Örneğin; squad takımlarının dışında kalan ekiplere vizyon katacak işleri anlatırken , içinde bulunduğumuz yoğunlukta ve çözmemiz gereken onca problemin içinde bu sorumlulugu eskale edebildik . Yani fikir verdik , ufuk açtık ama tutup bunu projelendirmedik. Zaten agile ekiplerinde bu kadar sorumluluğa her zaman karşı çıkmışımdır. O yuzden TurkNet’in bu organizasyon yapısı bazen çok işimize yaradı. Ama böyle devam etmemesi ve her takımın üyelerinin kendi başına bir startupmış gibi çalışmaya başlaması gereken bir durum. Proaktif olmak bunu gerektirir.
Bu konu hakkında ki 3 stage of fast growing startup olarak nitelendirilen bir çalışma var. Bir startup gibi olamamamızın ama aynı zamanda enterprise seviyesinde ilerleyemeyeceğimizin sebebi aslında çok uzun zamandır teknik alt yapılara yatırım yapılamamış olmasıydı. Herhangi bir yöntem sanırım denenmemiş bile. O yuzden noctools engineering ekibi olarak takip ettiğimiz adımlar global standartlara uyduğunu söylemem 🙂
Kaos aslında buradan kaynaklı. Ürün ekiplerinin early stage’de , engineer’ların scale stage’de , board member’larında aslında late stage’de olması şirketi uzun bir süre üzmüş olmalı ki 2007’den beri telco şirketi olarak adım atılmış ama hiç biri software defined olamamış.
Noctools ekibi olarak gördüğümüz boşluk buydu ve bunun için çok sağlam plan yapmamız ve ölüm vadisine girmemiz gerektiğini o gün anladık 🙂
2007’den beri atılması geciken adım
Hedefimiz aslında teknolojik altyapıyı iyi analiz edip sıkı bir plan ile migration etmekti. Ama işimizin aslında o kadar da kolay olmadığını öğrendik. TurkNet’i TurkNet yapan aslında kendine has network topolojisiydi. Sürekli değişen ,reactive olan ve değişen ihtiyaçlara göre tekrar şekillenen bir yapısı vardı. Backbone adı verilen omurga cihazlar ve aralarında ki bağlar aslında örümcek ağından hiç bir farkı olmayan bir sistemi andırıyordu.
Daha önce de bir çok tool,in-house solution vs denenmiş olmasına rağmen tam istenilen performansı gösterecek durumda değillerdi. Aslında irili,ufaklı bir çok tool gözlemledik ama pandemi etkisi olmadıgı için kendine özel bir kapasite ile çalışan sistemlerdi. Ölçek aşamasına süreci iten kısım ise pandemiydi. Ve migration strategy’si gerekiyordu.
Legacy app’lerden bazıları netmon,cacti,smokeping,port listener,arıza anons sistemi (vae,yapa,fiber)vs. vs. gibi bir çok birbirinden çok farklı yerlerde ama aslında analiz ettikten sonra anladığımız kadarıyla hepsi aslında puzzle’ın bir parçası olan bir ekosistemi oluşturuyordu. Aslında distiributed bir sistem içinde olduğumuz netti ve o dünyanın kuralları geçerli olacaktı.
Yani örümcek hislerimiz bizi yanıltmadı 🙂 Hepsinin tek bir amacı var. Icmp ve Utilization. Bu 2 konu için bu kadar cok tool inşa edilmesi ve reliability & scalability konularına değinecek kadar yükün olmaması sistemi bir yere kadar idare etmiş. Ama aslolan ise customer demand’i arttığında sağlıklı bir sonuç veremediğini görmemizdi. O yuzden replatforming kaçınılmazdı.
Böylece içinde bulunduğumuz dünyanın distributed zeminde oldugu konusunda hiç ayrıma düşmedik. Ekip olarak bunun farkına vardık diyebilirim.
1990’larda popüler olan distributed computing yaklaşımını günümüzde ki teknolojinin evrimine ve microservice konseptlerine göre tekrar yorumlamamız gerekiyordu.
Burada deyinmek istediğim nokta aslında atılması gecikmiş bir nokta idi. Distributed Computing & Software Defined Network.
Bu zamana kadar ki yapılmamış olanı yapmamız gerektiğini anladık . Computer science’ın en belalı konusu olan networking’i iyi anlamamız gerekiyordu. Bu zamana kadar ki tüm geliştirmeler application development seviyesinde kalmış ve domain’e hit eden kısımlar ile ilgili bir learning curve olmamıştı. Domain’in zorluğu veya kompleks oluşu çekincelere yol açtı ama aslında bu bir fırsattı. 🙂
Software Defined Network
Öncelikle networking konularının zor olmasına aşinaydık. Açık konuşmak gerekirse benim de okulda en zayıf olduğum dersti diyebilirim. Yalnız container mimarilerinin son 10 yılda öyle geliştiğini gördük ki sanallaştırma ile birlikte home user’ların bile kullanacağı duruma geldiği inkar edilemezdi.
Kendi adıma konuşacak olursam zaten vagrant gibi toolara cok vakıftım. Ama ekibi hızlı onboard edebilmek adına docker’ı benimsememiz gerekiyordu. O yüzden öncelikle legacy assetlerimizi dockerize ederek basit bir dev box haline getirdik. Bunun jr. arkadaşlarımızı nasıl hızlı onboard ettiğini anlatamam yaşamanız lazım. O kadar efektif debugging ortamlarımız oldu ki sorun maillerine gerçekten çok hızlı yanıtlar verir olduk ve hızlı anlayıp,analiz edebildiği için arkadaşlarımızın özgüvenine yerine geldi. Onların gelişimine yakından şahit olmak cok onur vericiymiş bunu anladım .
Bu container yaklaşımımız şirket hedefiydi. Ama buna inanmamız oldukça güçtü. O yüzden production da deneyimlemek oldukça uzun bir sürecti. IT ve infra ekiplerinin cok hızlı gelişmesini beklemek her kurumsal şirkette çok zordur.
Biz ise ekip içinde her ürünü localimizde dockerize ederek ortam agnostik development yapabildiğimiz için çözüm üretebilmemiz hızlı oluyor , ortam sorunlarından bağımsız business logic’e odaklanabiliyorduk. Zaten amacım dockerized debugging & old schools deploymenttı . 🙂 Bu infra ekiplerimiz hazır olana kadar ekibin cloud aşinalığını artıracak ve zamanı geldiğinde aslında hiç major sorun yaşamayacaklardı. En azından planım buydu 🙂
Öyle de oldu çok şükür . From container to k8s eğitimine katıldığımda başka şirketlerin de bu kavramı benimsediğini gördüğümde aklın yolu bir olduğu için ne yalan söyliyeyim benim de özgüvenim arttı. Onlar da bizim ki gibi önce local dockerda calışıp vmlere deploy edip sonra orchestration ortamlarına deploy ederek bir rampa görevi görmüşler. Bu cok zekiceydi. Sanallaştırma teknolojisinin artık okullarda müfredat olarak bile okutulabilmesi taraftarıyım. Çünkü öğretim metodolojisi olarak metoforik bir anlatım içeriyor. Çok zor konuları çok rahat anlayabiliyorsunuz. Aynı konu network için de geçerli. O dünyada da mininet ,packet tracer gibi network simülasyon toolları var ve sonuç inanılmaz.
Mvp de zaten her şeyin önce lean version’ınını yap demek değil miydi ? Bu yaklaşımın engineering perspektifinde ele aldığımızda bir ekibi buna adapte edebilirsiniz ve onların learning ve teknoloji curve’unu artırabilirsiniz.
Zamanla innovation’a olan adaptasyona herkes inanacak.
The age of distributed computing & microservices
Yukarda da bir görselini koymuştum , doğası gereği network bileşenleri dağıtıktır ama artık microservicelerin dünyasına göre yeniden design edilmesi gerekiyordu.
Son 5 yıldır endüstri 4.0’ın da etkisi ile zaten hayatımızda herşeyin dağıtık olduğu aşikar. Kernel dağıtıktı. İnternet dağıtıktı. Nicola Tesla’nın ortaya attığı alternatif akım dağıtıktı. Aslında evrende herşey dağıtıktı ama aralarında dikkatli baktığınızda göreceğiniz bir dependency’ler vardı. Sanırım asıl mesela bu context’i anlayabilmek. Microservice’lere hiç bir açıdan bakmamıştım.
Qos ’un reactive manifestosunda yeri var bu doğruydu ama networkingde de bu application level’ında bildiğimiz konuların low levelda da bir benzeşimini görmek ufuk açıcıydı. Aslında OSI referans modelinin 10 yıldır yukarsında çalısan biri olarak ilk defa fiziksel katmana kadar aslında yazılımın hala yukarda ki bileşenlerinden bir iz taşıdığını görmek entellektüel zekamızı artırdı diyebilirim. Yani high level design olarak bildiğimiz microservices
http,tcp,sync , async api,message brokers vs. vs. gibi konuların aslında temelinde yatan konu low level’ı anlamak olduğunu network domain’ine girince anladık.
Artık hayatımızda proxyler, reverse veya forward proxyler,cdn,edge location,az veya region gibi kavramlar olduğunu ve aslında microservislere ilham kaynagı olan ve home user olarak basite indirgenmiş bu prensiplerin olduğunu ve bunların ana vatanı olduğunu biliyoruz.
Kim pop,ssg,bng,router,switch gibi aletlerin kendi içinde oluşturdugu ağların dünyasında cloud,k8s ,microservices , distributed computing gibi oldukca sığ olarak anladıgımız konuların asıl ilham kaynagı olabileceğini soyleyebilirdi ? Bunu idrak etmek bence asıl mesele.
Ve şirkete A+ engineer’ları çekmenin hiç bir zaman linkedin postlarının olduğunu düşünmedim. Hali hazırda opensource edemeyeğimiz bir mono repolarımız vardı bu doğru ama en azından ilham olabilir diye awesome readme’lerin engineerların hayatında önemli bir yer kapladığını bildiğimiz için sauron adını verdiğimiz ürünü şirketin ortak github hesabına koyduk.
Amacımız , oldukca eski teknolojilerin olduğu ama dünyamızında k8s ve cloud’a evrildiği bir noktada ecommerce,fintech gibi şirketlerin oldukça popüler olması baz alındığında benim gibi şirket kültüründen değilde ufuk açıcı işlerin insanı back to basic’e götürmesi gerektiğini düşünen biri olarak bu tip scale aşamasında ki şirketlere A+ engineer’ları çekmek için mıktanıs olmaktı.
En azından bu fikre hala inanıyorum. Umarım başarabiliriz. Çünkü kültürün değişmesi için önce o kültüre sahip engineer’ları bir hayale inandırmak ve bir araya toplamak lazım 🙂
Clean DDD
DDD ’nin komplex problemleri kendi başına ele alın ve sorunu domain’in kalbinde arayın felsefesini son 3 yıldan beridir biliyordum, etkilenmiştim. Ama organizasyon seviyesinde de benzer pratikleri kullanacağımız ekip olarak hiç aklımıza gelmemişti. En azından felsefe şişede durduğu gibi durmuyormuş bunu anladık 🙂
Ekipleri bölmek , Domain boundarylerini çıkarmak , sınırları yönetmek vs vs. gibi işlere organizasyon seviyesinde tanık olmak ufuk açıcıydı. Açık konuşmak gerekirse büyük resmi göremeyen herkes bundan rahatsız oldu. Ama kendi ekibim adına konuşacak olursam bundan zevk almaya bile başladık. Eğer nereye gideceğiniz konusunda bir anlayışa sahip değilseniz hiç bir şirket ve ülke de rahat edemezsiniz. Dışarı da iyi bir şirket yok. Tahammül edebileceğiniz kadar bir hayaliniz ve o hayale ulaşacak sabrınız olmalı. Alimlerimiz boşuna dememiş ; rahatlığı sıkıntı da ara diye 🙂
O yüzden bu product manager’larımızdan bir arkadaşımızın tabiriyle mitoz bölünme hala devam ediyor. Artık nereye kadar parcacık fiziğine kadar gideriz bilmiyorum ama zombi mikroservislerin anti pattern oldugu bir dünyada sanırım zombi ekiplerde oyle olacak. Conwey law’ı bir kez daha hatırladık. Eger iletişim kötüyse demek ki ekipleri bölmek de verimsiz olabiliyor. Bunun toparlanacağını umuyorum.
Uzun süre teknoloji ekibinin başsız kaldıgı bir case’de bence takımlar olarak iyi bile idare ettik. Kimse kusura bakmasın bu squad ekiplerinin açık bir başarısıydı. Neyse ki board memberlarımız sesimizi duydu da alanında oldukça iyi bir cto göreve başladı.
Neyse çok uzattım 🙂 Vermek istediğim mesaj Ddd’yi clean hale getirmekti ki bu kolay olmuyormuş bunu anladık . İliklerimize kadar anladıklarımızın basında Ortak bir dilin önemi,Sınırlar herşeydir,Komplex sistemlerde agile değil spiral model işe yarıyor,Data inconsistency tam bir bela gibi çıkarımlar vardı ki ekipler arası dağılan yazılımlar bu inconsistency’e sebep olabiliyor.
Context map candır diyebiliriz 🙂
DDD’yi clean bir şekilde anlamak , lean düşünebilmek, aslında lean product development’ın da kapısını aralıyor ve ürün ekiplerimizinde hayatında lean’in benimsemesini sağlıyor. Hatta iş birimlerimizinde.
Açık konuşmak gerekirse en büyük hayalim bu konseplerden birini kullanabilmekti . Ne yazık ki o kadar evrilemedik ama inanıyorum , bir gün bu seviyeye geleceğiz .
Clean ddd demişken domain’i basite indirgemek için bazı engineering setuplar kurmamız gerekiyor ki buna fitness function diyorlar. Öncelikle ddd , sınırlara ve complexity’e dikkat çekerken o sınırları korumanın bir yolu da fitness function olduğunu idrak ettik diyebilirim. Herşeyin birbiriyle bağlantısı var , inanılır gibi değil 🙂
Building evolutionary architecture nitelikleri olarak bize hitap eden kavramlar aslında şunlar; adaptability, autonomy, availability, configurability, correctness, effectiveness, durability, usability, failure transparency, fault tolerance, maintainability, manageability, scalability, stability, traceability, testability.
sonar cloud,azure ci/cd pipeline,inline functional test,unit test gibi teknikler ops ve qa engineering ekiplerimizin de daha yerli yerine oturmadığı durumda bize elimizde ki imkanlar ile impact yarabileceğimiz konusunda ışık tuttu.
Aslında e2e test primadini bilirsiniz . Biz başlangıcta olaya biraz farklı yaklaştık.
Biz test quadrant olarak q3,q1,q2,q4 şeklinde bir sıra izledik.
Agile takımlarımızın görevleri, düzenleri, yerli yerine oturana kadar ve learning curve’leri artana kadar kendi içimizde bu şekilde idare ettik diyebilirim .
Tabi burada Meltem Makaracı’nın müthiş azmi ve istikrarı ekibe çok iyi kaldıraç oldu. Bu konu da aldığım insiyatife omuz verdiği için teşekkürlerimi borç bilirim.
Gitops Mindset
Aslında bu konu benim uzun zamandır merak ettiğim ve önceki şirketlerimde de bu işin artık bir best practice’i yok mu diye arayışa girdiğim bir konuydu. Netice de bu zamana kadar el yordamıyla bu konseptlerini uygulamıstık ve cloud native değildi. Vmler üzerinden çalısan sistemler hem dil hem platform seviyesinde farklılık gösteriyordu . Ci/cd bilmek sadece konsept olarak kalıyordu ve tech stack değiştiğinde yine atıl kalıyor ve yeni toolları öğrenmeniz gerekiyordu.
Bu işin artık böyle yürümeyeceğinin farkına benim gibi weave works şirketi de artık varmış olmalı ki gitops adında bir leanpub’da ebook yayınladı ama early registeration olarak .Yani sadece duyuruldu ve erken register olanlar için beta sürümünü göndereceğini bildirdi.
Sürü psikolojisinden nefret ederim ama bir çare bende subscribe oldum çünkü bu konu da ki bilgiye açlıgıma engel olamadım 🙂
Aslında adamlar noktayı koymuşlar. Yine örümcek hislerim beni yanıltmadı ve home user tanında fancy bir arayüzü olan bu tool’dan agile prensiplerinin basında gelen ci/cd perspektifine olan mindset’i öğrenebileceğimiz konusunda sağlam bir anlayışımız oldu.
Her zaman tools ve productlardan engineering’in zor konularını öğrenebilirsiniz çünkğ okuyarak bu kavramları asla derin öğrenemezsiniz. O yüzden bende bunu kavramları ekibimle paylasarak bir mindset değişikliğine zemin hazırlamaya çalıştım diyebilirim. Önemli olan başarmak değil bir tohum ekebilmekti her düşündüğümüzü live’a almak gibi bir beklentinin mümkün olmadığını biliyorduk. O yüzden ekibi şirkete değil hayata ve problemler karşısında ki tutumlarımızı nasıl geliştireceğimize hazırlamak önemliydi. Delivery pipeline’lar benim hep merak ettiğim bir konu iken artık ekibimiz için de bunun bir sorun olması niyetindeydim. Dönüşüm ürün hatlarını pipeline’ara ürünün ihtiyacına özel olarak dizilmesi gerektiğini anlamak ile başlar.
Şuan için sağ taraftaki görsele henüz evrilemedik ama sol taraftaki süreci sağ tarafa zemin olacak şekilde design ettik. Yani geçişin sonra ki süreçte çok basit olması niyetindeyiz.
Bunu anlayabilmek önemli bir kültür değişimine zemin hazırlamak için bence bir başlangıç olabilir. Önce sonucu göster sonra ekibi onu geliştirmeye it. Öğrendiğim en önemli fikirlerden biri bu oldu. Çünkü sebebini bilmeyen insanlar çalışmak istemiyorlar ve ekip içi homurdanmalar oluyor bu da haliyle retro’lara yansıyor. O yuzden sorunları açık olarak konuşmak ve şuan o nokta da değiliz ama sebat gösterirsek roadmap’imiz buna evrilebilir şeklinde yapılan her açıklama ekibi motive edebiliyor.
Tabi onun da bir sigorta poliçesi var. Zaman uzarsa ekibiniz size ve yöneticilerinize , şirkete olan inancını yitirebilir. Doğru zamanda doğru feedback’i vermeniz gerekir.
3 Pillars Observability
Bu konu da distriuted system’lerin en önemli konusu olarak biliniyordu. Bu konuya eğilmemiz gerektiğini biliyorduk ama sauron’u design ederken application seviyesinde değilde cam gibi bir turknet’in ülke genelinde ki sistemlerini monitor etmemiz gerektiği anlaşılınca tabi konu öncelik kazandı.
Bilindiği üzere konu bu ama aslında bizim domain’imiz de konunun bu kadar olmadığını , bizden çok iş birimlerine bir roadmap çizmesi ve bu birimlerin head’lerinin görev başına geldiğinde turknet noc dünyası üzerine business geliştirmelerini sağlamak olduğunu anladık.
Yani konunun sadece bir monitoring değil de SRE (Site Reliability Engineering) işi olduğunu idrak ettik diyebilirim.
Bu konu başlı başına bir iş aslında. Ve yukarıda hatırlayacağınız üzere 2007’den beri atılmakta geç kalınmış veya dikkat edilmemiş bir konu bile olabilir. Bize nasip olduğu için hem ekip hem kendi adıma çok mutlu oldum .
Çünkü bu katmanların her biri için tool geliştirmek aslında klasik microservice anlayışından daha derin bir anlayışa bizi iticeğini düşünmemiştim.
Öncelikle SIEM adı verilen incident logging tool’undan tutun, cam gibi tüm network elementlerinden gelen logları monitor etmeye ve stream’ler üzerinden iş birimlerine , journey ekiplerine api vermeye kadar tam anlamıyla bir ekosistem design ettik.
Network Planning Team Lead’imiz Ahmet Çoban’ın katkılarıyla ve gösterdiği yolda hem network domain’ini anladık hem de ürünü doğru design edip etmediğimiz konusunda çok önemli feedbackler aldık. Yeni kariyerinde çok başarılar dilerim , seni özleyeceğiz Ahmet Çoban 🙂
Özel eğitime gerek yok , onunla çalışıyorsanız zaten bir network engineer gibi düşünebilirsiniz.
Customer care online için kurumsal müşterilerimize verdiğimiz sla sözlerini,noc ops ekiplerimiz için arıza tespitlerini ve planning ekiplerimiz için ise gerekli olan yerlerde kapasite artırımına gidilmesi gerektiği yönünde tüm birimler için önemli bir impact olan bir tool diyebiliriz. Multi Tenant Sauron as a Service olarak adlandırdığımız bu tool inanıyorum ki TurkNet noc ekiplerine çok iyi gelecek fantastik bir tool oldu.
Çünkü biliyoruz ki TurkNet’i turknet yapan sahip olduğu bu kendine has network topolojisi diyebiliriz. O yüzden böyle bir tool’u no code low code olarak alamazdık. Piyasa da bulunan hazır bir çözüm yoktu. Hatta tubitak arge projesi olarak e2e datacenter monitoring olarak bile kullanılmak için bazı hazırlıklar oldu . Tam anlamıyla o isteği karşılamasa bile ilham kaynağı olduğuna eminiz 🙂
Şöyle bir ss’i koyacak olursak ki hassas veriler olduğu için daha fazla bilgi vermemiz çok uygun olmaz . Ülke geneline konuşlandırılan tüm network ekipmanlarından alınan bir veriler özelinde toplam trafiği cloud native bir ortamda görebiliyoruz. Cloud değil biliyorum henüz değil ama amaç konsept olarak cloud native olacak şekilde bu kaldıracı geliştirmekti.
Dashboard’da görüleceği üzere Antalya pop noktasında olan biten herşeyin cam gibi gözükmesi distributed sistemlerde ki olmaz ise olmaz olan bir konuyu anlamamızı sağlıyor. Eger Kompleks bir domain’de çalışıyorsanız bu tip dashboardlar sizin gözünüz kulağınız olacaktır. Henüz dashboard’da ki tüm veriler canlı değil ama hedefin bu olması bile oldukça motive edici.
Amacımız ise bunun gibi ülke genelinde tüm pop’ları gözlemleyebilmek . Bunun için en önemli öğrendiklerimizden biri bu adımı atabilmekti. Çünkü modern toollar olmadan bu imkansızdı.
Bunun gibi bir çok sistemleri cam gibi monitor edebildiğimiz, üzerine alertlar koydugumuz, tholdlar eklediğimiz ve diğer toollarımızı hatta ekiplerimizi trigger ettiğimiz bir ekosistem haline dönüştü.
Bu görselde de gözüktüğü gibi öncelikle diriliş sonra kuruluş sonra yükselişe geçmemiz gereken 3 aşamalı bir roadmap için full konsantre çalışılan 1.5 yıl sonrasında elde ettiğimiz ürünün tırmanış hikayesini görebilirsiniz. Bu aşamadan sonra business ile it strategy’yi yoneten yöneticilerimize daha rahat hareket edebilecekleri bir manevra kabiliyeti kattığımıza inanıyoruz.
Event sourcing’in her alanda cok fantastik bir çözüm olduğuna sahit olduk.
- Event Sourcing
- CQRS
- Event Driven Architecture
- Schema Evolution
- Software Evolution
- Schema Versioning
- Deployment Strategy
- Data Transformation
- Data Conversion
3,5,8 ve 9 nolu maddeler aslında sauron’un temelini olusturan maddeler ve bize de ilham kaynağı olan kavramlar diyebiliriz.
Event sourcing’in oldukca fantastik bir konu olduguna ve konunun bir de dark side’larının olduğuna dikkat çeken bir makale var. Linkini buraya bırakıyorum .
Data Engineering & Architecting
Öncelikle şunu itiraf etmeliyim bir önceki chapter’da da bahsettiğim üzere 3 ve 5 benim uzmanlaşmaya çalıstığım bir alandı ve o birikimlere dayanarak bir sistem kurmayı planlıyordum . Zamanla anladık ki 8 ve 9. adım olmadan bu mümkün olmazmış ve bu konuda klasik developer’dan öte daha farklı ve derin skilleri olan bir arkadaşa ihtiyacımız vardı.
Veri bilimi ekibine sahip olmamız TurkNet için büyük bir kaldıraçtı ama noctools’un musfafa can uslu gibi bir engineer’a sahip olması elmanın diğer yarısının uyumu gibi oldu . Onun bir cok skillerinden faydalanıldığı gibi bizimde data engineering kaslarından faydalanmamız data transformation , conversion ve etl gibi gibi çalışmalar konusunda insiyatif alması yine yukarda bahsettiğim üzere 2007’den beridir gelen network engineering’ine data perspektifinden bakması çok büyük bir katkı sağladı . Bu kavramlar hepsi toplandığında “Software Defined Networking”’i doğurdu. Artık ekibe hangi profillerde engineer’ların lazım olduğunu ve hangi niteliklere sahip olması gerektiğini biliyoruz.
Bu görselde ki gibi metafor aslında sauron’u ne iş yaptığına ve yukarda bahsetttiğim süreçlerin geliştirilmesi için neden data engineering’e ihtiyaç duyduğumuzu özetleyebilir. Tüm verilerin toplanmasından tutunda da üzerinde etl koşarak anlamlı ve kullanışlı ekranları çıkartılmasından ayrıca network ekipmanlarımızın naming conventionlarının bir standartizasyonuna olan ihtiyacı görünür kılınmasına kadar olan bir çok süreçte data engineering gerekiyordu. Bu konu da Mustafa’ya bir kez daha teşekkürlerimi iletmek istiyorum.
İtiraf etmem gerekirse ben dahil bu kadar skillere sahip değilim. O yüzden şirket içi bu konuları içeren eğitimler talep ettik. Umuyorum hem dışardan hem içerden tüm bilgilerimizin ve edindiğimiz deneyimlerin paylaşıldığı bir kültür yakın zamanda gercekleşir. Ve TurkNet , özellikle noc ekiplerine uygun profillerde engineer’larını bu şekilde yetiştirir.
Mustafa ve Benim önderliğimde teknik perspektif olarak , Ürün Geliştirme Yöneticimiz Büşra Yapıcı önderliğinde de business perspektifinde bu zamana kadar olan ve TurkNet evreninde sıkışan bir tool geliştirme ihtiyacı ve bundan sonra da bu tip işlerin nasıl geliştirileceği ile ilgili ekolün benimsenmesi gereken bir alanın kurulmasında ki çabalarımız sonuç verdi. Ekibimizin bu kültür etrafında kenetlenerek şirketin noc ekiplerinin kullanımına sundugu bu ürün özelinde göstermiş oldukları eşsiz çabaları için sonsuz teşekkürlerimi borç bilirim.
Bu tekniklerin geliştirilmesinde hem engineering hem business anlamında universal level’da bir innovation’a öncülük eden bir ekip olmaktan da onur duyduk.
Innovators alanında data + architecture olarak dünyanın gittiği yöne doğru gidişimizin ve endüstri 5.0 ‘ın trend konularını içeren ekosistemin bir parçası olma niteliği taşıyan çalışmalarımızında haklı gururunu yaşadık.
TurkNet ve endüstri için küçük olabilir ama Noctools Engineering Team için büyük olduğu ve çok fazla öğretici olduğunu düşünüyorum. Bence herkes nasibine düşeni bu uzun soluklu migration planımızdan aldı diye inanıyorum.
Son olarak;
- Mustafa Can Uslu — data sciencist
- Büşra Yapıcı — product manager
- Ahmet Çoban — lead core network engineer
- Burak Sarpkaya — developer
- Meltem Makaracı — qa engineer
- Gizem Güngör — devops
- Ali Demir — developer
- Serdar Kekik — technical product manager
- Gokalp Öztürk — ex developer
- Adnan Okay — ex system engineer
- Servet Bulut — ex dba
- Hicret Kilazer — ex devops
- Gönenç Özgan — ex devops
- Pınar Bakan — ex devops
Arkadaşlarıma turn-over’lar olsa da yılmadan 1.5 yıl boyunca motivasyonlarından hiç bir şey kaybetmeden hedefe kitlendikleri için sonsuz teşekkür ederim.
Bu sürecin tamamen teknik , data ve infrastructure özelinde ki olan yazımızı da serinin 2. post’u olarak paylaşmayı düşünüyoruz.
Görselden de anlaşılacağı üzere doğru ürün dogru yetkinlikte ki ekip ile geliştirilir. Ve bu dengeyi sağlamak kolay olmadı ve hala kolay değil 🙂
Mühendislik ve aynı zamanda yönetim becerilerimizi geliştirmemiz konusunda bize ilham kaynagı olan bazı kitaplar;
- domain driven design
- e2e Qos network design
- enterprise integration patterns
- site reliability engineering
- effective engineering
- how to solve it
- the goal
- the dip
- the art of war
- the system architecting for organizations
- implementation patterns
- microservice patterns
A Lessons in Learned
PS : The art of system design is the Picking the right architecture = Picking the right battles + Managing trade-offs
Sauron be with you 🙂
