Son zamanlarda IT biriminizden Kubernetes, OpenShift, Docker, Konteyner ya da DevOps kelimelerini çokça duymaya başladıysanız ve bir yatırım kararı verme aşamasındaysanız, bu yazı hem sizi ikna etmek hem de benim bu alandaki düşüncelerimi sistematik bir şekilde kayıt altına almam için yazıldı.

IT, bir birim olarak başlangıçta katma değerin artması için iş birimlerine destek olması ve işleri hızlandırması için kuruldu. Bu birim yıllar içindeki teknolojik gelişmeler, çoğu sektörde IT’nin önemini şirketin kaderiyle neredeyse aynı seviyeye getirmiş durumda. Bugün örneğin finans sektöründe çalışacağınız bankaya karar verirken sadece size sunduğu olanakların dışında şubesiz bankacılığın ne kadar gelişmiş olduğu da seçim kriterlerinizden birisi haline gelmiş durumda. Hal böyle olunca da rekabette öne geçmek için güçlü, pazara ve değişikliklere kolay adapte olabilen ve hızlı bir IT birimine ihtiyaç olduğu gerçektir.

IT her ne kadar böyle önem arz eden bir birim olsa da, firmanın kendisi bir IT şirketi değilse tek başına çalışabilecek bir birim değildir. Bu sebeple bu birim değer üretebilmek için çevresindeki iş birimlerinin isteklerini almalı, bunları işlemeli, anlamlı sonuçlar üretmeli ve bunu iç ya da dış müşterilerine sunmalıdır. Aksi halde Dünya’nın en güçlü, en parlak, en cici, en harika sistemi de kurulsa da IT birimi bir değer üretmekten uzak kalacaktır.

İş birimleri ise IT ile verimli çalışmanın bir yolunu uzun süredir aramakta bazen araya iş biriminin isteklerini IT’nin diline çevirecek (ve elbette tersini de yapacak) ek aktörler koymakta ya da PMO (proje yönetim ofisini) ayrı bir yapı olarak düşünüp bu işin PMO tarafından sahiplenilmesini beklemekte. IT okur yazarlığı daha düşük olan iş birimlerinde beklenti ve isterlerin iyi aktarılamaması, IT’nin uğraştığı onlarca projenin içinde her birime işin gerektirdiği ölçüde zaman ayıramaması (siz hiç işim acil değil diyen birini gördünüz mü?), IT’nin çalışmaya ve değer üretmeye devam edebilmesi için kendi içinde de projeler yürütmesi gerekmesi gibi faktörleri de eklediğimiz zaman uyumlu çalışması zaten zor olan sürecin iş birimiyle IT arasında zaman zaman kanlı bıçaklı kavgalar çıkaracak kadar kötü bir hale geldiğini şu ana kadar ya yaşadık ya da çevremizden duyduk.

Peki, günün sonunda sadece bir yazılım olan Kubernetes size nasıl yardımcı olabilir? Dertlere derman, açlara yemek, evsize ev, yalnıza dost olabilir mi bir yazılım? Kubernetes elbette sadece bir yazılım fakat Kubernetes verimli kullanabilmesi için IT ekibinizin işe bakış açısını değiştirmesi gereken ve DevOps pratiklerini uygulamaya başlamaları için iyi bir havuç konumunda. Dolayısıyla yalnıza dost olmasa da sizin daha çevik bir IT’ye sahip olmanız için Kubernetes biçilmiş kaptan olabilir.

IT’ciler ne kadar farklı olabilirler ki?

Her gün takım elbise giyerek gittiğiniz bir işiniz varsa IT’cilerin farklı insanlar olduklarını en azından kıyafetlerinden anlamışsınızdır. İster yazılım geliştiriyor ister sistem yönetiyor olsunlar (çoğu) IT’ciler de yaptıkları işin kendileri dışında kimse tarafından anlaşılmayacak ve diğer işlerle kıyaslanamayacak kadar zor, karmaşık ve farklı olduğunu düşünür. Bunun için onlara kızamasınız zira biz de (çoğumuz) kendi yaptığımız iş için çok benzer düşüncelere sahibiz. Bu düşünce dışarıdan bakıldığında doğru gibi gözükse de hem sizin işiniz hem de onların işi aslında o kadar da karmaşık değildir.

