We also had a look at Artik, Samsung, etc. They did not appear to be a correct fit for our solution. This post will mention what parametersand thought process bywhich wechose the Platform for our solution. This study was done in the second week of August 2016. So, by the time you read this, there could be some changes in terms of capabilities of these platforms.
Opinions expressed by DZone contributors are their own.
At an overall solution level, we needed a platform that could provide easy-to-develop and implement solutions right from regular REST service, deep analytical…,authors:[realName:Hariharan Anantharaman,isMVB:false,isStaff:false,aboutAuthor:null,claimed:null,name:harianantha2,tagline:null,company:OnRue Technology Solutions Pvt Ltd,id:2886641,avatar:3231354,isClaimed:false,url:/users/2886641/harianantha2.html]]; TH.installWidgetController(article.content, articleContent5, WMODEL_DATA, typeof controller == function ? controller : null, [name: partners, data: true,name: DEFAULT, data: true], oUhbblYOaqbcblYOaqbcC, null); )(); (function() function controller($scope, $service, $location, SideBarService, $timeout) if ($scope.edition) $scope.date = moment($scope.editionDate).utc().format(MMM DD, YYYY); SideBarService.ctx.pageSize = $scope.pageSize; SideBarService.ctx.isPreview = $scope.isPreview; SideBarService.ctx.mode = $scope.mode; SideBarService.fn.loader = $service; var $window = $(window); function checkWidth() var windowsize = $window.width(); $scope.width = windowsize; // Execute on load checkWidth() // Bind event listener $(window).resize(checkWidth); if ($scope.edition) SideBarService.ctx.edition = $scope.edition; SideBarService.fn.scrollCheck = function() $scope.$emit(thIfScrollCheck); ; var currentFilter; $scope.$on($locationChangeSuccess, function() if (!$location.search().filter) $scope.filter = latest; else $scope.filter = $location.search().filter; if ($scope.filter == latest) $location.search(filter, null); if (currentFilter == $scope.filter) return; currentFilter = $scope.filter; SideBarService.ctx.filter = $scope.filter; ); $scope.display = SideBarService.getList(); $scope.$watchCollection(function() return SideBarService.getList(); , function (n) $scope.display = n; ); $scope.isActive = SideBarService.isActive; $scope.isExcluded = SideBarService.isExcluded; $scope.loadMore = SideBarService.load; $scope.loading = function() return SideBarService.ctx.loading; ; TH.on(TapBarStatusChange, function(expanded) if (expanded) SideBarService.unblock(); ) var WMODEL_DATA = ; WMODEL_DATA.mode = null; WMODEL_DATA.isPreview = false; WMODEL_DATA.editionName = ; WMODEL_DATA.editionDate = null; WMODEL_DATA.pageSize = 20; WMODEL_DATA.edition = null; WMODEL_DATA.OPTIONS = ; TH.installWidgetController(sidebar.content.list, sidebarContentList8, WMODEL_DATA, typeof controller == function ? controller : null, [name: DEFAULT, data: true], oUhbkSMaaqbcdvVkcC, null); )(); (function() function controller($scope) var $window = $(window); function checkWidth() var windowsize = $window.width(); var $element = $(div.sidebar.sidebarTapBar); $scope.width = windowsize; if(windowsize
Google Reference Architecture (Reference:
Looking at all aspects, we have chosen Azure as our IoT platform.
1 && !articles[0].partner.isSponsoringArticle dc-slot=ads.sb2.slot(articles[0], 0) tags=ads.sb2.tags(articles[0], 0) size=ads.sb2.size(articles[0], 0)
parent.isLocked ? Enable : Disable comments
parent.isLimited ? Remove comment limits : Enable moderated comments
Apart from IoT messaging, we also have few use cases which are strictly not IoT-specific (e.g user signup, etc). We were looking for functions (serverless computing) to perform this, and all the players supported it. We were also looking for a NoSQL DB, and all the players provided that as well. Regardingcapabilities in Analytics and Machine learning (and using popular things like R,Spark etc), Azure and AWS appeared to be better than Google (to give the benefit of a doubt to Google, we did not do experiments in the Google Cloud Platform to confirm this. Since Google lagged behind in the other key aspects explained earlier, we did not want to spend more time in experimenting with Google).
Published at DZone with permission ofHariharan Anantharaman .See the original article here.
AtOnRue Technology Solutions, we were developingDataWheels,an IoT solution targeting personal and public transport. The first key decision we made was deciding which IoT platform to use. While there were lot of options available in market, we short-listed the following platforms:
parent.title parent.header.title
Join the DZone community and get the full member experience.
; e.id = parsely-root; e.style.display = none; b.appendChild(e); )(document); (function(s, p, d) var h=d.location.protocol, i=p+-+s, e=d.getElementById(i), r=d.getElementById(p+-root), ; if (e) return; e = d.createElement(s); e.id = i; e.async = true; e.src= h+//+u+/p.js; r.appendChild(e); )(script, parsely, document);
IoT Platform Selection: Azure vs. AWS vs. GCP
We also had a look at Artik, Samsung, etc. They did not appear to be a correct fit for our solution. This post will mention what parametersand thought process bywhich wechose the Platform for our solution. This study was done in the second week of August 2016. So, by the time you read this, there could be some changes in terms of capabilities of these platforms.
Azure also gives a provision where the gateway can be your own data center as well. Only Azure and Google gave streams or pipelines that will help in easy integration (AWS introduced it in September, once we already chose the platform). In Google, the only recommended way of connecting was pub/sub, while in Azure and AWS, it is not so restrictive and provided better options. Lookingoverall,Azureemerged as a winner in this section with AWS falling shortly behind. Though not required for us, I noticed that only Azure and AWS provided cloud-to-device messaging as well.
See how one team compared the Big Three of IoT Platforms. From architecture maturity to pricing to full stack support, see which one came out on top.
AWS Reference Architecture (Reference:
AtOnRue Technology Solutions, we were developingDataWheels,an IoT solution targeting personal and public transport. The first key decision we made was deciding which IoT platform to use. While there were lot of options available in market, we short-listed the following platforms:
Because oursolution will be used by end consumers, they should have the ability to activateor deactivatetheir devices. Our IoT platform should also enable device-level authentication and security. Only Azure and AWS provided device-level authentication and activation capabilities. It also meant that we needed to develop that component if we were going with Google.The non-availability of pipelines in AWS meant that storing incoming data meant more development effort on our part.
In our product, we will predominantly be using MQTT, whereas HTTP will be used on a few use cases. Azure and AWS provided SDKs in all popular programming languages for both device management, IoT messaging (using MQTT). For HTTP, existing APIs and languages proved sufficient. Google provided SDK support in all languages, but only for the gRPC protocol. So in this criterion as well, AWS and Azure were equal.
by parent.authors[0].realName parent.author
parent.articleDate date:MMM. dd, yyyy parent.linkDate date:MMM. dd, yyyy
By the nature of devices and IoT, supportprotocols other than HTTP was a key requirement. In these terms, AWS and Azure supported all the protocols used frequently in IoT like MQTT andAMQPS along with HTTP. Google supported only HTTP 2 and gRPC.Since we decided to go with theindustry standard of MQTT, we did not conduct any tests to validate pros and cons between MQTT, AMQPS, and gRPC to measure their performance (absolutely due to lack of time). Both AWS and Azure were equal in this respect.
For our solution, we needed to look at pricing for different areas like database, runtime cost of functions, stream analytics, etc. We also need to look at pricing for different volumes of data and rate of data ingestion (which are dependent on thenumber of devices). While coming to theprice of NoSQL DB, we realized that the price of Google is significantly higher. So Google was ruled out. When coming to consuming messages, AWS and Azure price based on thenumber of messages. But the catch is thesize of the message. In AWS, 1 KB is the size of the message, and in Azure it is 4KB. For example, if you send a message with 8KB, in AWS it will be treated as eight messages, and in Azure, it will be two messages. So when you are arriving at pricing, this needs to be kept in mind when choosing the corresponding plan. In our case, we did the math based on our message size, thenumber of users in thenear-term and medium-term, and thenumber of messagesin Azure worked out to be roughly 50% cheaper than AWS.
At an overall solution level, we needed a platform that could provide easy-to-develop and implement solutions right from regular REST service, deep analytical capabilities, messagingqueues, and IoT-specific features. In this context, Google lagged behind AWS and Azure. While Google is excellent in terms of hosting generic applications and analytics, we need to do a lot of plumbing in order to stitch everything together to suit our needs. The following reference architecture diagrams were taken from respective sites. While we could improve upon each of them,a better starting point meansless effort for the team.
1024 && edition) class=content-right-images ntent
IoT Platform Selection: Azure vs. AWS vs. GCP
= partners.length !toUse) toUse = 0; if(partners) article.showLogo = (partners.length