2017 Mart ile başlayan ve 2018 Temmuz ayında sona eren Iven maceramdan bahsetmek istiyorum. Bir buçuk sene içerisinde karşılaştığımız birçok sorun ve sıkıntının yanında heyecan verici ve bol öğrenmeli bir deneyim oldu benim için. Bu yazının ise aldığımız kararlar, hatalarımız ve güzel yaptığımız seyler üzerine geç kalınmış bir derleme olmasını umuyorum.

Bütün hikayeyi tek bir yazıya sığdırmak zor olacak. Bu nedenle bu yazı giriş niteliğinde olacaktır. Yapabildiğim kadarıyla sistematik bir şekilde yazmayı deneyeceğim. Yine de söz vermeyeyim . Serüvenimin taslağını aşağıdaki gibi başlıklara bölümledim. Kolay okunmasını diliyorum.

  • IoT Dünyası ile Tanışmam
  • A'dan Z'ye Geliştirme Süreci
  • Domain Driven Design ile Kültürel Yapılanma (hazırlanıyor...)
  • Bir Startup'ın İşe Alım Kriterleri (hazırlanıyor...)
  • Apache Kafka, Apache Flink ve Lagom'un Muhteşem Uyumu (hazırlanıyor...)
  • Çağın Modası "DevOps" (hazırlanıyor...)

IoT Dünyası ile Tanışmam

Iven'de çalışmaya, büyük ölçekli bir platform geliştirme zorluğunu kabul etmekle başlamaya karar verdim diyebilirim. Genç bir ekibin elindeki mevcut fırsatları zorlayarak geliştirdiği amatör ruhlu IoT platformunun artık ölçeklenebilmesi gerektiği bir zamanda, daha ciddi bir teknoloji alt yapısıyla yeniden yazılması fikri ortaya atılmış. Vizyoner bir karar ama net değil. Turkiyede, IoT alanında gelişme ve ilerleme o kadar da hızlı ve rahat değil (rahatlıktan kastım, kendisini iyi ifade edebilen diyebilirim). Özellikle halen dijital dönüşüm başlığı altında IoT'nin faydaları ve gerekliliği üzerinde hem fikir olamamış sektör liderleri firmalarımızın öncelikle bu girişimleri desteklemeleri ve yatırım yapmaları gerekiyor. Tabi onlar da haklılar, ülke olarak çözülmesi gereken daha onemli sorunlarla uğraşıyoruz (!)

Iven, müşterileri ev eşyaları üreticilerinden, endüstriyel cihaz üreticilerine (medikal cihazlar, otomatlar, fırınlar.. vs), donanım üreticileri partnerlerine kadar geniş bir grubun içinde yer alıyor. Ayrıca IoT, sektörel olarak birden fazla partinin bir arada hareket etmesi gereken bir ekosistem ile beraber anlam kazanıyor.

Image Description

Yukarıdaki resim, bir IoT uygulaması gercekleştirebilmek icin gereken teknoloji katmanlarını gösteriyor.

  • Donanım (bildiğimiz cihazlar)
  • Donanımın icinde, sözüm ona, onu akıllı yapan yazılım (firmware)
  • İletişim protokolü (Wifi, Bluetooth vs)
  • Cihazlardan alınan veriyi karşılayan, saklayan ve anlamlandıran, aynı zamanda cihaz ve son kullanıcı arasındaki iletişimi de saglayan bulut katmanı (cloud platform)
  • Platformun sunduğu servisleri kullanarak belirli bir amaç için geliştirilecek uygulamalar

Bu katmanları ortak olarak ilgilendiren bir başkası ise "Güvenlik" konusu. Güvenlik, hem cihaz tarafli hem de son kullanıcıların iletişiminde olduğu cihaz + uygulamalar tarafında da dikkat edilmesi gereken önemli bir mesele haline gelmiş durumda. Otoriteler 2020 - 2025 yıllarına geldiğimizde dünyada 80 milyar akıllı ve internete bağlı cihaz sayısına ulaşacağımızı öngörürken aynı oranda güvenlik problemlerinin de onemli ve karmaşık hale geldiğini belirtmektedir. Şu site üzerinden en kötü 5 IoT güvenlik zafiyet örneklerine bakabilirsiniz. Iven güvenlik konusunda neler düşündü ve uyguladı bahsetmeye çalışırım.

