Koding ile DevOps Söyleşisi

DevOpsTurkey olarak yaptığımız ziyaretlerde bu sefer ki konuğumuz yazılım geliştirme dünyasında kendisinden söz ettiren, Silikon Vadisi’ndeki ender Türk girişimcilerinden olan, Koding’in CEO’su ve Co-founder’ı Devrim Yaşar idi.


koding

 

Derya: Öncellikle Koding ve DevOps’u nasıl tanımlarsınız?

Devrim: DevOps şu anda dünya üzerinde baktığımız zaman genelde canlı ortam dediğimiz “Production” ortamlar ile daha çok ilgileniyor. Yazılımcı kendi makinesinde yazıyor kodunu ve yine kendi makinesinden canlı ortama bir şekilde deploy ediyor. DevOps’un bir bacağı da asıl bu noktadan sonra başlıyor: Benim siteme 1 milyon kişi gelirse bu siteyi nasıl yatay veya dikey ölçeklerimin ötesinde,  şirketlerin es geçtiği konuyu Koding çözüyor. Biz özellikle yazılımın geliştirildiği ortama odaklanmış durumdayız. Bu günkü koşullarda örneğin, bir kişi işe başladığında bu kişinin bilgisayarı tedarik edilir, çalışma arkadaşlarıyla tanıştırılır, SSH gerekiyorsa örnek Mike ile konuşturulur vs. gibi  3-4 hafta süren bir configuration ve setup var. Yani ne iş yaptığına bağlı olarak büyük şirketlerde ortalama 3 ay, küçük bir startup‘da ise 1 hafta bir zaman kaybı söz konusu. Koding bu süreci 5 dakikaya indiriyor. Takımındaki varsa DevOps şapkası olan kişi, yeni gelen kişinin bilgisayarıyla artık ilgilenmiyor, onun Koding’te yazdığı “stack script” ile tüm ihtiyaçları çözülüyor. Örneğin; X repository’nin eklenmesi, Y repository’nin forklanması, AWS üzerinde c3.xlarge bir makine açılması, 50 GB storage atanması ve sonra gereksinim duyulan paketleri yüklenmesi, belki sonra AWS’de ElastıcIP atanması gibi… Şimdi misal ben seni Koding’e işe alsam 5 dakika sonra kod yazabilirsin. İsmi de derya.koding.team diye domain olur sana ve hiç kimseye hiçbir soru sormadan ilk kodunu yazabilirsin.

koding

Koding sayesinde şirketlerdeki DevOps şapkası taşıyan kişiler kullanıcı destek gibi basit görevler yerine, katmadeğeri yüksek işler yapabiliyor.

