Yazılım Geliştirme
AI, IoT ve Bulutu Birlikte Kullanan Ürün Geliştirmek
AI, IoT ve Bulutu Birlikte Kullanan Ürün Geliştirmek
AI, IoT ve bulutu tek üründe birleştirmek bir trend hikayesi değil, mimari bir problem. Bu yazı veri akışlarını, edge ve bulut çıkarım kararlarını ve üçünü birlikte geliştirirken gerçekte ne değiştiğini anlatıyor.
AI, IoT ve bulutu tek üründe birleştirmek bir trend hikayesi değil, mimari bir problem. Bu yazı veri akışlarını, edge ve bulut çıkarım kararlarını ve üçünü birlikte geliştirirken gerçekte ne değiştiğini anlatıyor.
AI, IoT ve Bulutu Birlikte Kullanan Bir Ürün Geliştirmek: Entegrasyon Gerçekte Böyle Görünür
AI, IoT ve bulut yakınsaması üzerine konuşmalar çoğunlukla makro düzeyde kalır: pazar büyüklükleri, dönüşüm eğrileri, bağlı cihazların geleceği. Yatırım notları için işe yarayan bu çerçeve, gerçekte çalışan bir şey kurmaya çalışan ürün ekibi için bir anlam taşımaz.
Asıl soru daha somuttur. Ürününüzün fiziksel cihazlardan veri toplaması, bu veri üzerinde AI çalıştırması ve sonuçları mobil ya da web uygulaması üzerinden kullanıcılara iletmesi gerekiyorsa, mimari nasıl görünür? Her iş yükü nerede çalışır? Entegrasyon noktaları demoda değil, canlı ortamda nerede bozulur?
Bu bir trend meselesi değil, mimari meseledir. Mimari meselelerin de belirli yanıtları vardır.
"AI Ekleyelim" Neden Neredeyse Her Zaman Tutmaz
Birleşik AI-IoT ürünlerinde en sık rastlanan başarısızlık, AI'ı IoT katmanı kurulduktan sonra eklenecek bir özellik gibi düşünmekten kaynaklanır. Cihaz buluta veri gönderir, bulut saklar; bir noktada "analiz etmek" için AI devreye sokulur.
Bu sıra iki nedenden çalışmaz. Birincisi, veri akışı ML sorguları için değil, depolama için tasarlanmıştır. İlişkisel bir veritabanında biriken zaman serisi verisi, AI bir günlük okumadan fazlasını taraması gerektiğinde performans duvarına çarpar. İkincisi, gecikme hesabı tutmaz. Bir sensörün eşik aşımında uyarı üretmesi, hasar oluşmadan önce anomali yakalaması ya da cihaz davranışını anında düzenlemesi gerekiyorsa, bulut gidiş-dönüş gecikmesi bu bütçeye çoğu zaman sığmaz. Güvenilir bağlantıda bile yüzlerce milisaniyeyi bulan bu gidiş-dönüş, güvenilmez bağlantıda saniyelerle ölçülür.
AI, ilerleyen bir geliştirme döneminde değil ilk tasarım oturumunda mimarinin içinde yer almak zorundadır.
Üç Katman ve Her Birinde Ne Çalışır
AI-IoT-bulut ürününün birbirinden ayrı üç katmanı vardır; her birinin farklı işleme sorumlulukları vardır. Çoğu ekibin yaptığı hata, bu katmanları kod yazmaya başlamadan net biçimde ayırt etmemektir.
İş yükü | 2026'da nerede çalışır | Neden |
Gerçek zamanlı anomali tespiti | Edge / cihaz üzerinde | 100ms altı zorunlu; bulut gidiş-dönüşü çok yavaş |
Hareket veya örüntü sınıflandırması | Edge / mobil ağ geçidi | Gizlilik ve gecikme; bulut bağımlılığı yok |
Model eğitimi ve yeniden eğitimi | Bulut | Toplu veri ve GPU altyapısı gerektirir |
Filo genelinde trend analizi | Bulut | Toplu veri; gecikme hassasiyeti yok |
OTA model güncellemeleri | Bulut başlatır, edge yürütür | Merkezi kontrol, yerel yürütme |
Gizlilik hassasiyeti yüksek çıkarım | Yalnızca edge | Veri ağ sınırını hiç aşmaz |
Çok noktalı toplu raporlama | Bulut | Merkezi, toplu, gerçek zamanlı değil |
2026'daki pratik kural şudur: Kararın 200ms içinde alınması gerekiyorsa çıkarım edge'de çalışır; çok sayıda cihazdan veri ya da geçmiş örüntüler gerekiyorsa bulut devreye girer. Çoğu canlı ortam dağıtımı hibrit bir yapı izler: edge, gecikmeye duyarlı çıkarımı ve yerel kontrolü üstlenirken bulut model eğitimini, filo performans izlemesini ve toplu veriden beslenen karmaşık analitiği yönetir.
Edge AI yonga setleri kritik bir eşiği geride bıraktı. Orta segment akıllı telefonlarda cihaz üzerinde AI çıkarımı, TensorFlow Lite, ONNX Runtime ya da Apple'ın Core ML'i kullanılarak canlı ortam bilgisayarlı görme modellerinde 20ms altına indi. IoT donanımı için TensorFlow Lite Micro ile Qualcomm ve MediaTek'in çerçeveleri, düğme piliyle çalışan cihazlarda anomali tespiti yapmayı gerçek bir seçenek haline getiriyor.
Veri Nereye Akıyor: Gerçek Veri Akışı
AI'ın nerede konumlandığını kavramak, cihazdan kullanıcıya uzanan tam veri akışını anlamayı gerektirir. İyi tasarlanmış bir akış beş aşamadan oluşur; her aşamanın kendi teknoloji kararları vardır.
1. Aşama: Cihazdan bağlantı katmanına. Sensörler veri üretir; protokol seçimi bu verinin bir sonraki katmana nasıl ulaşacağını belirler. Buluta bağlı ürünlerin büyük çoğunluğunda standart yol, AWS IoT Core ya da Azure IoT Hub'a MQTT'dir. Tüketici sağlığı ve fitness ürünlerinde yaygın olan akıllı telefon-ağ geçidi mimarisinde ise akış şöyledir: cihazdan BLE aracılığıyla telefona, oradan REST ya da MQTT üzerinden buluta.
2. Aşama: Edge işleme. Veri buluta ulaşmadan filtrelenebilir, toplanabilir ve analiz edilebilir; edge AI tam burada devreye girer. Cihazda ya da mobil ağ geçidinde çalışan TensorFlow Lite modelleri, buluta gönderilen veri hacmini düşürürken bulut bağımlılığı olmadan anında yerel yanıt üretir. Hareket örüntülerini cihaz üzerinde sınıflandırıp yalnızca özet istatistikler yükleyen fitness giyilebilir cihazı, edge öncelikli tasarımın tipik örneğidir. Bu mimaride mobil uygulama, veriyi olduğu gibi geçiren bir kanal değil; akıllı bir işleme düğümü olarak konumlanır.
3. Aşama: Bulut alımı ve yönlendirme. Bulut IoT hizmetleri, yukarı akıştan gelen veriyi alıp içerik ve cihaz kimliğine göre yönlendirir; depolama, işleme ve uyarı sistemlerine dağıtır. AWS IoT Core'un kurallar motoru, Azure IoT Hub'ın mesaj yönlendirme yapısı ve Google Cloud Pub/Sub ile Dataflow bu işi farklı biçimlerde yürütür. Yönlendirme kurallarını mimari aşamasında açıkça belirlemek, gerçek trafik geldiğinde ortaya çıkacak maliyetli yeniden yazımların önüne geçer.
4. Aşama: Bulutta AI çıkarımı ve analitik. Vertex AI, AWS SageMaker ya da Azure ML Studio gibi bulut AI hizmetleri, edge donanımının kaldıramayacağı iş yüklerini üstlenir: model eğitimi, yeni filo verisiyle yeniden eğitim, çok sayıda cihazda eş zamanlı örüntü tespiti. Veri depolama kararının en kritik hale geldiği yer de burasıdır; InfluxDB, Amazon Timestream ya da TimescaleDB gibi zaman serisi veritabanları, ML sorgu örüntüleri altında işlem yükü için tasarlanmış ilişkisel veritabanından çok daha iyi performans gösterir.
5. Aşama: Uygulama katmanı. Flutter ya da React Native uygulaması, bulut katmanının API'lerinden veri çeker; cihaz durumunu ve AI'ın ürettiği içgörüleri ekrana taşır; komutları cihaza geri iletir. Mobil uygulama her durumu yönetebilmek zorundadır: cihaz bağlı ve gerçek zamanlı, cihaz bağlı ama bulut çevrimdışı, yalnızca geçmiş veri erişilebilir, tamamen çevrimdışı. Her durum, kendine özgü bir arayüz ve veri sözleşmesi gerektirir.
Edge mi, Bulut mu: Çıkarım Kararı
AI-IoT ürününde en belirleyici mimari karar, çıkarımın nerede çalışacağıdır. Bu bir teknoloji tercihi değildir; dört faktör tarafından şekillenir.
Gecikme gereksinimi. AI'ın sensör verisine 200ms içinde yanıt vermesi gerekiyorsa, tek seçenek edge çıkarımıdır. Güvenlik sistemleri, gerçek zamanlı kontrol arayüzleri ve anlık fiziksel sonuçları olan anomali tespiti, varsayılan olarak edge öncelikli mimariye yönelir.
Veri gizliliği. Sensör verisi biyometri, tıbbi okumalar ya da cihazdan çıkmaması gereken kişisel bilgi içeriyorsa, cihaz üzerinde çıkarım tek savunulabilir seçenektir. Federated learning, ham veriyi hiç buluta taşımadan çok sayıda edge cihazı üzerinde model eğitimine olanak tanır; GDPR veya sağlık mevzuatı kapsamındaki ürünler için doğru yapı budur.
Model karmaşıklığı. Mevcut mobil donanım yaklaşık 500 milyon parametre altındaki modelleri işler; daha büyükler bulut altyapısı gerektirir. AI görevi büyük bir akıl yürütme modeli gerektiriyorsa, ön işleme ve filtreleme edge'de kalır, çıkarım buluta taşınır.
Bağlantı güvenilirliği. Aralıklı bağlantının kaçınılmaz olduğu ortamlarda, depolar, inşaat alanları, uzak saha noktaları, kullanıcının çevrimdışıyken de ihtiyaç duyduğu her işlev için edge AI zorunlu hale gelir. Yalnızca bulut çıkarımına dayanan ürün, bağlantı kesildiğinde AI özelliklerini de yitirir.
Bu dört faktörü karşılayan hibrit yapı şöyle kurulur: edge'de hafif ve hızlı modeller gerçek zamanlı kararları üstlenir; veri özetleri ve model performans sinyalleri yeniden eğitim için buluta gönderilir; güncellenmiş ağırlıklar planlı OTA döngüsüyle edge'e geri taşınır. Mobil uygulama, canlı edge sonuçlarını ve buluttan önbellekte tutulan geçmiş eğilimleri yan yana sunar.
Gerçekte Değişen Geliştirme Kararları
Bir ürün AI, IoT ve bulutu ardışık değil birlikte entegre ettiğinde beş karar köklü biçimde değişir.
Veri şeması tasarımı. IoT verisi doğası gereği zaman serisidir. Şemayı ML sorguları için baştan tasarlamak, zaman serisi depolamayı seçmek, saklama politikalarını belirlemek ve ham veri ile toplu özetlerin her katmanda nasıl dağıtılacağına karar vermek demektir. Gerçek cihaz filolarıyla canlı ortama geçmiş bir üründe şemayı sonradan değiştirmek hem pahalıdır hem yıkıcıdır.
Model güncelleme altyapısı. Edge AI modellerinin, firmware güncellemelerinden bağımsız kendi güncelleme mekanizması olması gerekir. Model ağırlıklarını paketleyip imzalayan, dağıtıp gerektiğinde geri alan veri akışı, ilk model canlı ortama girmeden tasarlanmış olmak zorundadır.
Mobil uygulama durum yönetimi. BLE üzerinden cihaza bağlı, edge'den gerçek zamanlı AI çıkarımı çeken ve buluttan geçmiş analitik gösteren bir uygulama, birbirinden farklı güncellik, güvenilirlik ve gecikme profili taşıyan üç ayrı veri kaynağını eş zamanlı yönetir. Her kaynağın bağımsız işlenmesi şarttır. Üçünü tek veri katmanı gibi ele almak, yeniden oluşturulması zor ve kullanıcılara açıklanması daha da güç hatalar doğurur.
Uyarı tasarımı. AI'ın IoT verisinden ürettiği uyarılar, ancak arkalarındaki eşik ve güven tasarımı kadar değerlidir. Çok sık tetiklenen anomali tespit modeli uyarı yorgunluğu yaratır, kullanıcılar bildirimleri kapatır. Eşiği gereğinden yükseğe çeken model ise yakalamak zorunda olduğu olayları gözden kaçırır. Eşik tasarımı ve bildirim UX'i, AI ekibini, ürün ekibini ve donanım ekibini geliştirme başlamadan aynı masaya oturtmayı gerektiren kararlardır.
Maliyet modeli. Ölçekte bulut AI çıkarımı pahalıdır: bulut çıkarımını tetikleyen her sensör okuması, filodaki cihaz sayısıyla çarpılır. Edge öncelikli çıkarımı benimseyip buluta yükseltmeyi yalnızca güven eşiğinin aşıldığı durumlarla sınırlamak, mimari bir tercih değil; çoğu IoT iş modeli için birim ekonomisinin zorunlu kıldığı bir karardır.
Cihaz, mobil ve bulut AI'ını kapsayan ürünler geliştiren ekipler için entegrasyon karmaşıklığı tek bir katmanda değil, katmanlar arasındaki bağlantı noktalarında yaşar. Neon Apps'in mobil uygulama geliştirme pratiği, cihazdan buluta veri akışlarını, TensorFlow Lite ve Core ML kullanan edge AI entegrasyonunu ve üçünü kullanıcılara tutarlı biçimde sunan mobil uygulama mimarisini kapsar.
Sıkça Sorulan Sorular
Bir üründe "AI, IoT ve bulutu entegre etmek" ne anlama gelir?
Neon Apps, bir ürünün üç katmana da ihtiyaç duyduğunda mimariye nasıl yaklaşır?
AI-IoT ürünü için hangi bulut platformu daha uygundur?
Neon Apps, IoT cihaz verisini bulut AI ile birleştiren mobil uygulamalar geliştiriyor mu?
Edge AI ne zaman zorunlu, ne zaman tercih meselesidir?
İlham Almaya Devam Et
Yeni tasarım içgörüleri, makaleler ve kaynaklar doğrudan gelen kutunuza gelsin.
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeleri doğrudan gelen kutunuza alın.
Son Bloglar
İlham Almaya Devam Et
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeler doğrudan gelen kutunuza gelsin.
Bir projeniz mi var?
Bize Ulaşın
Bir projeniz mi var? Startup'lar ve küresel markalar için dünya standartlarında mobil ve web uygulamaları geliştiriyoruz.
Neon Apps, İstanbul ve New York ofislerinde 85 kişilik kendi ekibiyle mobil, web ve SaaS projeleri hayata geçiren bir ürün geliştirme şirketidir. Uzun vadeli bir çözüm ortağı olarak, markalar için ölçeklenebilir dijital ürünler üretiyoruz.
Yazılım Geliştirme
AI, IoT ve Bulutu Birlikte Kullanan Ürün Geliştirmek
AI, IoT ve Bulutu Birlikte Kullanan Ürün Geliştirmek
AI, IoT ve bulutu tek üründe birleştirmek bir trend hikayesi değil, mimari bir problem. Bu yazı veri akışlarını, edge ve bulut çıkarım kararlarını ve üçünü birlikte geliştirirken gerçekte ne değiştiğini anlatıyor.
AI, IoT ve bulutu tek üründe birleştirmek bir trend hikayesi değil, mimari bir problem. Bu yazı veri akışlarını, edge ve bulut çıkarım kararlarını ve üçünü birlikte geliştirirken gerçekte ne değiştiğini anlatıyor.
AI, IoT ve Bulutu Birlikte Kullanan Bir Ürün Geliştirmek: Entegrasyon Gerçekte Böyle Görünür
AI, IoT ve bulut yakınsaması üzerine konuşmalar çoğunlukla makro düzeyde kalır: pazar büyüklükleri, dönüşüm eğrileri, bağlı cihazların geleceği. Yatırım notları için işe yarayan bu çerçeve, gerçekte çalışan bir şey kurmaya çalışan ürün ekibi için bir anlam taşımaz.
Asıl soru daha somuttur. Ürününüzün fiziksel cihazlardan veri toplaması, bu veri üzerinde AI çalıştırması ve sonuçları mobil ya da web uygulaması üzerinden kullanıcılara iletmesi gerekiyorsa, mimari nasıl görünür? Her iş yükü nerede çalışır? Entegrasyon noktaları demoda değil, canlı ortamda nerede bozulur?
Bu bir trend meselesi değil, mimari meseledir. Mimari meselelerin de belirli yanıtları vardır.
"AI Ekleyelim" Neden Neredeyse Her Zaman Tutmaz
Birleşik AI-IoT ürünlerinde en sık rastlanan başarısızlık, AI'ı IoT katmanı kurulduktan sonra eklenecek bir özellik gibi düşünmekten kaynaklanır. Cihaz buluta veri gönderir, bulut saklar; bir noktada "analiz etmek" için AI devreye sokulur.
Bu sıra iki nedenden çalışmaz. Birincisi, veri akışı ML sorguları için değil, depolama için tasarlanmıştır. İlişkisel bir veritabanında biriken zaman serisi verisi, AI bir günlük okumadan fazlasını taraması gerektiğinde performans duvarına çarpar. İkincisi, gecikme hesabı tutmaz. Bir sensörün eşik aşımında uyarı üretmesi, hasar oluşmadan önce anomali yakalaması ya da cihaz davranışını anında düzenlemesi gerekiyorsa, bulut gidiş-dönüş gecikmesi bu bütçeye çoğu zaman sığmaz. Güvenilir bağlantıda bile yüzlerce milisaniyeyi bulan bu gidiş-dönüş, güvenilmez bağlantıda saniyelerle ölçülür.
AI, ilerleyen bir geliştirme döneminde değil ilk tasarım oturumunda mimarinin içinde yer almak zorundadır.
Üç Katman ve Her Birinde Ne Çalışır
AI-IoT-bulut ürününün birbirinden ayrı üç katmanı vardır; her birinin farklı işleme sorumlulukları vardır. Çoğu ekibin yaptığı hata, bu katmanları kod yazmaya başlamadan net biçimde ayırt etmemektir.
İş yükü | 2026'da nerede çalışır | Neden |
Gerçek zamanlı anomali tespiti | Edge / cihaz üzerinde | 100ms altı zorunlu; bulut gidiş-dönüşü çok yavaş |
Hareket veya örüntü sınıflandırması | Edge / mobil ağ geçidi | Gizlilik ve gecikme; bulut bağımlılığı yok |
Model eğitimi ve yeniden eğitimi | Bulut | Toplu veri ve GPU altyapısı gerektirir |
Filo genelinde trend analizi | Bulut | Toplu veri; gecikme hassasiyeti yok |
OTA model güncellemeleri | Bulut başlatır, edge yürütür | Merkezi kontrol, yerel yürütme |
Gizlilik hassasiyeti yüksek çıkarım | Yalnızca edge | Veri ağ sınırını hiç aşmaz |
Çok noktalı toplu raporlama | Bulut | Merkezi, toplu, gerçek zamanlı değil |
2026'daki pratik kural şudur: Kararın 200ms içinde alınması gerekiyorsa çıkarım edge'de çalışır; çok sayıda cihazdan veri ya da geçmiş örüntüler gerekiyorsa bulut devreye girer. Çoğu canlı ortam dağıtımı hibrit bir yapı izler: edge, gecikmeye duyarlı çıkarımı ve yerel kontrolü üstlenirken bulut model eğitimini, filo performans izlemesini ve toplu veriden beslenen karmaşık analitiği yönetir.
Edge AI yonga setleri kritik bir eşiği geride bıraktı. Orta segment akıllı telefonlarda cihaz üzerinde AI çıkarımı, TensorFlow Lite, ONNX Runtime ya da Apple'ın Core ML'i kullanılarak canlı ortam bilgisayarlı görme modellerinde 20ms altına indi. IoT donanımı için TensorFlow Lite Micro ile Qualcomm ve MediaTek'in çerçeveleri, düğme piliyle çalışan cihazlarda anomali tespiti yapmayı gerçek bir seçenek haline getiriyor.
Veri Nereye Akıyor: Gerçek Veri Akışı
AI'ın nerede konumlandığını kavramak, cihazdan kullanıcıya uzanan tam veri akışını anlamayı gerektirir. İyi tasarlanmış bir akış beş aşamadan oluşur; her aşamanın kendi teknoloji kararları vardır.
1. Aşama: Cihazdan bağlantı katmanına. Sensörler veri üretir; protokol seçimi bu verinin bir sonraki katmana nasıl ulaşacağını belirler. Buluta bağlı ürünlerin büyük çoğunluğunda standart yol, AWS IoT Core ya da Azure IoT Hub'a MQTT'dir. Tüketici sağlığı ve fitness ürünlerinde yaygın olan akıllı telefon-ağ geçidi mimarisinde ise akış şöyledir: cihazdan BLE aracılığıyla telefona, oradan REST ya da MQTT üzerinden buluta.
2. Aşama: Edge işleme. Veri buluta ulaşmadan filtrelenebilir, toplanabilir ve analiz edilebilir; edge AI tam burada devreye girer. Cihazda ya da mobil ağ geçidinde çalışan TensorFlow Lite modelleri, buluta gönderilen veri hacmini düşürürken bulut bağımlılığı olmadan anında yerel yanıt üretir. Hareket örüntülerini cihaz üzerinde sınıflandırıp yalnızca özet istatistikler yükleyen fitness giyilebilir cihazı, edge öncelikli tasarımın tipik örneğidir. Bu mimaride mobil uygulama, veriyi olduğu gibi geçiren bir kanal değil; akıllı bir işleme düğümü olarak konumlanır.
3. Aşama: Bulut alımı ve yönlendirme. Bulut IoT hizmetleri, yukarı akıştan gelen veriyi alıp içerik ve cihaz kimliğine göre yönlendirir; depolama, işleme ve uyarı sistemlerine dağıtır. AWS IoT Core'un kurallar motoru, Azure IoT Hub'ın mesaj yönlendirme yapısı ve Google Cloud Pub/Sub ile Dataflow bu işi farklı biçimlerde yürütür. Yönlendirme kurallarını mimari aşamasında açıkça belirlemek, gerçek trafik geldiğinde ortaya çıkacak maliyetli yeniden yazımların önüne geçer.
4. Aşama: Bulutta AI çıkarımı ve analitik. Vertex AI, AWS SageMaker ya da Azure ML Studio gibi bulut AI hizmetleri, edge donanımının kaldıramayacağı iş yüklerini üstlenir: model eğitimi, yeni filo verisiyle yeniden eğitim, çok sayıda cihazda eş zamanlı örüntü tespiti. Veri depolama kararının en kritik hale geldiği yer de burasıdır; InfluxDB, Amazon Timestream ya da TimescaleDB gibi zaman serisi veritabanları, ML sorgu örüntüleri altında işlem yükü için tasarlanmış ilişkisel veritabanından çok daha iyi performans gösterir.
5. Aşama: Uygulama katmanı. Flutter ya da React Native uygulaması, bulut katmanının API'lerinden veri çeker; cihaz durumunu ve AI'ın ürettiği içgörüleri ekrana taşır; komutları cihaza geri iletir. Mobil uygulama her durumu yönetebilmek zorundadır: cihaz bağlı ve gerçek zamanlı, cihaz bağlı ama bulut çevrimdışı, yalnızca geçmiş veri erişilebilir, tamamen çevrimdışı. Her durum, kendine özgü bir arayüz ve veri sözleşmesi gerektirir.
Edge mi, Bulut mu: Çıkarım Kararı
AI-IoT ürününde en belirleyici mimari karar, çıkarımın nerede çalışacağıdır. Bu bir teknoloji tercihi değildir; dört faktör tarafından şekillenir.
Gecikme gereksinimi. AI'ın sensör verisine 200ms içinde yanıt vermesi gerekiyorsa, tek seçenek edge çıkarımıdır. Güvenlik sistemleri, gerçek zamanlı kontrol arayüzleri ve anlık fiziksel sonuçları olan anomali tespiti, varsayılan olarak edge öncelikli mimariye yönelir.
Veri gizliliği. Sensör verisi biyometri, tıbbi okumalar ya da cihazdan çıkmaması gereken kişisel bilgi içeriyorsa, cihaz üzerinde çıkarım tek savunulabilir seçenektir. Federated learning, ham veriyi hiç buluta taşımadan çok sayıda edge cihazı üzerinde model eğitimine olanak tanır; GDPR veya sağlık mevzuatı kapsamındaki ürünler için doğru yapı budur.
Model karmaşıklığı. Mevcut mobil donanım yaklaşık 500 milyon parametre altındaki modelleri işler; daha büyükler bulut altyapısı gerektirir. AI görevi büyük bir akıl yürütme modeli gerektiriyorsa, ön işleme ve filtreleme edge'de kalır, çıkarım buluta taşınır.
Bağlantı güvenilirliği. Aralıklı bağlantının kaçınılmaz olduğu ortamlarda, depolar, inşaat alanları, uzak saha noktaları, kullanıcının çevrimdışıyken de ihtiyaç duyduğu her işlev için edge AI zorunlu hale gelir. Yalnızca bulut çıkarımına dayanan ürün, bağlantı kesildiğinde AI özelliklerini de yitirir.
Bu dört faktörü karşılayan hibrit yapı şöyle kurulur: edge'de hafif ve hızlı modeller gerçek zamanlı kararları üstlenir; veri özetleri ve model performans sinyalleri yeniden eğitim için buluta gönderilir; güncellenmiş ağırlıklar planlı OTA döngüsüyle edge'e geri taşınır. Mobil uygulama, canlı edge sonuçlarını ve buluttan önbellekte tutulan geçmiş eğilimleri yan yana sunar.
Gerçekte Değişen Geliştirme Kararları
Bir ürün AI, IoT ve bulutu ardışık değil birlikte entegre ettiğinde beş karar köklü biçimde değişir.
Veri şeması tasarımı. IoT verisi doğası gereği zaman serisidir. Şemayı ML sorguları için baştan tasarlamak, zaman serisi depolamayı seçmek, saklama politikalarını belirlemek ve ham veri ile toplu özetlerin her katmanda nasıl dağıtılacağına karar vermek demektir. Gerçek cihaz filolarıyla canlı ortama geçmiş bir üründe şemayı sonradan değiştirmek hem pahalıdır hem yıkıcıdır.
Model güncelleme altyapısı. Edge AI modellerinin, firmware güncellemelerinden bağımsız kendi güncelleme mekanizması olması gerekir. Model ağırlıklarını paketleyip imzalayan, dağıtıp gerektiğinde geri alan veri akışı, ilk model canlı ortama girmeden tasarlanmış olmak zorundadır.
Mobil uygulama durum yönetimi. BLE üzerinden cihaza bağlı, edge'den gerçek zamanlı AI çıkarımı çeken ve buluttan geçmiş analitik gösteren bir uygulama, birbirinden farklı güncellik, güvenilirlik ve gecikme profili taşıyan üç ayrı veri kaynağını eş zamanlı yönetir. Her kaynağın bağımsız işlenmesi şarttır. Üçünü tek veri katmanı gibi ele almak, yeniden oluşturulması zor ve kullanıcılara açıklanması daha da güç hatalar doğurur.
Uyarı tasarımı. AI'ın IoT verisinden ürettiği uyarılar, ancak arkalarındaki eşik ve güven tasarımı kadar değerlidir. Çok sık tetiklenen anomali tespit modeli uyarı yorgunluğu yaratır, kullanıcılar bildirimleri kapatır. Eşiği gereğinden yükseğe çeken model ise yakalamak zorunda olduğu olayları gözden kaçırır. Eşik tasarımı ve bildirim UX'i, AI ekibini, ürün ekibini ve donanım ekibini geliştirme başlamadan aynı masaya oturtmayı gerektiren kararlardır.
Maliyet modeli. Ölçekte bulut AI çıkarımı pahalıdır: bulut çıkarımını tetikleyen her sensör okuması, filodaki cihaz sayısıyla çarpılır. Edge öncelikli çıkarımı benimseyip buluta yükseltmeyi yalnızca güven eşiğinin aşıldığı durumlarla sınırlamak, mimari bir tercih değil; çoğu IoT iş modeli için birim ekonomisinin zorunlu kıldığı bir karardır.
Cihaz, mobil ve bulut AI'ını kapsayan ürünler geliştiren ekipler için entegrasyon karmaşıklığı tek bir katmanda değil, katmanlar arasındaki bağlantı noktalarında yaşar. Neon Apps'in mobil uygulama geliştirme pratiği, cihazdan buluta veri akışlarını, TensorFlow Lite ve Core ML kullanan edge AI entegrasyonunu ve üçünü kullanıcılara tutarlı biçimde sunan mobil uygulama mimarisini kapsar.
Sıkça Sorulan Sorular
Bir üründe "AI, IoT ve bulutu entegre etmek" ne anlama gelir?
Neon Apps, bir ürünün üç katmana da ihtiyaç duyduğunda mimariye nasıl yaklaşır?
AI-IoT ürünü için hangi bulut platformu daha uygundur?
Neon Apps, IoT cihaz verisini bulut AI ile birleştiren mobil uygulamalar geliştiriyor mu?
Edge AI ne zaman zorunlu, ne zaman tercih meselesidir?
İlham Almaya Devam Et
Yeni tasarım içgörüleri, makaleler ve kaynaklar doğrudan gelen kutunuza gelsin.
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeleri doğrudan gelen kutunuza alın.
Son Bloglar
İlham Almaya Devam Et
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeler doğrudan gelen kutunuza gelsin.
Bir projeniz mi var?
Bize Ulaşın
Bir projeniz mi var? Startup'lar ve küresel markalar için dünya standartlarında mobil ve web uygulamaları geliştiriyoruz.
Neon Apps, İstanbul ve New York ofislerinde 85 kişilik kendi ekibiyle mobil, web ve SaaS projeleri hayata geçiren bir ürün geliştirme şirketidir. Uzun vadeli bir çözüm ortağı olarak, markalar için ölçeklenebilir dijital ürünler üretiyoruz.
Yazılım Geliştirme
AI, IoT ve Bulutu Birlikte Kullanan Ürün Geliştirmek
AI, IoT ve Bulutu Birlikte Kullanan Ürün Geliştirmek
AI, IoT ve bulutu tek üründe birleştirmek bir trend hikayesi değil, mimari bir problem. Bu yazı veri akışlarını, edge ve bulut çıkarım kararlarını ve üçünü birlikte geliştirirken gerçekte ne değiştiğini anlatıyor.
AI, IoT ve bulutu tek üründe birleştirmek bir trend hikayesi değil, mimari bir problem. Bu yazı veri akışlarını, edge ve bulut çıkarım kararlarını ve üçünü birlikte geliştirirken gerçekte ne değiştiğini anlatıyor.
AI, IoT ve Bulutu Birlikte Kullanan Bir Ürün Geliştirmek: Entegrasyon Gerçekte Böyle Görünür
AI, IoT ve bulut yakınsaması üzerine konuşmalar çoğunlukla makro düzeyde kalır: pazar büyüklükleri, dönüşüm eğrileri, bağlı cihazların geleceği. Yatırım notları için işe yarayan bu çerçeve, gerçekte çalışan bir şey kurmaya çalışan ürün ekibi için bir anlam taşımaz.
Asıl soru daha somuttur. Ürününüzün fiziksel cihazlardan veri toplaması, bu veri üzerinde AI çalıştırması ve sonuçları mobil ya da web uygulaması üzerinden kullanıcılara iletmesi gerekiyorsa, mimari nasıl görünür? Her iş yükü nerede çalışır? Entegrasyon noktaları demoda değil, canlı ortamda nerede bozulur?
Bu bir trend meselesi değil, mimari meseledir. Mimari meselelerin de belirli yanıtları vardır.
"AI Ekleyelim" Neden Neredeyse Her Zaman Tutmaz
Birleşik AI-IoT ürünlerinde en sık rastlanan başarısızlık, AI'ı IoT katmanı kurulduktan sonra eklenecek bir özellik gibi düşünmekten kaynaklanır. Cihaz buluta veri gönderir, bulut saklar; bir noktada "analiz etmek" için AI devreye sokulur.
Bu sıra iki nedenden çalışmaz. Birincisi, veri akışı ML sorguları için değil, depolama için tasarlanmıştır. İlişkisel bir veritabanında biriken zaman serisi verisi, AI bir günlük okumadan fazlasını taraması gerektiğinde performans duvarına çarpar. İkincisi, gecikme hesabı tutmaz. Bir sensörün eşik aşımında uyarı üretmesi, hasar oluşmadan önce anomali yakalaması ya da cihaz davranışını anında düzenlemesi gerekiyorsa, bulut gidiş-dönüş gecikmesi bu bütçeye çoğu zaman sığmaz. Güvenilir bağlantıda bile yüzlerce milisaniyeyi bulan bu gidiş-dönüş, güvenilmez bağlantıda saniyelerle ölçülür.
AI, ilerleyen bir geliştirme döneminde değil ilk tasarım oturumunda mimarinin içinde yer almak zorundadır.
Üç Katman ve Her Birinde Ne Çalışır
AI-IoT-bulut ürününün birbirinden ayrı üç katmanı vardır; her birinin farklı işleme sorumlulukları vardır. Çoğu ekibin yaptığı hata, bu katmanları kod yazmaya başlamadan net biçimde ayırt etmemektir.
İş yükü | 2026'da nerede çalışır | Neden |
Gerçek zamanlı anomali tespiti | Edge / cihaz üzerinde | 100ms altı zorunlu; bulut gidiş-dönüşü çok yavaş |
Hareket veya örüntü sınıflandırması | Edge / mobil ağ geçidi | Gizlilik ve gecikme; bulut bağımlılığı yok |
Model eğitimi ve yeniden eğitimi | Bulut | Toplu veri ve GPU altyapısı gerektirir |
Filo genelinde trend analizi | Bulut | Toplu veri; gecikme hassasiyeti yok |
OTA model güncellemeleri | Bulut başlatır, edge yürütür | Merkezi kontrol, yerel yürütme |
Gizlilik hassasiyeti yüksek çıkarım | Yalnızca edge | Veri ağ sınırını hiç aşmaz |
Çok noktalı toplu raporlama | Bulut | Merkezi, toplu, gerçek zamanlı değil |
2026'daki pratik kural şudur: Kararın 200ms içinde alınması gerekiyorsa çıkarım edge'de çalışır; çok sayıda cihazdan veri ya da geçmiş örüntüler gerekiyorsa bulut devreye girer. Çoğu canlı ortam dağıtımı hibrit bir yapı izler: edge, gecikmeye duyarlı çıkarımı ve yerel kontrolü üstlenirken bulut model eğitimini, filo performans izlemesini ve toplu veriden beslenen karmaşık analitiği yönetir.
Edge AI yonga setleri kritik bir eşiği geride bıraktı. Orta segment akıllı telefonlarda cihaz üzerinde AI çıkarımı, TensorFlow Lite, ONNX Runtime ya da Apple'ın Core ML'i kullanılarak canlı ortam bilgisayarlı görme modellerinde 20ms altına indi. IoT donanımı için TensorFlow Lite Micro ile Qualcomm ve MediaTek'in çerçeveleri, düğme piliyle çalışan cihazlarda anomali tespiti yapmayı gerçek bir seçenek haline getiriyor.
Veri Nereye Akıyor: Gerçek Veri Akışı
AI'ın nerede konumlandığını kavramak, cihazdan kullanıcıya uzanan tam veri akışını anlamayı gerektirir. İyi tasarlanmış bir akış beş aşamadan oluşur; her aşamanın kendi teknoloji kararları vardır.
1. Aşama: Cihazdan bağlantı katmanına. Sensörler veri üretir; protokol seçimi bu verinin bir sonraki katmana nasıl ulaşacağını belirler. Buluta bağlı ürünlerin büyük çoğunluğunda standart yol, AWS IoT Core ya da Azure IoT Hub'a MQTT'dir. Tüketici sağlığı ve fitness ürünlerinde yaygın olan akıllı telefon-ağ geçidi mimarisinde ise akış şöyledir: cihazdan BLE aracılığıyla telefona, oradan REST ya da MQTT üzerinden buluta.
2. Aşama: Edge işleme. Veri buluta ulaşmadan filtrelenebilir, toplanabilir ve analiz edilebilir; edge AI tam burada devreye girer. Cihazda ya da mobil ağ geçidinde çalışan TensorFlow Lite modelleri, buluta gönderilen veri hacmini düşürürken bulut bağımlılığı olmadan anında yerel yanıt üretir. Hareket örüntülerini cihaz üzerinde sınıflandırıp yalnızca özet istatistikler yükleyen fitness giyilebilir cihazı, edge öncelikli tasarımın tipik örneğidir. Bu mimaride mobil uygulama, veriyi olduğu gibi geçiren bir kanal değil; akıllı bir işleme düğümü olarak konumlanır.
3. Aşama: Bulut alımı ve yönlendirme. Bulut IoT hizmetleri, yukarı akıştan gelen veriyi alıp içerik ve cihaz kimliğine göre yönlendirir; depolama, işleme ve uyarı sistemlerine dağıtır. AWS IoT Core'un kurallar motoru, Azure IoT Hub'ın mesaj yönlendirme yapısı ve Google Cloud Pub/Sub ile Dataflow bu işi farklı biçimlerde yürütür. Yönlendirme kurallarını mimari aşamasında açıkça belirlemek, gerçek trafik geldiğinde ortaya çıkacak maliyetli yeniden yazımların önüne geçer.
4. Aşama: Bulutta AI çıkarımı ve analitik. Vertex AI, AWS SageMaker ya da Azure ML Studio gibi bulut AI hizmetleri, edge donanımının kaldıramayacağı iş yüklerini üstlenir: model eğitimi, yeni filo verisiyle yeniden eğitim, çok sayıda cihazda eş zamanlı örüntü tespiti. Veri depolama kararının en kritik hale geldiği yer de burasıdır; InfluxDB, Amazon Timestream ya da TimescaleDB gibi zaman serisi veritabanları, ML sorgu örüntüleri altında işlem yükü için tasarlanmış ilişkisel veritabanından çok daha iyi performans gösterir.
5. Aşama: Uygulama katmanı. Flutter ya da React Native uygulaması, bulut katmanının API'lerinden veri çeker; cihaz durumunu ve AI'ın ürettiği içgörüleri ekrana taşır; komutları cihaza geri iletir. Mobil uygulama her durumu yönetebilmek zorundadır: cihaz bağlı ve gerçek zamanlı, cihaz bağlı ama bulut çevrimdışı, yalnızca geçmiş veri erişilebilir, tamamen çevrimdışı. Her durum, kendine özgü bir arayüz ve veri sözleşmesi gerektirir.
Edge mi, Bulut mu: Çıkarım Kararı
AI-IoT ürününde en belirleyici mimari karar, çıkarımın nerede çalışacağıdır. Bu bir teknoloji tercihi değildir; dört faktör tarafından şekillenir.
Gecikme gereksinimi. AI'ın sensör verisine 200ms içinde yanıt vermesi gerekiyorsa, tek seçenek edge çıkarımıdır. Güvenlik sistemleri, gerçek zamanlı kontrol arayüzleri ve anlık fiziksel sonuçları olan anomali tespiti, varsayılan olarak edge öncelikli mimariye yönelir.
Veri gizliliği. Sensör verisi biyometri, tıbbi okumalar ya da cihazdan çıkmaması gereken kişisel bilgi içeriyorsa, cihaz üzerinde çıkarım tek savunulabilir seçenektir. Federated learning, ham veriyi hiç buluta taşımadan çok sayıda edge cihazı üzerinde model eğitimine olanak tanır; GDPR veya sağlık mevzuatı kapsamındaki ürünler için doğru yapı budur.
Model karmaşıklığı. Mevcut mobil donanım yaklaşık 500 milyon parametre altındaki modelleri işler; daha büyükler bulut altyapısı gerektirir. AI görevi büyük bir akıl yürütme modeli gerektiriyorsa, ön işleme ve filtreleme edge'de kalır, çıkarım buluta taşınır.
Bağlantı güvenilirliği. Aralıklı bağlantının kaçınılmaz olduğu ortamlarda, depolar, inşaat alanları, uzak saha noktaları, kullanıcının çevrimdışıyken de ihtiyaç duyduğu her işlev için edge AI zorunlu hale gelir. Yalnızca bulut çıkarımına dayanan ürün, bağlantı kesildiğinde AI özelliklerini de yitirir.
Bu dört faktörü karşılayan hibrit yapı şöyle kurulur: edge'de hafif ve hızlı modeller gerçek zamanlı kararları üstlenir; veri özetleri ve model performans sinyalleri yeniden eğitim için buluta gönderilir; güncellenmiş ağırlıklar planlı OTA döngüsüyle edge'e geri taşınır. Mobil uygulama, canlı edge sonuçlarını ve buluttan önbellekte tutulan geçmiş eğilimleri yan yana sunar.
Gerçekte Değişen Geliştirme Kararları
Bir ürün AI, IoT ve bulutu ardışık değil birlikte entegre ettiğinde beş karar köklü biçimde değişir.
Veri şeması tasarımı. IoT verisi doğası gereği zaman serisidir. Şemayı ML sorguları için baştan tasarlamak, zaman serisi depolamayı seçmek, saklama politikalarını belirlemek ve ham veri ile toplu özetlerin her katmanda nasıl dağıtılacağına karar vermek demektir. Gerçek cihaz filolarıyla canlı ortama geçmiş bir üründe şemayı sonradan değiştirmek hem pahalıdır hem yıkıcıdır.
Model güncelleme altyapısı. Edge AI modellerinin, firmware güncellemelerinden bağımsız kendi güncelleme mekanizması olması gerekir. Model ağırlıklarını paketleyip imzalayan, dağıtıp gerektiğinde geri alan veri akışı, ilk model canlı ortama girmeden tasarlanmış olmak zorundadır.
Mobil uygulama durum yönetimi. BLE üzerinden cihaza bağlı, edge'den gerçek zamanlı AI çıkarımı çeken ve buluttan geçmiş analitik gösteren bir uygulama, birbirinden farklı güncellik, güvenilirlik ve gecikme profili taşıyan üç ayrı veri kaynağını eş zamanlı yönetir. Her kaynağın bağımsız işlenmesi şarttır. Üçünü tek veri katmanı gibi ele almak, yeniden oluşturulması zor ve kullanıcılara açıklanması daha da güç hatalar doğurur.
Uyarı tasarımı. AI'ın IoT verisinden ürettiği uyarılar, ancak arkalarındaki eşik ve güven tasarımı kadar değerlidir. Çok sık tetiklenen anomali tespit modeli uyarı yorgunluğu yaratır, kullanıcılar bildirimleri kapatır. Eşiği gereğinden yükseğe çeken model ise yakalamak zorunda olduğu olayları gözden kaçırır. Eşik tasarımı ve bildirim UX'i, AI ekibini, ürün ekibini ve donanım ekibini geliştirme başlamadan aynı masaya oturtmayı gerektiren kararlardır.
Maliyet modeli. Ölçekte bulut AI çıkarımı pahalıdır: bulut çıkarımını tetikleyen her sensör okuması, filodaki cihaz sayısıyla çarpılır. Edge öncelikli çıkarımı benimseyip buluta yükseltmeyi yalnızca güven eşiğinin aşıldığı durumlarla sınırlamak, mimari bir tercih değil; çoğu IoT iş modeli için birim ekonomisinin zorunlu kıldığı bir karardır.
Cihaz, mobil ve bulut AI'ını kapsayan ürünler geliştiren ekipler için entegrasyon karmaşıklığı tek bir katmanda değil, katmanlar arasındaki bağlantı noktalarında yaşar. Neon Apps'in mobil uygulama geliştirme pratiği, cihazdan buluta veri akışlarını, TensorFlow Lite ve Core ML kullanan edge AI entegrasyonunu ve üçünü kullanıcılara tutarlı biçimde sunan mobil uygulama mimarisini kapsar.
Sıkça Sorulan Sorular
Bir üründe "AI, IoT ve bulutu entegre etmek" ne anlama gelir?
Neon Apps, bir ürünün üç katmana da ihtiyaç duyduğunda mimariye nasıl yaklaşır?
AI-IoT ürünü için hangi bulut platformu daha uygundur?
Neon Apps, IoT cihaz verisini bulut AI ile birleştiren mobil uygulamalar geliştiriyor mu?
Edge AI ne zaman zorunlu, ne zaman tercih meselesidir?
İlham Almaya Devam Et
Yeni tasarım içgörüleri, makaleler ve kaynaklar doğrudan gelen kutunuza gelsin.
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeleri doğrudan gelen kutunuza alın.
Son Bloglar
İlham Almaya Devam Et
Neon Apps ekibinden hikayeler, içgörüler ve güncellemeler doğrudan gelen kutunuza gelsin.
Bir projeniz mi var?
Bize Ulaşın
Bir projeniz mi var? Startup'lar ve küresel markalar için dünya standartlarında mobil ve web uygulamaları geliştiriyoruz.
Neon Apps, İstanbul ve New York ofislerinde 85 kişilik kendi ekibiyle mobil, web ve SaaS projeleri hayata geçiren bir ürün geliştirme şirketidir. Uzun vadeli bir çözüm ortağı olarak, markalar için ölçeklenebilir dijital ürünler üretiyoruz.