Yeni bir Platform Gelistirme Fikri

Index.co üzerinden bakacak olursak, Xively, Cumulocity, Arrayent, Nest, Carriots gibi IoT platformlarının Google, Amazon, Software AG gibi firmalar tarafından satın alınması önemli gelişmeler. Gartner'in 2017 de yayınladığı hype cycle grafiğine bakacak olursak, IoT platformları, Gartner'in tanımladığı "Peak of Inflated Expectations" evresinde yer alır. Herkesin o dönem içinde kabul gören en onemli/büyük teknoloji gelişmelerinin yer aldığı bu tepede, Machine learning, Deep Learning, Autonomous Vehicles, Connected home gibi diğer teknoloji gelişmeleri de bulunmaktadır.

Image Description

Bu kadar rakip varken yeni bir platform geliştirmek doğru mu ?

IoT platform pazarı yatay ve dikey olarak ikiye ayrılıyor. Yatay eksende Google, AWS, IBM, Microsoft, Thingworx gibi platform devleri yer alıyor. Hemen hemen her sektör için alt yapı sağlayabilecek şekilde kendilerini konumlandıran bu devler ile yarışabilmek için haklı ve geçerli sebepleriniz olmalı. Önce belli başlı IoT platformları için ortak olan ana bileşenlerden bahsedelim.

Aşağıdaki blok diagram Microsoft Azure IoT platformunun referans mimarisini gösteriyor. Microsoft, alt yapısının açıkça nelerden oluştuğunu anlatan bir döküman oluşturmuş ve bunu halka açık yapmış (dökümana buradan ulaşabilirsiniz).

Image Description

Peki bunu neden yapıyor ? İşletim sistemi pazarında yıllarca liderliğini korumuş ve sektör önderliği konusunda oldukça hırçın olan Microsoft, IoT konusunda da sektöre yön vermek istiyor. Bunu da standardı tam oturmayan IoT sektöründe yapmaya çalışıyor. Bunu sadece Microsoft degil adı duyulmuş, duyulmaya yeni başlamış neredeyse her IoT platform şirketi mimari yapılarını dışarı açarak adeta birbirlerine meydan okuyorlar. Genel olarak bu dökümanlarda, cihazlardan verilerin nasıl alındıklarından, veriyi canlı veya yarı-canlı olarak analiz yöntemlerine, yüksek hacimli verinin nasıl işlenmesi ve saklanması gerektiğinden, bunların yöntem ve prensiplerinin ne ve nasıl olması gerektiğine kadar bizi aydınlatmaya çalışıyorlar. Açıkçası hepsi sonunda su döngüyü uyguluyor :

(Topla) Collect -> (İşle) Process -> (Sakla) Store -> (Analiz et) Analyze

Örneğin AWS IoT bir IoT platformunda olması gereken temel mimari yapıyı sunmaktadır. Bileşenlerini istediğiniz gibi kullanabileceğiniz bir model sunduğu için istediğiniz servisi alıp kullanabilirsiniz. Ancak yine işler sanıldığı kadar kolay olmuyor. Türkiye'deki firmalar yatayda konumlanmış bu tarz platformlardan hizmet almak istediklerinde sert kayaya tosluyorlar. Vestel, Arcelik, Arzum, Beko gibi Turkiye'de ev eşyaları endüstrisinde tanınan markaların karşılaştığı güçlüklerden biri de IoT'leşme süreçlerindeki bu tercihlerinden kaynaklı hesaba katmadıkları öğrenme güçlüğü ve adaptasyon sorunları (learning-curve) ve keşif süreçlerindeki zorluklar oluyor. Zaten firmaların bu tarz "hype" teknoloji ağırlıklı gelişmeleri takip edebilmek adına yaptıkları yatırımlar, "modaya ayak uyduralım, kervanı yolda düzelim ..." anlayışı ile olduğu zaman başarısızlıkla yüzleşiyorlar.

Kısacası IoT çözümleri anahtar teslim olamıyor, olmamalı da. Iven'de bu zorlukları aşabilmek icin bütün süreci 3'e bölerek değerlendirmeye karar vermiştik.

Seviye 0, Müşteriyi Anlamak ve Keşif Süreci