Bunun olmadığı ortamlarda “Benim kodum çalışmadı”, “Benim makinemde çalışmadı”, “şu olmadı”, “burası çalışmadı” gibi cümleleri duymak olasıdır. Eğer yazılım stack’de bir değişiklik gerekli ise, “Stack script” de değişiklik yapılır ve ilgili herkese bir uyarı mesajı gider. Telefonumuzdaki bir yazılım güncellemesi gelmiş gibi “Stack” güncellemesi aktif olur. Yazılımcı ne zaman hazır ise, bu değişikliklerin uygulanmasını sağlayıp, eski makinelerin sona erdirilmesi ve yeni makinelerin ayağa kaldırılması ile yazılımcıya yine kodlama imkanı verilir. Bir yazılımcı açısından birinci ve en güzel özelliği bu. Yazılımcı bir kodun nasıl çalıştığını, nasıl konfigüre edildiğini, nasıl setup edildiğini bilmek zorunda kalmıyor ve bunlar hazır geliyor. Yöneticiler açısından en güzel özelliği ise analitik veriler sağlayabilmesidir. Örnek olarak takımındaki bir yazılımcı 50 tane task’ın 40 tanesini yapamamış. Normalde, dışarıdan bakıldığında bu durum yazılımcı için olumlu bir durum gibi gözükmez. Ama gerçekte bu yazılımcınin, Koding’in verdiği analitikler sayesinde, takımındaki 30 kişinin problemini çözmüş olduğu ve bu yüzden diğer işlerinden geri kaldığı görülebilir, ve bunu Koding ile bütün takım için takip etmek mümkün. Koding, üzerinde yapılan tüm aksiyonları bildiği için, takip ettiği metrikler sadece konfigurasyon ve setup değil. Eğer bir yazılımcı, mevcuttaki bir fonksiyonun ne iş yaptığını anlamamış ve yardım istiyorsa, yardıma gelen kişiye en sonunda, sanki bir “Uber” deneyimi gibi skor verebilir ve ay sonunda bu kişinin örnek 25 kişiye yardım ettiğini ve hepsini de çok memnun ettiğini görebilirsin. Veya başka bir yazılımcı 25 kişiye yardım etmiş ve hiç kimseyi de memnun edememiş birçok kişinin de zamanını almış olabilir. Bu gibi analitikler sayesinde Koding aslında şeffaflığa ve yönetilebilirliğe yardımcı oluyor. Birçok yerde yazılım geliştirme ortamı kara kutu, yani hiç kimse hiçbir şey bilmiyor, kodlamak ile meşguller ama onun dışında hiçbir şekilde verification, validation, visibility yok. Biz günün sonunda yazılımcılara özgürlüklerini verirken onların zamanlarını harcayan etmenleri ortadan kaldırıyoruz. Özellikle büyük şirketlerde yazılım geliştirme ortamları 2000li yıllara takılı kalmış ve güncellemek çok zor olabiliyor. Bunların üzerine Docker, containerlar, mikro servisler derken şirketlerin ve yazılımcıların yenilikçi teknolojileri kullanması iyi zorlaşıyor. Deployment, staging, testing, production proseslerinin tekrar düzenlenmesi gerçekten dert oluyor. Koding’de yazılım geliştirme ortamı da kodun bir parçası olduğu için, sistem yöneticisi yazılan kodun yazıldığı ortamı da gözden geçirip “canlı ortama gönderebilirim” diyebiliyor.

 

Yazılımcı özgürlüğü ile sistemlerin tutarlılığı birbirlerine sürekli düşman

Her kullanılan teknoloji ve araç için geliştirme ortamının değiştirilmesi mümkün olmadığı için yazılımcı özgürlüğü ile sistemlerin tutarlılığı birbirlerine sürekli düşman ve biz bu düşmanlığı da ortadan kaldırıyoruz. Koding ile diğer bir avantajımız ise buluttaki bir sunucuyu lokal ortamınıza mount ediyor olması. Böylelikle AWS’deki makine sanki senin lokal makinenmiş gibi çalışabiliyor. Mount ediyorsun ve Eclipse, Sublime veya hangi IDE ile çalışmak istiyorsan onunla çalışabiliyorsun.

koding

Bizim misyonumuz DevOps’u “Tech support” olmaktan çıkarmak.

Bu sayede DevOps sorumluluğu olan kişiye de kariyerindeki bir sonraki adım için dikey/yatay ölçeklenme “vertical/horizontal scaling” gibi daha üst seviye de görevler verilebiliyor, yani son kullanıcı bilgisayarındaki basit problemle uğraşmıyor. Artık yeni işe başlayan bir yazılımcı için ilk gün deneyimi Koding üzerinde ilgili Stack script’i çalıştırmak ve yazılım geliştirmeye direk başlamak olabiliyor.

koding

Derya: Daha üst seviye işler ile uğraşmanın çalışan motivasyonuna da etkisi oluyordur?