Zihinsel emek gerektiren hemen her iş gibi IT işleri de aslında iki çok genel kategoriye ayrılabilir. Bunlar tekrarlayan ve bilişsel işlerdir. İlk kategoride yer alan işler sık sık yaptığınız, tekrarlarken çok fazla düşünmeniz gerekmeyen işlerdir. Günlük rutinin bir parçasıdırlar ve fark etmeden gerçekten vaktinizi alabilirler. Öte yandan bilişsel işler üstünde zihin emeği harcamanız gereken çoğu zaman ortaya yeni bir fikri eser çıkmasına sebep olan bir süreçin yaşandığı işlerdir ve kural olarak işinize kattığınız değer tam da bu noktada ortaya çıkar. Her ne kadar IT’ciler her işin bilişsel bir iş olduğunu düşünmeye yatkın olsa da (bir yazılım geliştiriciyi gerçekten kızdırmak isterseniz ona gelecekte kodların robotlar tarafından yazılacağını söyleyin!) durum tam olarak böyle değildir ve bazı işler mutlaka kendilerini tekrar ederler.

Peki, Kubernetes tekrar eden işleri sizin adınıza yapan bir robot mudur? Kubernetes her tekrarlayan işe biraz bilişsel katkı da sunan hipersonik yarı organik tam elektronik bir yapay zekâ mıdır? Cevap hayır! Dertliye derman olmayan, bizim adımıza kod yazamayan bu Kubernetes’e biz neden para vereceğiz o zaman? Cevap için okumaya devam…

Kubernetes dertlere derman, kurak topraklara yağmur, düşküne yoldaş mı?

Eliyahu Goldratt’ın The Goal (endüstri mühendislerinin gözleri yaşlı.) kitabı bize bir mühendisin aşk hikâyesini anlattığından çok daha fazlasını anlatmış ve Kısıtların Teorisi’nin ortaya çıkmasını sağlamıştır. Kısıtlar teorisine göre yönetilen bir sistemde her zaman bir ya da birden fazla kısıt vardır ve verimin maksimize edilmesi için tüm organizasyon kısıtın en verimli çalışacağı şekilde organize edilmelidir. Aynı zamanda kısıtın verimini arttırmayan her bir hareket sadece bir illüzyondur ve yapılmasının pek bir manası yoktur verimin artması için.

Bir fabrikada üretim hattına tepeden baktığınızda ya da bir restoranda mutfağa girdiğinizde kısıtın ne olduğunu anlamınız görece kolaydır. Çelik tencere üreten bir fabrikada pres makinesinin kapasitesinin çeliği kesen makineden az olduğunu gördüğünüzde kulp takma makinesine (kendisi ayrıca bir kısıt değilse) ek kapasite yatırımının yapılmasının gerek olmadığına ya da ızgarada aynı anda sadece üç yemek yapılabilirken 4 tane ızgaracının varlığının gereksiz olduğuna karar vermeniz o kadar zor değildir.

Peki, ya aynı durum için IT için de geçerliyse neyin gerekli olup neyin gerekli olmadığına kim nasıl karar vermelidir?

Her bir IT departmanının kısıtı o kurumun organizasyonuna ve birimin organizasyonuna göre değişiklik gösterecek olsa da kısa bir beyin fırtınası ile bu kısıtların çoğu zaman ortak olduğunu söyleyebiliriz. Kısıtlı bütçe, işe göre kısa kalan ekip sayısı, makine parkı ve kapasite eksiklikleri, iş birimleri ile düşük eşgüdüm genellikle kısıtların başında gelmektedir. Bunun üstüne planlama eksiklikleri / hataları, erişilmesi zor teslim hedefleri, AR-GE sürecinin doğasından kaynaklanan gecikmeleri de eklediğimizde bu kısıtlar çoğu zaman dramatik denebilecek sonuçlar doğuracak hale gelmektedir.