Bu seviyede müşterinin istekleri ve ihtiyaçları analiz ediliyor. Keşif süreci de diyebileceğimiz bu evrede IoT ürünleri üretmek isteyen firmaların doğru yönlendirilmesi sağlanılmalıdır. Hizmet alanı/üretilen ürünün uygunluğu analiz edilir ve maksimum fayda sağlamak için çalışmalar yapılır.

Seviye 1, Teknoloji Entegrasyonu

İhtiyaçları daha gercekçi olan ve amacı olan bir değişim/dönüşüm süreci içine artık teknoloji de dahil olmalı ve bu amaç doğrultusunda transformasyonu destekleyecek her birim bu sürece dahil olmalıdır. Iven, bu evrede yer alan ve teknoloji alt yapısını da saglayan bir pozisyonda bulunuyor.

Yerel pazarda, yatayda konumlanan büyük rakipler gibi IoT platformu satmaya çalışmak pek mantıklı değil. Özellikle startuplar için riskli bir yatırım olabilir. Açıkçası bu seviyelendirme yöntemiyle müşterilere yaklaşmak da bizim gibi bir oyuncuyu daha tercih edilebilir kılıyor. Müşterilerle yakın ve zamana yayarak çalışmak daha verimli sonuçlar doğuracak gibi görünüyor. Müşteriye daha yakın olabilmek ve onların hem süreçsel hem de teknoloji ile alakalı her türlü ihtiyaçlarına, taleplerine geri dönüş yapabilmek için kendine ait bir platform ile bunu yapmak istemesi de çok mantıksız görünmüyor.

Veri toplamak, işlemek, saklamak ve analiz etmekten ibaret olan teknolojiyi yani platformu geliştirmek için harcadığımız 1 bucuk sene içinde nelerle karşılaştık onlardan bahsetmeye başlayabilirim artık. Buraya kadar uzun bir giriş yaptım biliyorum. Ama öncesinde ne sebeple aşağıdaki sıraladığım işlere kalkıştık onu anlatmayı da gerekli gördüm.

Yeni bir IoT platformunun en baştan geliştirilmesi fikrinin ne kadar doğru ya da yanlış olduğuna siz karar verin. Ama önce bu serüvenin mühendislik tarafındaki detaylara inelim.

A'dan Z'ye Geliştirme Süreci
  • Başlama vuruşu
  • Kurallar ve Prensipler
  • Voltranı oluşturmak
  • Teknoloji ve Mimari
  • Geliştirme süreci
  • İletişim
  • DevOps
Nereden başlamalıyız ?

Elbette önce ne yapacağımızı bilmemiz gerekiyor. Bu konuda önemli ölçüde yatırım yaptık. Zamanımızın büyük bir kısmını şirketin gitmek istediği yeri anlamaya ve doğru hamleleri yapmaya çalıştık. Fakat bu konuda biraz fazla zaman kaybettiğimiz konusundaki öz eleştirimizi de esirgemiyoruz. 4 - 5 ay gibi bir süre harcayarak IoT platformunun neye benzemesi gerektiğine karar verdik. Bunu da bir yönteme uyarak yapmak en doğrusuydu. Biz de IBM'in Disciplined Agile Delivery adında bir agile proje yönetim yaklaşımını dikkate alarak yaptık. Oldukça faydasını gördüğümüzü söyleyebilirim. Eğer inceleme fırsatı bulabilirseniz tavsiye ederim. Özellikle büyük ölçekli bir proje geliştirmeye başlayacaksanız DAD kullanabilirsiniz. Ama her boyuttaki projeler için de kullanılabilir diye düşünüyorum.

DAD nedir ? Nasıl İşimize Yaradı ?