Devrim: Tabii, çalışanı sevdiği gerçek işiyle uğraştırıyoruz. Tabir yerindeyse Koding sayesinde şirketler, Formula1 sürücüsünü (DevOps) taksi kullanmak (tech support) zorunda bırakmıyor. Bir DevOps veya Sistem Yöneticisine bir yazılımcının ortamının düzeltilmesi görevi verildiğinde, ve buna karşılık o da örneğin; Nginx konfigurasyonunda bir güncelleme yapıyorsa belki de birçok kişinin çalışma ortamını olumsuz etkiliyor olabilir.Çünkü çalışma ortamı onun kontrolünde olmayabilir. Bu kadar küçük bir değişiklik bile developer takımının yarısının bilgisayarında artık stack’in çalışmamasına sebep olabilir. Birbirlerine yardım etmek istiyorlar ama kimse bir diğerinin bilgisayarındaki problemi çözme konusunda motive değil, kimbilir bilgisayarına daha önceden ne değişiklikler yaptı, belki Apache kurmuştur, ondan Nginx patlamıştır gibi düşünüyor haklı olarak. Koding bunların da önüne geçiyor çünkü her yarattığın “Stack” özdeş, yani bendekiyle sendeki aynı. Bendeki çalışıyorken sendekinin çalışmama ihtimali zaten yok. Çalışmıyorsa da çok ilginç bir problem var demek ki bunu debug edebiliriz. Şu an her şirketin içerisinde herkesin makinesi birbirinden o kadar farklı olabiliyor ki onu debug etmek insanlara zulüm geliyor.

koding

Derya: Uyguladığınız DevOps pratikleri hakkında biraz daha detay alsak mesela “insfrastructure-as-code” kod anlamında kullandığınız bir yaklaşımınız var mı? Container, orchestration, CI server, test automation ve braching e bakış açınız ve yaklaşımız konusunda bilgi alabilir miyiz?

Devrim: Bizim tek ilgilendiğimiz kısım “Development Environment” ama CI/CD/Deployment gibi araç setlerini Koding’e teker teker entegre ediyoruz. Mesela Koding’de GitLab’daki bir proje için “Run this Project” dediğin zaman Koding bunu ayağa kaldıracak ve senin de zaten geliştirme ortamı ayarların kodun içinde yer aldığı için bir issue‘e bastığın zaman, ben Derya ile bu issue üzerinde çalışmak istiyorum diyebileceksin. Tek tuşlama ile ortam açılacak ve iki yazılımcı aynı koda bakar hale gelecek. Sen diyelim ki Hindistan’da çalışıyorsun ben Türkiye’deyim ve ben geliştirme ortamımı seninle paylaşmak istiyorum. Bunu yapmak için bir email atıyorum ve sabah kalktığımda sen benim sorunumu çözmüş oluyorsun. Bizim bu arada şirketlere dikte ettiğimiz bir şey de yok, herkes sunucularını istedikleri gibi programlayabiliyor. Bizim için önemli olan şey yazılımcının ihtiyacı olan sunucuyu tüm ayarlarıyla çalışabilir hale getirmek. Örnek olarak Ubuntu 14.04 üzerine koyacağın paketleri belirleyip, buna ElasticIP ekleyip, sonra route53’den bir tane domain ata – işte sana ortam hazır! Bunun içinde Docker yazabilirsin, Puppet ile altyapını tanımlayabilirsin veya sunucu ayağa kalkar kalkmaz merkezi bir Chef ile konuşturabilirsin, yani Koding ile ayağa kalkan makinelar konfigure edilebiliyor olabilir.

koding

Derya: Sizin kendi içinizde ölçeklenme için kullandığınız yöntemler nelerdir?

Devrim: Bizim canlı ortamlarımız AWS’de. CloudFormation da var,  ElasticBeanstalk da var. PostgreSQL RDS’de. RabbitMQ’larımız dışarıda.
koding

Derya: Yani PaaS olarak mı alıyorsunuz?

Devrim: Biz her şeyi PaaS’a çevirdik, PaaS’a çevirmediğimiz her şey başımıza dert oldu maalesef. MongoDB’miz bu şekilde, gerisi zaten Go server. Go serverlar Elastic Beanstalk’da kendilerini Scale ediyor. Node.js’lerimiz var onlar da Elastic Beanstalk’da. Başka da aklıma büyük bir bileşen gelmiyor. Mümkün olduğu kadar DevOps ile biz uğraşmamaya çalışıyoruz. Çünkü Koding’in kendisinin çok büyük bir sıkıntısı yok. Bizim bir “Webapp” olarak Micro Servis framework’umuz kendimize ait. Bizim insanlara önerimiz özetle bu konuda yok. Yani nasıl çalışmak istiyorsan biz ona ayak uyduruyoruz ama tabii fikrimiz yok mu var, Ancak Koding’in şöyle yaparsanız daha iyi olur dediği çok fazla bir şey yok.