Teknolojide yaşadığımız bazı değişimler kısıtların bir kısmının ortadan kalkmasını ya da süreçlerin hızlanmasını sağladıysa da bu değişiklikler yanlarında bakış açısı değişikliklerini pek getirmediği için verimi istenen ölçüde arttıramadılar. Örneğin sanallaştırma öncesi dünyada bir IT projesine başlamak çoğu zaman fiziksel sunucuların satın alınması, mevcut cihazların yeniden kurulması, kablolama yapılması, işletim sistemlerinin yüklenmesi ve yazılımların kurulması gibi pek çok iş gerektirirken sanallaştırmanın gelmesiyle yeni bir ortam kurulması haftalardan saatlere geriledi.

İşte burada durup şu soruyu kendimize sormamız gerekir. Gerçekten bu süre geriledi mi? Gerçekten şu anda ortalama büyüklükteki bir ortamda geliştirici kısa bir işi test etmek için temiz bir sisteme ihtiyaç duyduğunda bunu ne kadar sürede alabiliyor? Saatler içinde mi? Günler içinde mi? Yoksa çoğumuzun yaşadığı gibi haftalar içinde mi? Alınması gereken onaylar, yapılması gereken yönlendirmeler ve verilmesi gereken izinleri düşündükçe iş biriminin belki acil olarak beklediği bir değerin sadece test ortamına aktarılması bile uzun süre alabiliyor.

Bu durumun elbette birçok sebebi var. İlki kendi içinde silolara bölünmüş olan klasik IT yapılanmasında her alt ekibin kendine ait farklı öncelikleri olması. Bu sebeple örneğin sanallaştırma ekibi size hızla yeni makine yaratırken ağ ekibi başka (zaten hep bu networkcülerden yüzünden dertler!) öncelikleri olduğu için basit bir IP tahsisini bile yapmakta yavaş kalabilirler.

Öte yandan bu tarz repetitif işlerin bir değer üretmesi için orada olan kaynak tarafından her zaman sevilerek yapılmadığı da malum. Çoğumuz bizi heyecanlandıran bir işle uğraşmayı bırakıp rutine binen bir işi tekrar yapmaktan hoşlanmayız bu durum elbette IT sektöründe çalışanlar için de geçerli.
Son olarak tekrarlayan işlerde iş her ne kadar çokça yapılsa da yapılış prosedürünün net olmaması veya sadece ekibin içinde 1-2 kişi tarafından yapılabiliyor olması bekleme sürelerini arttıracaktır.

Peki, Kubernetes sıkıcı bir işi eğlenceli bir hale çeviren bir oyun mudur? Yoksa abi sen bunu nasıl yapıyorsun bir anlat da belgesini yazalım diyen bir metin editörü müdür? Cevap yine hayır! Sıkılırken bizi güldürmeyen, yalnıza dost olmayan bir yazılıma niye yatırım yapıyoruz o zaman?

Biz her ne kadar IT bir fabrika değildir kendi içinde çok kompleks süreçleri olan farklı uzmanlıklardan oluşan karmaşık bir organizmadır desek de yukarıda söylediğim gibi IT’de bir anlamda bir üretim bandıdır (ve gerçekten karmaşıktır). Bu bandın da veriminin artması ve bazı yerlerin otomatize edilmesi her halde mümkündür. Peki, bunu yapmak gerçekten yapmak ister miyiz ya da yapmaya karar verdikten sonra bunu yapacak gücümüz olacak mı? İşte asıl sorulması gereken soru bana kalırsa bu. Kubernetes işte burada dertlere derman, kurak topraklara yağmur, düşküne yoldaş olabilir. O değil de nedir bu Kubernetes?

1.000 kelime okuduk, daha konuya yeni mi giriyoruz?

Başlıktaki gibi düşünüyorsanız, bloguma hoş geldiniz arkadaşlar. Benim herhangi bir konuda merhaba yazmam 2.000 kelime sürüyor, kusura bakmayın. Kubernetes aslında açık kaynak kodlu bir konteyner orkestratörüdür (Kardeşim çok zahmet oldu; yaptığın tanım süper hemen anladık ne olduğunu).

