Geçtiğimiz Cuma (21.06.2019) günü gerçekleştirdiğimiz etkinlikten bazı notlarım aşağıdadır. Doğrudan etkinlikte konuşulanlar şeklinde değil başka okumalarımdan, etkinliklerden edindiğim birikimlerin yorumuyla yazacağım inşallah. Biraz uzun bir yazı oldu. Sıkılmayın diye aralara kendi çapımda espriler kattım. Hatırım olan arkadaşlardan sonuna kadar okuyup katkılarını rica ediyorum.
Her şeyden önce DevSecOps, DevOps süreçlerine “Security”nin vurgulanarak eklenmesi diyebiliriz.
DevOps anlatılırken genellikle aşağıdaki kavramlara değiniliyor hatta zaman zaman doğru veya yanlış birbirlerinin yerine kullanılıyorlar.
- Continuous Delivery/Deployment/Integration (Benim izlenimim DevOps un ana teması bu)
- Automation
- Pipeline
- Agile (Çevik yaklaşım)
- Scrum / Sprint- Kanban, Extreme programming
- Micro Service
- Container
- Culture (Kültür)
- Collaboration (İş Birliği)
- Specialist VS Generalist
- Agile VS Waterfall
Bu kavramları yöntemleri çok farklı şekillerde anlayıp uygulayanlar var. Dikkatinizi çekeceği üzere DevOps tan bahsederken ilk akla gelen/öne çıkan kavramlar ne geliştirme (development) ne de altyapı/operasyon.
Aslında scrumdan, sprintten, sürekli dağıtımdan (continuous delivery) bahsedenler tüm bu alt yapının ve ona uygun projenin, kültürün var olduğunu varsayıyorlar. Ya da bazı konuşmacılar tüm bunların olması için alt yapının hazır olması gerektiğini vurguluyorlar.
Sprint Ready Project
Çevik (agile) yaklaşımı; ben müşterinin ihtiyaçlarını en küçük anlamlı parçalara bölüp en öncelikli olanından başlayarak gerçekleştirmek olarak algılıyorum. Çevik yaklaşımlar yöntem olarak bu işlerin nasıl yapılacağını belirtir fakat pratikte teknik olarak nasıl bir yol izleneceğini belirtmez. İşte bu durumda DevOps süreçlerine ve pratiklerine ihtiyaç vardır. Ancak burada bir sorun olarak gördüğüm şey şu. Örneğin kurumsal satış yapan web site gibi büyük bir uygulamayı çevik yaklaşım veya bir başka deyişle iki haftalık sprintlerle yapamazsınız diye düşünüyorum. Bu noktada benim önerim müşteri ihtiyaçlarını sprintlerde giderebileceğiniz bir seviyeye gelinceye kadar waterfall yaklaşımıyla projeyi sprintlere hazır hale getirip sonrasında çevik (sprint, scrum) olarak devam etmektir. Bunun için ben bir kavram uydurayım. “Sprint Ready Project”.
DevOps Infrastructure
Elimizde Sprint Ready bir proje olduğunu varsayalım ve sprintlere başlayacağımız zaman elimizde bir sürekli dağıtım hattı (continuous delivery pipeline) yok ise çok büyük ihtimal ile sprint başarısız olacak. Sprint/scrum çalıştırmak için-ilk bir kaç aşamada- bir otomatize hatta (pipeline) ihtiyacınız olmadığını düşünüyorum. Ancak eğer yoksa iki haftada bir isteği yerine getirmeniz mümkün değil. İşte bu noktada sprintin doğru çalışması için bir otomatik hatta ihtiyacınız var. Otomatik üretim hattı (pipeline) bakkaldan alınan bir şey değil. J Bu alt yapıyı birilerinin kurması gerekiyor. Bu alt yapıda neler olmalı ayrıca değerlendirmek gerek ancak en temelde kaynak kod yönetimi, code build, monitoring, test otomasyonu, otomatik deployment vs…
Micro Service Nereden Çıktı?
Diyelim ki sürekli dağıtım (Continuous delivery) yapabilmek için projemiz hazır, alt yapımız hazır. İki haftada bir dağıtım (deployment) yaptığımızı düşünelim. Böyle bir durumda uygulama tek parça ise tek bir paket halinde deploy ediliyorsa çok büyük bir uygulama oluyor ve her deploymentta paketin tamamı etkileniyor farklı sprint takımlarınız olsa bile onların kod commitlerini düzgün bir şekilde birleştirmek ve kesintisiz veya kısa süreli bir kesintiyle deploy etmek neredeyse imkansız hale geliyor. İşin doğrusu monolitik dediğimiz tek uygulamalı çözümler sürekli olarak build ve deploy edilemezler. Burada düşünürlerimiz düşünmüşler ve demişler ki “yahu bölelim şu uygulamayı yutması kolay olsun. (Böl- parçala-yut J klasik yöntem) Böylece mikro servis mimarisi dünyaya gelmiş. Büyük bir uygulamanın parçası olan mikro servisimiz aynı zamanda hacmi küçük bağımsız bir uygulama olduğu için kod commit ve bir üretim hattında (pipeline) ilerlemesi kolay. Böylece istediğiniz kadar takımı paralel çalıştırın.
Bağımsızlık/Özgürlük Başa Bela!
Sonra adamı tıkarlar bir koteynıra. (Şiir gibi oldu haa.. )
Yine hayal edelim. Kocaman bir uygulamayı mikro servize ettiniz ( nasıl beğendiğiniz mi yeni kelimemizi. servize) Eee her biri bağımsız olduğuna göre farklı ihtiyaçları olabilir. Farklı .net core/java versiyonları farklı çevresel değişkenler falan filan … O zaman nasıl baş edeceğiz bunlarla alt yapı ekipleri kur Allah kur bir sürü sunucu.. kim yönetecek kardeşim bunları? İşte yine büyük bilginlerimiz imdada yetişmiş ve konteynırrrr demişler. (peynirrr gibi gülümsetmiyor.) İşte arkadaşlar konteynır (container) zaten küçük olan mikro servislerimizi hapsettiğimiz bağımsız kutucuklar. Bu kutucukları genelde kullan at yapıyoruz. (Valla içim acıdı. kullanılıp atılmak kötü bir şey olsa gerek.) Docker, Kubernetes, Openshift bu ortamı sağlayan alt yapılardan temel olanları.
Bu araç Sola Çekiyor (Shift Left):
Tüm bu işlemler olup biterken bahsetmediğimiz hususlardan birisi testler özellikle de güvenlik taramaları. Etkinlikteki güvenlik direktörü olan bir konuşmacı, en çok son dakika güvenlik taraması istenmesinden şikâyetçi olduklarını ifade etti. Örneğin Cuma günü canlıya geçecek uygulamayı Perşembe günü taramaları isteniyormuş. Bizde eskiden alt yapıya hep son dakika geliniyor diye şikâyet ediyorduk aynı mevzu. Mütefekkirlerimiz boş durmamış bunu aşmak için literatüre “shift left” diye bir şey sokmuşlar. Yani sürece mümkün olduğu kadar erken dahil olma eylemi. Bu problem hem alt yapı hem test hem de güvenlik ekipleri için var. Örneğin son dakika iletilen bir firewall erişim izni için yapabileceğimiz bir şey yok. Çözüm olarak bu ekiplerin soldan sağa ilerleyen bir zaman çizgisinde sola kaydırılarak dahil edilmesine “Shift Left” diyorlar. (Bu konuyu TOGAF ADM döngüsünde çözüyor ama şimdi Oraya çok girmeyelim.)
İş Birliği (Collaboration):
İş birliği ortamı; bence her işin uzmanının işi yaptığı ancak diğerleriyle iletişimin ve empatinin güçlü, önerilere açık olduğu bir ortamdır. Bunun yolungeneralistliğin üstüne oturmuş bir specialistlikten geçtiğine inanıyorum. Yani iyi bir yazılımcı orta seviyede olsa veritabanı, sistem, proje yönetimi bilir; yine aynı şekilde iyi bir sistemci orta seviyede yazılım, veritabanı bilir. Bir uzmanın diğer alanlardaki bilgisinin etkikili iletişim konusunda oldukça faydalı olduğunu düşünüyorum.
Bu noktada etkinlik konuşmacılarından Hasan Yaşar Bey’in notunu da iletmek isterim: Aslinda DevOps un istediği “collaboration: yardim olarak degil, fikir alisverisinde bulunmak,DBA isini yapmak degil DBA ye isteklernini zamaninda iletmek, yada Security ihtiyaclarni bilen ekip bilgileirni developer architect ile paylasmasi demek. Birbirlerine yardimdan ziyade konusmak, konusmak konusmak,,,”
Kültür (Culture):
Hemen hemen her konuşmacı bu işlerin kültürü olmadan ilerlenemez dediler. Peki bu işin kültürü nasıl oluşturulacak? Bu konuda da farklı beyanlar var ancak ben alt kademelerde benimseyen işlerin hep güdük kaldığını düşünüyorum. Elbette yöneticilerin destek vermediği bir şeyin başarılı olması neredeyse imkânsızdır. Bu durumda tüm kurum olarak kültürel değişimin benimsenmesi gerekiyor. Benim bu noktadaki kanaatim bir çok paralel faaliyetin bir arada yapılması gerektiği yönünde. Örneğin çevik yaklaşım nedir hiç duymamış birisine siz çevik yaklaşım kültürünü aşılayamazsınız. Veya heyecanlı bir çalışanınız koteynır uygulamalarını öğrendi deneyimleyip öğrenmek istiyor ona alt yapı sunmazsanız o heyacan söner gider. O zaman kültürün yerleşmesi için şunlar yapılmalı;
- Sürekli eğitimler, konferanslar etkinliklerle bilgi ve ilgi düzeyi arttırılmalı
- Yönetim cesaretlendirici, teşvik edici en önemlisi ilgili olmalı.
- Bir taraftan alt yapı hazırlanmalı.
- Küçük bir projelerle başarı hikayesi oluşturulmalı ve onun etrafına yenilerini ekleyerek yaygınlaştırılmalı.
Etkinlikten Güvenlik Notları:
- NSA demiş ki bizim sıfırıncı gün açıklarına ihtiyacımız yok. Kurumların çoğu yamaları zaten zamanında geçmiyorlar bizde bu açıklardan faydalanıyoruz. Yamalama önemli.
- Açık kaynak frameworkleri kaynak kodları internetten olduğu gibi kullanmayın. Çoğu kodun içine sizin istediğiniz fonksiyonla beraber istemediğiniz örneğin coin işleme gibi şeylerde sokuşturulmuş durumda. Sürekli dağıtım hattınıza dışardan çekilen kodlar önce güvenlik taramasından geçmeli.
Diğer Notlar:
- Mark Miller: ben her zaman tıkanan noktalara (bootleneck) odaklanırım diyor. İşlerde sıkıntı varsa tıkanıklık nerede, sorun nerede ona bakarım diyor. Aslında scrum ın amacı da insanların birbirlerine ne yaptıklarını anlatması değil bir yerde tıkanıklık varsa onu tespit etmektir diyor.
- Yine Mark otomasyondan bazıları işimizi kaybederiz diye korkuyorlar diyor. Ancak otomasyon mühendislere kendi işlerini yapmayı sağlar diyor.
- En beğendiğim konuşmacı Hasan Yaşar: İster agile ister waterfall ne olursa olsun her yazılım mutlaka bir analiz, tasarım, test, canlıya alma sürecinden geçer diye ifade etti. Önemli olan bu süreçlerde yapılması gereken security checklist ve yazılım ihtiyaçlarının her adımda ele alınmasından bahsetti.
Zeynel Abidin Sezer, Bilişim Teknolojileri Derneği Genel Kurul Üyesi, sezerz@gmail.com