Disciplined Agile Delivery (hiç tr'ye çevirme niyetim yok :)), bu linkte DAD'nin tercih edilmesinin 10 sebebi sıralanmış.

Kısaca DAD; yazılım geliştirme sürecinin zorluklarını sadece teknik odaklı bir anlayışla değil de çözüm odaklı bir perspektifle aşmaya çalışıyor. Bildiğimiz agile geliştirme metotlarından birini seçebilecek bir çatı sunarak, bizi herhangi birinin sunduğu reçeteye uymak zorunda bırakmıyor. Bu sayede mevcut koşullara uygun olacak şekilde strateji değişikliğini kabul ediyor ve destekliyor. Bir süreç karar çatısı ortaya koyuyor diyebilirim.

Çoğumuzun yolun başında yapmayı unuttuğumuz veya yapmaya erindiğimiz konuların önemine değiniyor. Konsept belirlenmesi, başlangıç için gerekli hazirlıkların yapılması, geliştirme sürecinde kanban, scrum, scrumban gibi herhangi bir agile yöntemin aparat gibi takıp çıkarılarak uygulanabilmesi konusunda da yöntemler ortaya koyuyor.

Tam bu noktada DAD'nin neden bizim işimize yaradığını anlamak kolaylaşıyor. Büyük ölçekli (large-scale) bir projeye start verdikten sonra ipin ucunu kaçırmak çok kolay. Ortaya çıkan ürünün/platformun/sistemin ana kullanıcılarını tanımlamaktan tutun da, satışı yapılacak bir ürün ise satış ve teslimat (delivery) süreçlerine kadar her konuyu düşünmeniz ve beklediğiniz çıktıları ona göre şekillendirmeniz gerekiyor. Eğer düşünmeniz gereken şeylerin listesini oluşturmak zorlaşıyorsa DAD bu konuda aradığınız şey olabilir.

Bize gereksinimlerimizi toplamaya yardımcı olan ve geliştirme öncesi üzerinde çalışılması gerekenleri derlememizi kolaylaştıran listemizi özetliyorum.

DAD bütün proje sürecini 3 bölüme ayırıyor. İlk etap olan Başlangıç Aşamasında (Inception Phase) bazı hedefleri yerine getirmemiz gerekiyor. Bunlar :

Takımını kur

Bir proje başlangıcında herhalde en zorlu konu takımın kurulması olabilir. Doğru insanları doğru rollerle bir araya getirmeyi, işin yarısını tamamlamak olarak görüyorum. Eğer doğru insanlar bir araya gelemiyorsa istediğiniz kadar uğraşın, modeller çizin, planlar yapıp hedefler koyun. Öyle ya da böyle başarılı olmanız çok kolay değil.

(Bir startupın nasıl elemanlara ihtiyacı olmalı konusunda da bir yazı hazırlıyorum)

Ortak vizyon geliştir

Takımınla iletişim yöntemine karar ver, stratejini oluştur. Çalışma şeklin ve düzeni hakkında kararlar ver ve birliktelik nasıl sağlanacak tartış.

Dökümantasyon ! Herşey (hemen hemen) dökümante edilmeli. Aslında temel iletişim modelimiz dökümantasyon üzerine oldu. Yani konuştuğumuz karar verdiğimiz, yapacağımız herşey dökümanlar üzerinden ilerledi.

Sanırım şimdiye kadar yaptığım en faydalı şey bu oldu. Yani dökümantasyonun önemini aktarabilmek. Ne zaman döküman desem insanlar korkuyorlar. Nedense birine döküman yaz demek ona verilebilecek en ağır iş gibi geliyor. Halbuki dökümanlar da agile olduğu müddetçe bir yazılımcının kendisini yanlış anlaşılmalardan koruyabilmesinin en basit yolu oluyor. Yani geleneksel yöntemlerle hazırlanmış dökümanlar değil, daha çok sistemi genel olarak tanımlayan, belirli bir yöntemle hazırlanmış, çizimlerle desteklenmiş dökümanlar gayet yeterli olacaktır. Bu işi kurum kültürüne entegre edebilmek zor bir konu olsa da, orantılı bir şekilde bunu başabilmiş olmamızdan ötürü karşılığını farklı şekillerde aldığımızı da söylemeliyim (Tübitak hibe programlarından 1501 için çok az efor harcamış olmamız, yeni gelenlerin oryantasyon süreçleri gibi).

Kurumun fikri mülkiyetini (IP : Intellectual Property) yönetebilmesi ve saklayabilmesinin başka bir yolu var mı bilmiyorum. Patentleri, ulusal ve uluslararası proje başvurularının hepsi dökümanlardan oluşuyor. Buna ek olarak şirketin başarısızlık/darboğaz noktalarını (single point of failure) ortadan kaldırması şirketin kendine yapabileceği en iyi yatırım olarak görüyorum. En basit şekliyle, müşteriye yapılacak olan bir sistemin kurulumuyla ilgili detaylar sadece bir kişinin kafasındakilerden ibaret ise ve bu kişi bir şekilde ortalarda yoksa başarısız oldunuz. Bu konuyla ilgili güzel bir yazı (truck factor) var okumanızı tavsiye ederim.

Kurumun stratejisi ile paralel hareket et

Şirketin mevcut koşulları değerlendirilmelidir. Pazardaki stratejisine uygun hareket etmeli ve finansal durumlardan haberdar olunması gerekmektedir.

Iven'ki yanlışlarımızdan birisi de kurum stratejisini iyi tanımlayamamaktan kaynaklandı. IoT pazarındaki yeri önce platform üreticileri ile aynı seviyede iken sonrasında bunun çok ciddi yatırım gerektirdiği ortaya çıktı. Halbuki bunu en baştan hesaba katmalıydık. İlk başlarda belirttiğim gibi "yataydaki platformlar" ile rekabete girmek Türkiye içerisinde çok da mantıksız görünmese de, bunun için şirketin kaynaklarının yeterli olup olmadığının iyi analiz edilmesi gerekiyordu. Bir süre sonra Iven stratejisini değiştirerek, odağını ev aletleri (home appliances), elektronik eşyalar, HVAC (heater, vantilator, air conditioners), aydınlatma, wellness pazarlarında internete bağlı ürün (connected products) geliştirme üzerine vermiş oldu. Bu önemli ve doğru bir adımdı. Daha belirgin ve net bir pazara hitap ediyor olmak, dışarıya platform şirketi görünümünden çok işini iyi bilen, IoT ve dijitalleşme süreçlerinde müşterilerinin yanında yer alma sözü veren ve her iki seviyede de (seviye 0 ve 1) destek veren, kendi yerli teknoloji alt yapısını kullanan bir şirket profili çizmek istemesi çok mantıklıydı.

Mimari ve teknoloji alt yapısı konusunda verilecek kararlar tamamen buradaki tetkiklere bağlı olarak değişmelidir. Herşeye en baştan başlamak çok da akıllıca olmasa da, geldiğimiz noktada başarı veya başarısızlığın teknoloji veya mimari yöntemlerin seçimine bağlı olmadığını da görüyor olduk. Ayrıntıları yazılarımın devamında keşfetmenizi isterim.

Kapsamı keşfet

Kapsam keşfi ile ne yapacağımızı en kaba düzeyde netleştirmemiz gerekiyor. Kapsam belirlemek için çok çeşitli yöntemler tercih edilebiliyor. Yöntemler, projenin tipine (müşteri talebine göre, şirketin kendi ürünü vb.) ve koşulların uygunluğuna göre belirlenebilir. Kapsam detayına ne kadar inilmesi gerekiyorsa bu da proje tipine göre değişecektir. Bu sürede,

  • Kullanım senaryolarının ne kadar detaylı analiz edilmesi gerekiyor ?
  • İş süreçlerinin tanımlanması (business processes) gerekiyor mu ? Gerekiyorsa ne kadar detayda tanımlanması gerekiyor ?
  • Sistemin/Ürünün kullanıcıları var mı ? varsa personaların tanımlanması gerekiyor mu ?
  • UI (user interface) ihtiyacı var mı ? Mockup, wireframe gibi çizimler gerekiyor mu ?
  • Fonksiyonel olmayan durumlar için kabul kriterlerinin belirlenmesi gerekiyor mu ?
  • Geliştirme süreci için görevlerin oluşturulma stratejisi ne olmalı ? (Scrum, Kanban) Makul yönteme karar verilmeli. İş takibi için nasıl bir yöntem izlenecek ?

Yukarıdaki soruların cevaplarını bulmaya çalıştık. Makul düzeyde de dökümante ettik. En başta Trello üzerinde bu gibi işlerin takibini yapmaya başlamıştık. Sonrasinda JIRA ve Confluence'u birlikte kullanmaya başladık.

Platformun kullanıcılarının persona analizlerini farklı profillerdeki kullanıcı adayları ile görüşmeler yaparak çıkarmaya çalıştık, genel temaların belirlenmesi ve ihtiyaçların ortaya çıkmasıyla süreçlerin çıktılarını Confluence üzerinde kayıt altına aldık. Ayrıca rakip firmaların analizlerini de yine Confluence'a ekledik. (Tavsiye : şirketinizin döküman alanına güzel bir isim bulun. Bizimki IVENPEDIA'ydı )