Kubernetes’in bir orkestra şefi olduğunu anladık galiba ama orkestra kim dediğinizi duyar gibiyim (bozmayın beni). Orkestranızsa yukarıda adı geçen konteynerler. Bir konteyner, uygulamanın çalışmasını sağlayacak gerekler bütününün standart bir paket haline getirilmesi işidir. Bu sayede tıpkı gemilere yüklenen konteynerler gibi uygulamalar bir işletim sistemi içine yüklenip birbirlerinden izole user spaceler altında sanallaştırılabilirler. Bu sanallaştırma sayesinde aynı kapasite üzerinde işletim sisteminin yarattığı yükün azaltılması ve performansın hemen tamamının uygulamalar tarafından kullanılması sağlanır. Aynı zamanda bir kez paketlenen bir uygulamanın sahip olduğu ayar ve bileşenlerle asgari şartları sağlayan her ortamda aynı şekilde çalışması sağlanır ki, bu da günümüz yazılım ortamında son derece önemlidir.

Konteyner ve Kubernetes sizin kullandığınız yazılıma süper özellikler katan bir bileşen değildir, neredeyse tamamen IT’nin iç işleyişiyle ilgili bir alt yapı bileşenidir ve özel durumları saymazsak günlük hayatta yazılımı kullanırken Kubernetes üzerinde mi çalıştığından ya da geleneksel yöntemlerle mi kurulduğundan haberiniz bile olmaz. Buna rağmen Kubernetes geçişi ve DevOps pratiklerinin uygulanışı tüm şirketin iş yapış biçimini değiştirebilecek kadar önemlidir.

Kavramsal olarak teknoloji eski olsa da (chroot, Solaris zones vb.) son yıllarda Docker firmasının bu alana getirdiği çözüm ve çözümün daha sonrasında firmanın ötesine geçerek bir endüstri standardı oldu. Linux çekirdeğinin aynı zamanda her bir konteynere ayrılan sistem kaynağını tam olarak kontrol etmeye izin vermesi gibi özellikler sayesinde yepyeni bir paradigma yaratıldı ve bu da IT sektörü için bir dönüm noktası haline geldi.

Her ne kadar tek bir konteyneri tek bir makine üzerinde yönetmek kolay olsa da, N tane konteyneri N tane makine üzerinde yüksek bulunabilirlik gerekleriyle N farklı sürümde yönetmek çok zor olacağından bu işi bizim yerimize yapan birine ihtiyaç duyduk ve bu orkestrayı yönetmek için bir şef aramaya başladık. Her ne kadar bir kaç sene önce sabaha erken başlayan herhangi bir geliştirici orkestratör mü yazsam acaba dese de (Bknz. Format savaşları ve Betamax) bugün sektörün hemen tamamı Kubernetes’in bu yarışı kazandığı konusunda hemfikir.

Huzur Kubernetes’te mi?

Kubernetes sayesinde uygulama geliştirme sürecinin içinde yer alan devreye alma, ölçekleme ve yönetim işlerini otomatize edebilirsiniz. Hatta kendi deyimiyle Kubernetes, kümelenmiş sunucular üstündeki uygulama konteynerlerinin otomatik devreye alınması, ölçeklenmesi ve yönetilmesi için bir platform oluşturmayı amaçlar. Peki, gerçek hayatta biz bu bilgiyi nerede kullanacağız işte ona bakalım.

Şimdi biz iş birimi olarak çalıştığımız şirkette müşterilerimize değer üretmek için bir yazılım kullanıyoruz ve diyelim ki bu bir CRM yazılımı olsun. IT birimimiz bu CRM yazılımının bakım ve idamesinden sorumlu bizse yazılımı kullanan kişileriz. Bizim için yazılımın hangi teknolojiyi kullandığı ya da nerede nasıl çalıştığı hiç önemli değil. Tek ihtiyacımız çalışması. Ta ki ekibimizdeki bir aklı evvelin (sonra ülkede inovasyon yok diyoruz) çıkıp yazılımda olmayan bir veriyi kullanırsak daha iyi bir sonuç alacağımızı söylemesine kadar.