Derya: Peki kendi içinizde test amaçlı kullandığınız yaklaşımlar var mı?

Devrim: O da PaaS. Rainforestqa.com diye bir sistem var, onlar manuel testleri yapıyorlar. Amazon Mechanical Turk’den 2000-3000 testerları var. Biz sadece adımları belirliyoruz. Örneğin; “Şuna bastın bunu gördün mü?” gibi ve İngilizce anlaşılabilir şekilde testler yazılıyor ondan sonra deploy öncesinde rainforest’da normalde 1 hafta sürecek testler 1 saatte geri dönüyor ve deniyor ki “tamam hepsi geçti”. Bunun yanı sıra Selenium testlerimiz var. Selenium’da SauceLabs kullanıyorduk ama çok yavaş kaldığı için onu yapmıyoruz artık. Bunun yanında unit test’lerimiz de var.

Derya: Branching’e bakış açınızı öğrenebilir miyim? Mesela Trunk-based development vs over-branching gibi konulara bakış açınız nedir?

Devrim: Biz GitHub’da çalışıyoruz, GitLab’de çalışsak durum daha farklı olurdu. Gitlab’da main repoyu forklamanıza gerek yok. Orada direk merge request yapabiliyorsun ama orada codebase çok şişmeye başlıyor çünkü her yaptığın branch ana repoya yazılmış oluyor. Arada commitleri rebase etmek gerekiyor. Github’daki biraz daha temiz, başlangıç biraz daha komplike ama daha temiz oluyor. Over-branching yine oluyor ve çok fazla branch oluşmaya başlıyor ama bunların repoyu kirletmesi kısa bir zaman değil, o yüzden büyük bir problem olmuyor. Çünkü görüyorum bizim çocuklar “hadi branchlerı silelim artık, 1 senelik branchler oluşmaya başladı” diyorlar arada sırada, ama çok nadir.

Derya: Son olarak, önümüzdeki hedefleriniz nelerdir?

Devrim: Koding yaklaşık olarak %98 “feature complete” oldu ve şu anda ana feature olarak yeni birşey yok, sadece sunduğumuz feature set içerisinde eksikliklerimiz var. Mesela Cloud connector olarak AWS ve Vagrant destekliyoruz şu anda. Bunun yanında Gitlab ile enterge olacağız, Kubernetes, Google Cloud Platform, Microsoft Azure, Digital Ocean’a kadar farklı connector’lerimizi yazacağız. Bunun yanında özellikle kurumsal müşteriler Single Sign-on (SSO) gibi özellikler de istiyorlar. Ve asıl Koding’i OpenSource yapacağız (Bu yazının yayınlandığı sıralarda yapılmıştı). Baştan sona kadar, bu işte bizim için büyük bir haber. Artık bundan sonra yazılım geliştirmenin özellikle entegrasyonlar kısmının iç dünyamızdan, dışarıya doğru da açılmasını istiyoruz. Tüm ortam gereksinimlerini “Domain Specific Language (DSL) olarak bir dosya içine kodladığın zaman Koding bunları ayağa kaldırıyor ve böylelikle örnek bir her türlü proje için gereken 1 veya 50 server, 5 gigabyte veya 20 petabyte storage gibi gereksinimler elle manuel olarak yönetmek yazılımcının işi olmaktan çıkıyor, ama tabii yazılımcının da her an gözü önünde kalmaya devam ediyor.

Derya: Devrim Bey’e bize Koding’in geçmişini ve gelecekteki planlarını derinlemesine anlatarak sorularımıza gösterdiği özen ve keyifli sohbeti için teşekkürlerimi iletiyorum. DevOps Turkey olarak Koding’i takip etmeye devam edeceğiz.

koding


Biz bu yazıyı yayınladığımız saatlerde Koding OpenSource olmuştu ve bu gelişmenin bizi şimdiden heyecanlandırdığını söylememiz gerek. Tüm herkesi Koding’e contribution yapmaya davet ediyoruz.