Konu hakkında irdelemek istediğim birkaç husus var;
Cihaz Sadece verimi gönderecek?
Eğer cihaz sadece veri gönderecekse, senaryonuz da sıkıntı yok; Sabit bir endpointiniz olur(iot-api.domain.com) ve cihaz kendi id'si ile birlikte verileri gönderir ve o id'li cihaz kime tanımlanmışsa verileri onun panelinde kullanabilirsiniz. Ama sizde cihaza bir şeyler gönderecekseniz bu senaryoya socket mantığıyla çalışan real time Iot çözümlerini de dahil etmeniz gerekir.
En basit mantıkla bir örnek vereyim. Cihaz bir ışık yakacak diyelim; cihazın gönderdiğiniz komutu anında işleme alması için real time çalışan bir teknolojiye ihtiyacı vardır. Bu iş daha farklı yollarla da çözülebilir ama çok daha ilkel ve maliyetli olur.
Yada ters bir mantık ile cihaza parametre göndereceksiniz; Sıcaklık sensörünün ölçtüğü değer 25 derece sıcaklığa ulaştığında bana(apiye) sıcaklık bilgisini gönder diyeceksiniz. Bu senaryoda da parametreler sabit bir endpoint üzerinden id ile çekilebilir ama buda daha maliyetli ve ilkel bir yol olur.
Sonuç olarak, Sizin uygulamanızda böyle bir ihtiyaç olmayabilir ama Iot teknolojilerin optimum şekilde kullanılabilmesi için socket mantığı ile çalışan real time çözümlere ihtiyacı oluyor diyebiliriz. Bakınız: AWS IoT Uygulamaları ve Çözümleri
Alt yapı seçimi
Sistemin serverless bir mimaride barınması geliştiriciler ve proje sahipleri için çok güzel bir gelişme. Sizde çok haklı olarak serverless olsun bir daha donanım/sunucu derdim olmasın diyorsunuz. Ama maalesef serverless konusunda maliyet hesabının yapılması, optimize edilmesi ve Laravel gibi komplex yapıların hızlıca serverless üzerinde çalıştırılması noktasında katedilmesi gereken mesafeler var. Web uygulamanız Laravel ile hazırlanabilir ama Laravel'in Aws Lambda ile çalışır hale gelmesi biraz çetrefilli bir konudur. Aws Lambda'nın desteklediği diller içerisinde maalesef henüz PHP bulunmuyor. Lambda üzerinde PHP çalıştırılabilir(Custom Runtime) ama onun yerine NodeJS veya Python gibi popüler dillerin tercih edilmesi bu servisi kullanırken şimdilik daha fiyat/performans olabilir.
Laravel'in Lambda ile çalışması neden çetrefilli? Serverless mimaride barınacak uygulamaların ya mikro servis olarak çalışması yada mikro servismiş gibi çalışması gerekmektedir. Özetle; Laravel uygulamaları monolit yapıda olduğundan, mikro servis gibi çalıştırılmaları gerekmektedir. Ayrıca bu mikro servismiş gibi olan Laravel endpointlerinin AWS Service Endpoint üzerinden ulaşılabilir hale getirilmeleri gereklidir.
Ama bu konuda güzel haberlerde yok değil; Laravel'in geliştiricisi(Taylor Otwell) Vapor adında bir SAAS uygulaması geliştiriyor. Bu uygulama ile AWS üzerinde serverless Laravel çalıştırılabilecek/miş. Bu Saas'ı kiraladığınızda, Laravel'in serverless olarak yayınlanması işini sizin için Vapor halledecek. Deployment haricinde DNS(Route53), CDN(CloudFront), Database, Caching(ElastiCache), Queue, Storage(S3) vb. konularını da AWS teknolojileri ile çözecekmiş. Bakınız: Laravel Vapor, Laravel Vapor ve AWS Lambda, Laravel Vapor Fiyat/Performans Optimizasyonu
Ayrıca işin birde database tarafı var. Ama neyse ki bu konuda da artık AWS'nin serverless database servisi bulunmakta. Bakınız: Aurora Serverless
Sonuç olarak, şimdilik serverless üzerinde php çalıştırmak yerine, en azından vapor tarzı hızlandırıcı sistemler gelene kadar, AWS Elastic Beanstalk üzerinde, serverless database(Aurora Serverless) ile entegre çalışan otomatik ölçeklendirilebilir bir sunucu altyapısı daha fiyat/performans olabilir. Laravel Vapor çıktığında onunla devam edilebilir.
Konum ile alakalı benzer işlemler yapacak bir proje için analiz aşamasındayız. Bizim projemizde Iot cihaz yerine mobil uygulama kullanılacak. Çünkü konum dışında harici çok fazla veriye ihtiyacımız yok. İnteraktif olması önemli; o yüzden sim kartlı tabletler ile konum bilgilerini alarak kullanmayı planlıyoruz. Konu araçlarla alakalı ama bizimkide araç takip sistemi değil. 🙂 Projenizde başarılar dilerim.