İşte bu noktada artık sadece yazılımın idamesine değil geliştirilmesine de ihtiyacımız var. Bunu yapmak için öncelikle ihtiyacımızı tam olarak belirliyoruz (IT ekipleri LoL diyor burada) ve sonrasında IT biriminin kapısını çalıyoruz. Onlar ihtiyacımızı anlıyor, değerlendiriyor ve sonunda gerçeklemeye karar veriyorlar. Bunun için kendi süreçlerini işletiyorlar ve size bir kaç çeyrek sonra dönüp işte istediğin özellik diyorlar. Şampanyaları patlatıp kutlama yapacakken farkediyoruz ki, istediğimiz veriyi değil ihtiyacımız olmayan bir veriyi tutuyoruz hem zaten pazar da arada değişmiş ve doğru veriyi tutsak bile artık ona ihtiyacımız yok. Bu hikâye, hikayenin tüm tarafları için aslında çok yıpratıcı. Siz iş birimi olarak istediğinizi alamazken karşı tarafta da IT emek sarfetmiş olmasına rağmen sonuca ulaşamamış olmanın verdiği hayal kırıklığını yaşayacaktır. O yüzden böyle şeyler olduğunda suçlu aramaktan ziyade yapılması gereken çözüm aramakta ve huzur Kubernetes’te.

Kubernetes ne yapacak?

Aslında hiçbir şey. Amacımız sektörde “Hype” olmuş bir teknolojiyi kullanılmasını sağlayarak IT ekibimizin ve kendimizin bakış açısını değiştirmeye teşvik sağlamak. İşletim sistemi sanallaştırması hayatımıza girdiğinde bu bakış açısını değiştirme fırsatını kullanabilirdik ama o kadar hazır değildik o zaman ve iş bugüne kaldı.

Orkestrasyonun Kubernetes tarafından yapıldığı bir ortamda huzurlu çalışmanın ilk anahtarı ekibinizin repetitif tüm işleri hızla otomatize etmesi olmalıdır. Yukarıdaki tanımlardan çıkaracağınız gibi uygulamalarımız artık kurulumu özel ilgi isteyen yükler değil gemiye standart olarak yüklenebilecek konteynerler haline gelmelidir ve geminin de bunu kabul etmeye hazır olması gereklidir. Bunu başarmaksa havuca ve ödüle ulaşmak için DevOps tekniklerini uygulamadan geçmektedir.

Operasyon ekibimizin gerçek operasyonu yönetmekten ziyade operasyonu yöneten araç ve ortamları yönettiği bir hale gelmek ve geliştirme ekibimizin de yaptığı geliştirmeyi sadece kendi bilgisayarında çalıştırmaktan ziyade isterden teslime kadar bütün ortamı hayal ederek geliştirme yapmasını sağlayacak bir bakış açısı değişikliği Kubernetes’in işinizin ortasına güvenle oturması için gereklidir. Hadi gelin yukarıdaki örnek üzerinden tekrar gidelim bu sefer IT’den gelen konteynerleşme ve orkestrasyon isteklerine kulak tıkamayıp bütçe ayırdığınızda ilk geliştirme isteğinizin ve ikinci geliştirme isteğinizin nasıl sonuçlanacağını birlikte inceleyelim.