Mimari ve teknik stratejini belirle

Bu aşamada projenin sıfırdan mı tasarlanacağı veya referans bir mimari üzerinde mi çalışılacağı ya da satın alınan ticari bir ürün mü kullanılacağı konuları tartışılıyor. Bizim yaptığımız ise referans mimarileri sentezleyip onun üzerine bir yapı geliştirmek oldu. Aslında neredeyse herşeyi en baştan yapmayı planlamıştık. Örnek alabileceğimiz oldukça başarılı referans mimariler vardı. Diğer bir konu ise teknoloji seçimimizin ne olması gerektiğiydi. Bir CTO'nun sanırım en kritik görevlerinden birisi de teknoloji seçimleridir. Bu noktadaki seçimler şirketi çok büyük zararlara götürebileceği gibi hem ekibi hem de şirketi çok güzel noktalara da taşıyabilir.

Uzun yıllar JVM ekosisteminde dolaşan biri olarak elimde çok da fazla seçenek olduğunu söyleyemezdim. Koşullar teknoloji seçimlerini de etkiliyor. Öncelikle geliştirme yükü fazla olacak bir proje için programlama dili konusunda dikkatli olmak gerekiyor. Ekibin seçilecek dil(ler) veya araç(lar) konusundaki bilgisi, yatkınlığı ve eğitimleri çok önemli bir konu. Ayrıca ilk etapta 10 binlerce cihazın bağlı olacağı ve çok hızlı şekilde yükün artacağını planlayarak işe başlıyorsanız en iyi kozunuzu kullanmak istemeniz çok doğal olacaktır (tabi ki Java).

