Merhaba,
Bugun itibariyle katıldığım DevOps zirvesinde (http://devopszirvesi.com/) edindiğim ilk gün notlarımı aşağıda halka açıyorum 🙂
Bu konferansın temel amacının , 8-10 yıldır ABD’de tartışılan ve geliştirilen DevOps yaklaşımı ve tanımının, Türkiye için de bir tartışma konusu olmasının istenmesi. Ücretinin bu denli çok olmasının sebebi de start-up ve küçük firmalar yerine kurumsal firmaların talep göstermesini sağlamak olduğu söylendi, akıllıca olsa da dile getirilmeseydi iyiydi 🙂
Küçük firmalar için DevOps’un gerçekten kolay bir hedef olduğu konusunda konuşmacalarla hemfikirim. Özellikle bulut çözümleri zaten default DevOps.
DevOps nedir ise en basit ve kaba şu şekilde ifade edilebilir.
- DevOps exists to help the business win
- The scope is broad, but centered on IT
- The foundations are found in Agile and Lean.
- Culture is very important
- Feedback is fuel for innovation
- Automation helps
Öncelikle, konferansda ilk konumuz DevOps temelleriydi. Aşağıdaki görsel ilk konunun kısa bir özetini anlatıyor.
DevOps’un tek başına ayakta kalabilecek birşey olmadığı, agile,ITSM ve Lean Pratiklerle ayakta kalması gerektiği vurgulandı.
DevOps’un Industry 4.0 yaklaşımından baz alarak otomasyona yöneldiği de belirtildi fakat ben bunun endüstriyle direkt alakalı olduğunu düşünmüyorum.
Puppet’ın State of Devops raporu gerçekten takdire şayan. İçindeki veriler hem gerçekçi hem de yol gösterici. Bu rapora göre DevOps’a geçen ekiplerin 2550 kat daha hızlı feature deploy ettiği örnek gösterilerek, bunun ancak doğru darboğaz çeken adımlardaki yerlere otomasyon çözümünün sağlanarak gerçekleşebileceği belirtildi.
Kurumsal her firmanın bir feature deploy süreci vardır, evet, ama onu hızlandırmak için önceliği ürünler yerine darboğazlara vermemiz gerektiği vurgulandı.
Amazon’un lambda teknolojisinin yakın zamanda dünyayı kasıp kavurabileceği de, araştırılması gerektiği de ufak bir PS olarak dile getirildi.
DevOps’a nereden başlamalıyız konusunda da 3 adımlık aşağıdki plan yansıtıldı.
- Identify App
- Build the Team (not DevOps team, agile team)
- Automate & Expand
Bu yaklaşım genel olarak, IT4IT’e gönül vermiş HPE’nin kabul ettiği yaklaşım.
Bugun öğrendiğim en ilginç bilgilerden birinin de NETAŞ’ın 50 yıllık bir şirket olduğuydu. Ve 2000’den fazla çalışanı olduğu. DevOps ‘a onlar da kafayı takmış durumda 🙂
Şirketlere hem microservis hem de IAC (Infrastructure as Code) olarak danışmanlık yapıyorlarmış.
Kafamı meşgul eden şeylerden biri de , konfigurasyon yönetimi araçlarından çıkan kodların araç üzerinde mi yoksa bir scm’de mi tutulması gerektiğiydi. Buna da cevap scm olarak verildi. Mantıklı.
NETAŞ ‘ın IAC konusunda yaklaşımı şu. “Çalışan servera dokunma, runtime çokla ve ne yapıyorsan orada yap,CI dahil.”
Ve üstadımız, cloud’ın ilk fikir sahiplerinden Vogels şöyle diyor 🙂 Servera sarılma, o sana sarılmaz. Bunun altında yatan şey şu, hepimiz yaşamışızdır, serverda bir script , bir runnable çalıştırdığımızda içimizden ‘hadi koçum sen bunu yaparsın, aslansın’ diye geçmiştir. Bunu yapma, o sana yapmaz diyor 🙂
Tamam yeri geldi serverımızı runtime çoklayabildik, peki common DB’leri napacağız konusunda da içimizi rahatlatacak bir cevap alamadık, onu da çoklayalım dışında:)
IBM’in Compose’unun da dikkate alınması gereken bir teknoloji olduğu dile getirildi.
UniKernel başlı başına tüm container teknolojisinin yerini alabilecek bir düşünce.
Bence konferansın en güzel konusu, ITIL vs DevOps’du.
Konuşmacı arkadaşımızın çarpıcı tespitleri, soruları var ve bazıları gerçekten üzerinde düşünülmesi gereken şeyler. Belki bir organizasyonu DevOps’a evirmeden önce bu sorulara cevap vermek ilerde yaşanacak sorunlara tedbir olabilir.
İşte o tespitler,
- ITIL sadece Ops değildir.
- ITIL’a göre de Ops rutin datacenter işlerinden ibaret değildir.
- ITSM müşteri için feature deployment’tan önce gelir. (Borsa Istanbul’un bir release sonrası 1 gün hizmet veremediğini öğrendik.)
- ITSM’in Application Management fonksiyonun parçalarından biri olan Dev, 26 ITIL süreci ve 4 Fonksiyonundan birinin altındaki küçük bir olgudur.
- Yazılım bir ürün değildir, bir servisin küçük bir parçasıdır. Dolayısıyla da development ITIL’daki servis tasarımının bir parçası olmalıdır. Service Design’da bu kültürü uygulamayan bir kurumda Service Transition ve Service Operation’da DevOps yapmak başarılı olabilir mi?
- Dev’de neden operasyon süreçlerini görmüyoruz da sadece tool konuşuyoruz? Event, incident, Problem, Request, Access bu yaklaşımın neresindedir?
- CD yapıyorum derken müşterinin Continuity’sini kesersen, business’ın süreklilik ve gelişme anlayışı anlamını korur mu?
- DevOps’un ana amacı , dev ve opsda bir bütün halinde mükemmelleşmek değil, verilen hizmette mükenmelleşmek olmalıdır.
Benim notlarım bu kadar. Bu konferansı düzenleyip bu fikirleri bizimle paylaşan her bir konuşmacıya ve organizatör/sponsorlara teşekkür ediyorum.