Aklı evvellerin favori yazılımı olan CRM’de yaşadığımız kötü deneyimden sonra değişik fikri olan tüm ekip arkadaşlarımızı karanlık bir odaya hapsettik ve yazılım bize ne veriyorsa onla yetineceğimize dair birbirimize sözler verdik iş birimi olarak. Yine de olduysa oldu ve karanlık zindanından kurtulan bir iş arkadaşımız kullandığımızı yazılımı bir adım öteye götürecek yeni bir fikirle kapımızı çaldı. Siz de belki bir kez daha kırılmaz bu minnoş kalp diyerek umutlarınızla birlikte IT’nin kapısını bir kez daha çaldınız ama bu sefer IT ekibiniz size Docker, Kubernetes gibi işinizle hiç ilgisi olmayan kavramlardan gözleri parlayarak, havalara zıplayarak, birbirlerine çak çak (High Five’ın Türkçe’sinin yüksek beşli değil de çak çak olması, bir tek bana mı dil açısından bir kayıp gibi geliyor?) yaparak bahsettiler. Siz de önünüze gelen bol sıfırlı bütçeyi tamam diyerek desteklediniz ve yeni bir projenin içinde buldunuz kendinizi.

İsteklerinizin neler olduğunu söylediniz ve iyisi mi ben sizi biraz kendi halinize bırakayım diye düşünüp bir sonraki statü toplantısına kadar kendi işlerinize daldınız. İşte burada senaryomuz ikiye ayrılacak.

İlk senaryoda ekip Kubernetes yatırımı yapacak ama bakış açılarını değiştirmeyecek. Bu durumda katılacağınız ilk toplantıda geliştirme ekibi test sistemlerinin hala hazır olmamasından dem vururken operasyon ekibi test sistemini ancak çalışmaya ve kurulmaya yakın bir yazılımın hak ettiğini söyleyecek ve geliştiricinin bilgisayarında çalışan kodun neden test ortamında çalışmadığını anlamadığını söyleyecek. Öte yandan Kubernetes’in ortama büyük bir kompleksite getirdiğinden ve şu an neyin çalışıp neyin çalışmayacağından emin olunmadığı da söylenecek. Siz de garibim arada oturacak ve belki LinkedIn’den ilan bakacaksınız.

İkinci senaryoda ise IT ekibiniz sizle yaptıkları toplantının %99.976’sını (bilimsel olarak defalarca ölçülmüştür, kontrol edilebilir) daha önce çok zaman alan birçok görevi nasıl otomatik hale getirdiklerini anlatmaya ayıracaklardır. Örneğin artık yeni makine istekleri geliştiriciler tarafından otomatik olarak yapılıyor ve state tutan sunucular sanal ortamda otomatik olarak oluşturulurken Kubernetes ortamında her geliştirici test ortamında kotası kadar düğüm oluşturmak için kimseden onay almadan self servis portalını kullanabiliyordur. IP atamaları ve yönlendirmeleri IPAM servisleriyle otomatize edilmiştir ve hatta decommision işlemleri bile otomatiklemeye başlamıştır. Geliştirici ekip test, staging, üretim gibi ortamlar için gereken konteynerleri oluşturma işini pipeline’lar üzerinde otomatize etmeye başlamıştır. Böylece her seferinde yazılımın kurulmasında ve ayarlanmasında operasyona destek olmak yerine doğrudan devreye alım yapabilecek hale gelmeye başlamışlardır. “Ee benim özellikler?” dediğinizde toplantının %0.024’lük kısmı olan “Evet ona da bakıyoruz” cevabını alacaksınız ama bu sefer LinkedIn’e girmeye gerek yok zira umut artık bu evde de yeşermektedir.

IT birimimiz ortamın gereğini yerine getirmeye başlayıp repetitif tüm görevleri otomatize etmeye başlamış bu sayede kısıtlı kaynağı daha verimli kullanma yoluna gitmiş ve değer üretmeye başlamıştır. Artık operasyonun sanal makine kurmak yerine nasıl otomatik sanal makine kurulur sorusuna cevapları vardır. Bir yandan otomatize etmenin ilk adımı doğru belgelendirme olduğu için o işin nasıl yapıldığını sadece Handan / Nuri biliyor dönemi de sona ermeye başlamıştır.

Yazılım geliştirme ekipleriniz de operasyona benzer bir şekilde artık ayar, entegrasyon, devreye alma ve yükseltme gibi işlemlerin nasıl yapılacağını operasyona bırakmak yerine kendisi aksiyon alabilecek durumdadır çünkü operasyon artık kendine göre kurmaya çalışacağı (ve çoğu zaman zorlanacağı) bir bileşenler ağacı yerine standardize olmuş ve paketlenmiş bir konteyner beklemektedir. Bu sebeple operasyondaki benzer bir dokümantasyon ve bilgi paylaşımı gereği yazılım tarafında da hasıl olmuştur.

