IoT platformu vs MQTT broker sorusu pek çok ekibin kafasını karıştırır; çünkü ikisi birbiriyle örtüşür ve sağlayıcılar bu terimleri gevşek biçimde kullanır. Bu yazı katmanları net şekilde ayırıyor, tam bir IoT platformunun broker'ın üzerine neler eklediğini açıklıyor ve bir platforma mı ihtiyacınız olduğuna, yoksa yalın bir yönetilen broker ile birkaç açık aracın projenizi karşılayıp karşılamadığına karar vermeniz için pratik bir yol sunuyor.
İki Farklı Katman
Bir MQTT broker bir mesaj yönlendiricisidir. İstemciler bağlanır, topic'lere mesaj yayınlar ve topic'lere abone olur; broker her mesajı istenen QoS ile eşleşen tüm abonelere iletir. Oturumları, retained message'ları, will mesajlarını ve MQTT 5 ile birlikte paylaşımlı abonelikler ve mesaj süresi dolumu gibi özellikleri yönetir. Bilgilerinizi tazelemek isterseniz bir MQTT broker'ın ne yaptığını okuyun.
Bir IoT platformu ise bir mesajlaşma çekirdeği etrafında kurulmuş hizmetler paketidir. Ürüne bağlı olarak şunların bir kısmını veya tamamını ekler:
- Cihaz kaydı, provizyonlama ve kimlik yönetimi.
- Shadow veya twin gibi cihaz durumu hizmetleri.
- Kablosuz (OTA) firmware güncelleme orkestrasyonu.
- Verileri filtreleyen, dönüştüren ve yönlendiren kural motorları.
- Zaman serisi depolama ve geçmiş sorguları.
- Panolar, alarmlar ve bildirimler.
- Kullanıcı yönetimi, kendi müşterileriniz için çok kiracılı yapı ve uygulama API'leri.
Pek çok platform bir MQTT uç noktası içerir; bu bazen tam bir broker, bazen de sabit topic'lere sahip bir cihazdan buluta ağ geçididir. Platformun değeri, tüm bu parçaların entegrasyonundadır.
IoT Platformu ve MQTT Broker Karşılaştırması
| Yetenek | Yalnızca MQTT broker | Tam IoT platformu | Yalın broker artı açık araçlar |
|---|---|---|---|
| Gerçek zamanlı pub/sub | Evet | Genellikle, bazen yalnızca cihazdan buluta | Evet |
| Cihaz kimliği | İstemci başına kimlik bilgileri | Yaşam döngülü kayıt | Kimlik bilgileri artı kendi envanteriniz |
| Cihaz durumu | Retained message'lar | Shadow veya twin hizmeti | Retained durum topic'leri |
| Veri işleme | Hayır | Yerleşik kurallar | Node-RED, küçük servisler |
| Depolama ve geçmiş | Hayır | Yerleşik | InfluxDB, TimescaleDB, PostgreSQL |
| Panolar | Yalnızca broker konsolu | Yerleşik | Grafana, Node-RED Dashboard |
| Uyarılar | Broker'a bağlı | Yerleşik | Broker uyarıları veya Grafana alerting |
| Firmware güncellemeleri | Hayır | Çoğunlukla yerleşik | Ayrı OTA araçları |
| Taşınabilirlik | Yüksek | Çoğunlukla daha düşük | Yüksek |
| Başlama eforu | Düşük | Düşük ile orta | Orta |
Ortadaki sütun pratik ama belirli bir yaklaşımı dayatır. Sağdaki sütun biraz daha montaj gerektirir, ancak her parçayı değiştirilebilir bırakır.
Tam Bir IoT Platformu Ne Zaman Doğru Seçimdir?
Bir platform maliyetini ve kısıtlarını şu durumlarda hak eder:
- Büyük ölçekli cihaz yaşam döngüsü yönetimine ihtiyacınız varsa; örneğin pek çok cihaz türünde toplu provizyonlama, sertifika rotasyonu ve kademeli OTA güncellemeleri.
- Bileşenleri entegre edecek ekibiniz yoksa ve tüm yığından tek bir sağlayıcının sorumlu olmasını istiyorsanız.
- Arka ucunuz zaten o platformun bulutunda yaşıyorsa ve verilerin oraya minimum yapıştırıcı kodla ulaşmasını istiyorsanız.
- Çok müşterili bir ürün geliştiriyorsanız ve platformun kiracı, kullanıcı ve API modeli sizinkiyle örtüşüyorsa.
Bu durumlarda platformu bilinçli olarak seçin ve cihaz firmware'ini mümkün olduğunca taşınabilir tutmak için MQTT sağlayıcı bağımlılığı yazısını okuyun.
Yalın Bir Broker Ne Zaman Yeterlidir?
Yönetilen bir broker artı birkaç açık araç, çoğu zaman şu durumlarda daha iyi bir seçimdir:
- Temel ihtiyacınız canlı veri aktarımıysa; makineler, ağ geçitleri, uygulamalar ve panolar arasında.
- Node-RED, Grafana, Telegraf veya bir zaman serisi veritabanı gibi araçları zaten kullanıyorsanız.
- Bir Unified Namespace kuruyorsanız ve topic hiyerarşisine tamamen sahip olmak istiyorsanız.
- Bulutlar ve şirket içi sistemler arasında taşınabilirliğe değer veriyorsanız.
- Cihaz filonuz mütevazıysa ve cihaz yönetimi basit bir envanterde tutulabiliyorsa.
ConnectMQ bu desen için tasarlanmıştır. MQTT 3.1.1 ve 5.0, TLS ve Secure WebSocket destekli tam yönetilen bir MQTT hizmetidir ve bir platforma dönüşmeden birkaç "platform benzeri" temel özelliği kapsayan bir portal sunar: tarayıcı içi MQTT client, canlı topic gezgini, pano, ISA-95 seviyelerine göre cihaz görünümü, uyarı kaydıyla birlikte eşik tabanlı uyarı kuralları, Sparkplug B çözümleme ve ISA-95 topic'lerine yeniden yayınlama. Bilinçli olarak kural motoru, webhook veya veritabanı köprüleri içermez; bu işler harici araçlara bırakılır.
Yalın Bir Referans Mimari
Yönetilen bir broker etrafında yaygın, tamamen açık bir yığın şöyle görünür:
Devices / PLC gateways --MQTT/TLS--> Managed MQTT broker (ConnectMQ)
|
+-------------------------------+-----------------------------+
| | |
Telegraf (mqtt_consumer) Node-RED flows Browser apps (WSS 8084)
| (logic, alerts, APIs)
InfluxDB (time series)
|
Grafana (dashboards, alerting)
Her bileşen broker'a sıradan bir MQTT client olarak bağlanır. Cihazlara dokunmadan bunlardan herhangi birini değiştirebilirsiniz.
Örnek: Telegraf ile Telemetri Depolama
Telegraf'ın MQTT consumer girişi, yalnızca yapılandırma ile broker'ınıza abone olup InfluxDB'ye yazabilir:
# telegraf.conf
[[inputs.mqtt_consumer]]
servers = ["ssl://broker.connectmq.com:8883"]
topics = ["acme/plant1/+/+/telemetry"]
qos = 1
client_id = "YOUR_CLIENT_ID"
username = "YOUR_USERNAME"
password = "YOUR_PASSWORD"
data_format = "json"
topic_tag = "topic"
[[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
token = "${INFLUX_TOKEN}"
organization = "acme"
bucket = "telemetry"
Başlatın ve noktaların geldiğini kontrol edin:
export INFLUX_TOKEN=your-influx-token
telegraf --config telegraf.conf --test # tek seferlik ayrıştırma kontrolü
telegraf --config telegraf.conf # sürekli çalıştır
{"temp": 72.4, "rpm": 1450} gibi JSON payload'larda sayısal alanlar InfluxDB alanlarına dönüşür, topic ise Grafana'da filtreleyebileceğiniz bir etiket olur. Her eşzamanlı bağlantının kendi kimlik bilgilerine ve client ID'sine ihtiyaç duyduğunu unutmayın; ConnectMQ'da client ID'ler verilen kimlik bilgilerine bağlıdır.
İki Tarafın da Gizli Maliyetleri
Hiçbir yol ödünleşimsiz değildir ve karar vermeden önce bunları adlandırmak işe yarar.
Tam bir platformda gizli maliyetler genellikle kavramsal ve sözleşmeseldir. Ekibiniz platformun cihaz, kural ve durum modelini öğrenir ve bu bilgi başka bir yere aktarılmaz. Fiyatlandırma çoğu zaman bağlantılar, mesajlar, kural çalıştırmaları ve depolama gibi birkaç boyutta aynı anda büyür; bu da tahmini zorlaştırır. Kullanmadığınız özellikler bile kullandıklarınızı nasıl tasarladığınızı şekillendirir.
Yalın broker artı araçlar yaklaşımında gizli maliyetler operasyoneldir. Birinin Node-RED'i, zaman serisi veritabanını ve Grafana'yı çalıştırması, güncel tutması ve yedeklemesi gerekir. Topic adlandırma ve payload formatları gibi entegrasyon kararlarını belgelemek ve uygulatmak size kalır. Küçük bir ekip için bu yönetilebilirdir; platform ekibi olmayan büyük bir kuruluş için ise dağınık bir hâl alabilir.
Pratik test, önümüzdeki iki yılın taslağını çizmektir: kaç cihaz, hangi veri hedefleri ve her parçanın bakımını kim yapacak. Bakım yükü ekibinize uyan seçenek genellikle doğru olandır.
Karar Kontrol Listesi
Her soruyu evet veya hayır ile yanıtlayın:
- Büyük bir filo genelinde tek bir konsoldan OTA firmware orkestrasyonuna ihtiyacınız var mı?
- Bir kimlik bilgileri listesinin ötesinde, yaşam döngüsü durumlarına sahip bir cihaz kaydına ihtiyacınız var mı?
- Verilerin otomatik olarak belirli bir bulutun hizmetlerine ulaşması şart mı?
- Node-RED, Grafana veya küçük bir servisi çalıştırmakta rahat olan kimse yok mu?
- Kendi müşterileriniz için hazır, çok kiracılı bir uygulama katmanına ihtiyacınız var mı?
Çoğunlukla evet: tam IoT platformlarını değerlendirin. Çoğunlukla hayır: yalın bir yönetilen broker ile başlayın ve ihtiyaçlar ortaya çıktıkça araç ekleyin. Pek çok ekip ikisini birleştirir de; broker'ı tarafsız gerçek zamanlı omurga olarak, platformu ise OTA güncellemeleri gibi belirli bir iş için kullanır.
Daha derin karşılaştırmalar için, iki tanınmış platformu bu bakış açısıyla inceleyen AWS IoT Core alternatifi ve Azure IoT Hub alternatifi yazılarına bakın.
Yalın Bir Yönetilen Broker ile Başlayın
Yalın yaklaşımı bir öğleden sonrada doğrulayabilirsiniz. Kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun, bir cihaz bağlayın ve Telegraf'ı veya Node-RED'i ona yönlendirin. Bulut MQTT broker rehberi projeniz büyüdükçe dağıtım seçeneklerini açıklar; connectmq.com ise Serverless'tan Dedicated, BYOC ve Self Managed Enterprise'a kadar tüm planlara genel bakışı sunar.
Sık Sorulan Sorular
MQTT broker bir IoT platformu mudur?
Hayır. Broker, mesajları istemciler arasında yönlendirir. IoT platformu ise bir mesajlaşma katmanını cihaz yönetimi, depolama, kurallar ve panolarla bir araya getirir.
Yalnızca bir MQTT broker ile IoT çözümü kurabilir miyim?
Evet, birkaç harici araçla. Bir broker artı Node-RED, bir zaman serisi veritabanı ve Grafana, pek çok izleme ve kontrol projesini karşılar.
ConnectMQ bir kural motoru veya veritabanı entegrasyonları içeriyor mu?
Hayır. Entegrasyonlar Node-RED, Telegraf veya kendi servisleriniz gibi harici MQTT client'lar olarak çalışır; bu da onları taşınabilir tutar.
Bir IoT platformunu ve ayrı bir MQTT broker'ı birlikte kullanabilir miyim?
Evet. Pek çok ekip tarafsız bir broker'ı gerçek zamanlı omurga olarak, bir platformu ise firmware güncellemeleri veya cihaz provizyonlama gibi belirli işler için kullanır.