4 - 5 aylık başlangıç süresi içinde mimari yapının neye benzemesi ve alt yapımızda ne gibi yöntemler ve teknolojiler kullanmamız gerektiğine karar vermeye çalıştık. Aslında işin en güzel kısımları burada başlıyor. Normalde DAD bu kararları hızlıca verdikten sonra "prove architecture early", yani mimari yapını erkenden ispatla der. Bunu da geliştirme aşamasına geldiğimizde yapabiliriz. Fakat o kadar çok prensip ve yöntem üzerinde hemfikir olduk ki (gerekli olduğuna inandık diyelim) hızlıca PoC (proof of concept) yapabileceğimiz kadar küçük bir yapıyı kurmak bile çok zamanımızı aldı. Peki neydi bu üzerinde hem fikir olduğumuz prensipler ve yöntemler ?

  • Domain Driven Design uygulamak
  • Event Sourcing ve CQRS
  • Event driven, message passing ve actor based programlama (Akka.io)
  • Kappa mimarisi
  • Real time stream processing (teknoloji : Apache Flink)
  • Microservice mimarisi (teknoloji : Lagom Framework)
  • Cihazlardan veri toplamak için MQTT broker (teknoloji : eMqtt)
  • Polyglot persistence (Cassandra, MySQL, Redis, Elasticsearch)
  • Streaming -> Apache Kafka
  • Kubernetes, AWS
  • UI ReactJs
  • Continuous Integration ve Delivery (Jenkins)
  • Unit ve Integration testler
  • Trunk based geliştirme (Bitbucket ve Jira)
  • Code review ve Pull request zorunluluğu

Evet ! tam olarak yukarıdakilerin hepsi bizim kurguladığımız sistemin ana çatısını oluşturuyor. Daha belirtmediklerim bile olabilir. İlk bakışta korkutucu görünüyor ama içine girdiğimiz işi en baştan tasarlayıp kendimiz geliştireceksek bunlara ihtiyacımız var. Bu konuda eleştiriler aldığım da oldu ama önceden de dediğim gibi Iven'in tam olarak sahip olmak istediği buydu. (o zamanlar öyleydi ). Bunları nasıl uyguladığımızı ve platformu hayata geçirirken nelerle karşılaştığımızı daha sonraki yazılarda anlatmayı planlıyorum.