Evet, kimse sizin çok istediğiniz ve önemli olan o büyük geliştirmenizle ilgilenir gibi gözükmemektedir ama masanın etrafında da pek kavga yoktur. Birkaç statü toplantısı sonrasında artık geliştirmeyi test edebileceğiniz söylenir ve bu sefer her zamankinden biraz daha kısa bir sürede istediğinizi alırsınız. Aynı aklı evvel bir kez daha şakıdığında artık bu süreçlerin daha da oturduğu IT biriminiz isterlerinizi almakta ve çok kısa bir süre içinde yanınıza gelip istediğin buna benzer bir şey mi diyecek hale gelecektir. Çünkü artık daha fazla kaynak bilişsel işlere ayrılabilmekte ve aynı zamanda değerin hızla oluşabilmesi için gerekli altyapı da sağlanmış olacaktır.

Kubernetes her eve lazım mı?

Elbette Kubernetes herkes için değil. Örneğin tüm işlerin karşısında çok kısa kalan bir ekip için ek bir iş yükü yaratmaktan öteye geçmeyebilir. Hepi topu 4 uygulamanız varsa ve ölçeklenebilecek durumda değillerse önceliğiniz bu teknolojiye geçmek olmamalıdır.

Teoride kulağa hem hoş hem de inanılmaz geldiğinin farkındayım ama gözlemlediğim iyi uygulama örnekleri Kubernetes yatırımlarının ve bu havucun getirdiği bakış açısı değişikliklerinin genellikle iş birimlerinin IT’den edindiği değeri artırdığı yönünde oldu. O yüzden geçtiğimiz 2.000+ kelimede Konteyner’i, Kubernetes’i, orkestrasyonu öğrenen sizler ya IT sizin kapınızı destek için çaldığında yardıma gitmek gerektiğini ya da onlar size bu istekle gelmiyorsa sizin belki bu istekle onlara gitmeniz gerektiğini anlamışsınızdır (umarım.)

Bu yazıda dilim döndüğünce Kubernetes’ten, Konteyner’lerden ve bu teknolojilerin bakış açımıza getirdiği farklılıklar sayesinde iş birimlerine değer katabileceğinden ve bizim iş birimleri olarak bu fırsat penceresini kaçırmamamız gerektiğinden bahsetmeye çalıştım. Elbette IT ile iş birimi arasındaki sürtünmenin tek nedeni bu değil ve bu teknoloji de bir gümüş kurşun değil ama iyi bir başlangıç noktası.

Gelecek yazının konusu bir başka sürtünme konusu olan “Kardeşim bu IT’nin tek işi sizin projenizi yapmak mı?” başlığı üzerine olacak. Bu yazıda sorunun cevabının neden kocaman bir HAYIR olduğuna da yanıt vermeye çalışacağım.

Okuduğunuz için teşekkürler.

Dipnot: Eğer IT ile ilgili olan herkesin bir kitap okumasını sağlayabilecek olsaydım, The Phoenix Project’i okumasını sağlardım. (Eğer dünyadaki herkesin bir kitap okumasını sağlayacak olsaydım herkesin Otostopçu’nun Galaksi Rehberi’ni okumasını sağlardım bu sayede onları bu kitabı okumaya zorladığım için aslında ne kadar bilge bir kişi olduğumu görürler ve beni dünyanın, evrenin ve diğer şeylerin doğal ve bilge lideri olarak seçerlerdi). Bu yazıyı yazmamın temel nedeni de aslında kendi görüşlerimin büyük kısmını bu kitabın şekillendirmesi oldu. Dolayısıyla yazının büyük kısmına kitabın ilham verdiğini fark etmeniz normal.

Bu yazının özgün hali, bu bağlantıda bulunan 17 Şubat 2020 tarihli yazıdır.