Imagine following scenario:
We build an IoT solution and use Azure Service Fabric to implement the complete backend.
Messages from devices flow through the IoT Hub to the Device Actor which processes those messages.
We also have a web API as a stateless service through which people can put some data (using an SPA) in a database.
Now the Device Actor needs this data to make some decisions.
In terms of Microservices architecture Device Actor could use that stateless service to retrieve the data (avoiding integration through the database). But if we consider that the Device Actor scales to many thousands devices that stateless service would be the bottleneck unless we scale it too (only because of devices).
So my question is: what is the best approach here?
Related
I am not understanding when Azure IoT Hub can be preferred over Azure IoT Central. From the readings done so far, IoT central seems better over all the aspects.
Anybody can explain me where are the situations where IoT hub is better than IoT Central?
Thanks
There is no definitive answer to that question, neither are "better", but most of the times one will fit your use case more than the other.
If you want a complete, managed way of connecting devices to the cloud and create dashboards (within the product's limits), a Software as a Service solution like Azure IoT Central can be a match. Think about the requirements of the project you're looking to do, and if it's all supported by IoT Central, go for it! If there are some features you can build by leveraging data export from IoT Central, it might still be a great fit.
If you want to build bi-directional communication and device registration for IoT devices into your own cloud platform, IoT Hub comes into play. Maybe you need better control of the data, or maybe the data insights you need aren't supported by IoT Central. There are a lot of cases where it might not be the best choice. IoT Hub gives you a lot more flexibility that you can use to create almost any IoT scenario.
Both are not directly comparable, there are specific advantages of IoT Central which you may need to consider.
IoT Hub is a PaaS service which can be used with other services to create an IoT solution while IoT Central is IoT Application platform which can be used as-is or extended via companion application. Even addressing basic functionality in IoT Central you will need over dozen other services and you own responsibility to design, manage and administer the orchestration yourself.
IoT Central internally uses multiple IoT Hubs (HA/DR) and bunch of services to bring the functionality that you see in the application. This includes App Service to host the UX, Rules Engine, Fast Storage, API layer, Data Export, RBAC, in-app Multi-tenancy , etc. etc. The key advantages you get -
Full featured IoT solution with high availability, security, scalability that is available in < 10 secs under 99.9% SLA
Simplification, easy to connect any device or simulate basic capabilities using the built-in plug-n-play support. Just select any device from the pnp catalog and try it out even before purchasing the devices.
Create user or app level dashboards with device specific views. Device specific view can be auto-generated with PnP devices.
Rule creation, alerting and integration with other applications via Logic Apps, Functions
Data Export functionality to Event Hub, Service Bus, Blob Storage or Web hooks
Rich Job's interface allowing updating device configurations or firmware
RBAC in combination with Organizations allow giving specific permissions to user.
The big advantage is all this is available with a very simpler per device per month pricing that starts as low as 8 cents per device per month ($2 a year) + additional messages https://azure.microsoft.com/en-us/pricing/details/iot-central/
In general unless you already have UX, Storage, Rules engine, etc. elements required for IoT Solution and need to add IoT Hub to ingest and manage IoT devices it will make more sense to start with IoT Central and build with it. It will save time, efforts and you can focus on specific differentiation than build the underlying plumbing and owning the management and sustenance. It is difficult to come to that price point given the high cost of cloud engineers required to support and maintain it.
It is recommended that all customers begin their IoT journey with our aPaaS offering Azure IoT Central. IoT Central is a ready-made environment for IoT solution development. As an aPaaS offering it is built to simplify and accelerate IoT solution assembly and operations, by preassembling PaaS services from the IoT Platform (including IoT Hub and the IoT Hub Device Provisioning Service) and across Azure. A customer that starts with IoT Central builds valuable expertise regardless of whether they go to production with IoT Central, or later build a custom solution to meet complex business needs using PaaS services. To learn more about onboarding to Azure IoT check out this documentation: https://aka.ms/azureiotarch and stay tuned for a session at Microsoft Ignite Nov3-4th Entitled Onboarding to Azure IoT
We produce an enterprise DLT (Blockchain) application for big banks, FMIs, exchanges etc..
Being distributed each instance of the application is installed on-prem for each customer, as they must remain the sovereign owner of their private keys.
We want to integrate with a SaaS application that is widely used in the banking sector. We intend to achieve this by writing a "connector" which will also run on-prem and be able to communicate and marshal data between the SaaS system and our on-prem system.
Events occur in the SaaS app, which must then trigger something to happen in our on-prem app.
The SaaS app has a RESTful API as well as webhooks. So there are 2 options in my eyes:
Poll the RESTful API
Con: This is inefficient as most traffic will simply be "any new events?" "no"
Con: There will be some latency between the event occurring on the SaaS system and our on-prem app being triggered
Pro: This is stable. If the connector (the thing doing the polling) goes down, it will pick up any missed "events" from the SaaS system when it comes back up and process them
Pro: There is no requirement to allow internet traffic into the firewall - the comms are all outbound.
Use the webhooks
Pro: Very efficient
Pro: Get events in near real-time
Con: What happens if the connector is down and we miss a webhook? Does the SaaS system need a retry mechanism? We need to ensure that we only process messages exactly once. (this is important because the action we perform moves large amounts of funds so double processing would be extremely bad!)
Con: The bank would need to punch a hole in the firewall to allow the SaaS app to communicate into the connector - the bank's security teams won't like this IMO.
Is there a common, enterprise ready, security policy friendly way to do deal with this?
I think here you can use RESTful API with an enterprise ready-solution for API management. I would recommend that you explore APIGEE and see if it fits your usecase.
APIGEE is a platform for developing and managing API proxies.
An API proxy is an interface to developers that want to use backend services. Rather than having them consume those services directly, they access an Edge API proxy that you create. You can have it on cloud and also on-premises.
Here, you will solve your two main issues which are events management and latency.
I am looking for a way to integrate the IOT with Blockchain. I need to record the device data (IOT device) into the blockchain. I am successfully able to send data from the device to the IOT Hub.How can I record this data in a block chain created using Azure Ethereum Consortium?
Blockchain and IoT are a marriage made in heaven. Blockchain can enable and augment a variety of application scenarios and usecases for the IoT. No longer are such possibilities too futuristic – as we will discuss in this post.
IoT Meets Blockchain...
Blockchain and Internet Of Things (IoT) are easily the two biggest buzzwords in technology at the moment. The IoT encompasses the world of sensors,moving objects like vehicles and really any device that has embedded electronics to communicate with the outside world – typically over an IP protocol.
Combine that with Blockchain – a distributed ledger architecture (DLT) pattern. Combining the two can facilitate the entire lifecycle of IoT devices and applications and prove to be the glue for business processes to act on these events. Consider the following scenario – a private blockchain for a driverless connected car that will enable secure and realtime interactions from the car starting with car startup, driver authentication, smart contracts to exchange insurance and maintenance service information and realtime location info to track safety.
You can learn more about IBM BlockChain and develop your own BlockChain # https://www.ibm.com/developerworks/cloud/library/cl-ibm-blockchain-101-quick-start-guide-for-developers-bluemix-trs/index.html
Service Fabric was just announced at the build conference. I was reading the scarce documentation about it and I have a question.
I'm evaluating Service Fabric for hosting CRUD like microservices that are at the moment built in ASP.NET WebApi.
Is Service Fabric geared towards hosting small pieces of functionality that receive data, process it and return the result, rather than hosting CRUD WebApi types of application?
Service Fabric enables the creation of both stateless and stateful microservices.
As the name suggests, any state maintained by an an instance of a stateless service will be lost if the node goes down. A new, fresh instance will simply be spun up elsewhere in the cluster.
Stateful services offer the ability to persist state without relying on an external store. Any data stored in a Reliable Collection will be automatically replicated across multiple nodes in the cluster, ensuring that the state is resilient to failures.
A common pattern is to use a stateless service as the client-facing gateway to the application and then have that service direct traffic to the app's partitioned stateful services. This hides the work of resolving partitions from clients, allowing them to to target one logical endpoint with all requests.
Take a look at the WordCount sample for an example of how this works. The WordCount.WebService stateless service acts as the front end to the application. It simply resolves the partition based on the incoming request and then sends it on. The WordCount.Service stateful service (partitioned based on the first letter of the word) immediately puts those incoming requests in a ReliableQueue and then processes them in the background, storing the results in a ReliableDictionary.
For more details, see the Reliable Services Overview.
Note: for now, the best way to expose WebAPI endpoints to clients is to self-host an OWIN server in the stateless service. ASP.NET 5 projects will soon be supported as well.
This video answers my own question: http://channel9.msdn.com/Events/Build/2015/2-704. In summary, we should use Stateless Services to host ASP.NET based sites or API's which persist data to external data stores.
If you don't have state (or have it externally), Stateless Service is the way to start.
Answer to the original question is "both". Basically, anything that have main() function (with couple of more extended contract methods to talk to Service Fabric) can be a service in Service Fabric world.
I'm building a game for Windows Phone 8 and would like to use Windows Azure SQL Database for storing my users' data (mostly scores and rankings).
I have been reading Azure's documentation on SQL Database and found this link which describes just the scenario I'm looking for (it's Scenario B in the picture): I want my clients (the game running in a user's windows phone) to get data from an SQL Server through a middle application also hosted on Windows Azure.
By reading further the documentation (personally I think it's really messy and hard to find what you're looking for in there), I've learned that I could use Cloud Services for this middle application, however I'm not sure if I should use a background worker which provides an HTTP API or a worker with a Service Bus Relay (I discovered that I can use service bus in WP8 in this link).
I've got a few questions that I couldn't find an answer to:
1) What would be the "standard" way to go in this case?
2) If both ways are acceptable, are there other advantages to using a Service Bus other than an easier way to connect and send messages to my middle application? What are the disadvantages?
3) Is a cloud service really what I'm looking for (and not just a VM with the middle application code running in it)?
Its difficult to answer these sort of question as there are lots of considerations. I don't believe there is a necessarily 'standard way'.
The Service Bus' relay service's purpose is to help traverse firewalls and NATs, not something that directly relates to your scenario, I suspect.
The Service Bus, though, also includes a messaging capability which provides queues, topics and subscriptions to use to exchange messages between clients or client/server.
You could use the phone client to write and read messages to/from queues. you would then have a worker role hosting your application logic and accessing the database as needed.
Some of the advantages of using messaging include being load leveller, helping handling peaks in traffic (at the expense of latency), helping separating concerns and allowing you to accept requests from the clients when the backend is down as so can help with resiliency.
In theory they can also help you deliver messages to the client in the same fashion, by using a queue or subscription per client, but for a large number of clients this may become a management issue.
On the downside you would have to work with what is a proprietary protocol, and will need to understand the characteristics and limitations of the service bus. you will need to manage the queues and topics over time. there will also be some increased latency, although typically not an issue and, finally, you will have to implement asynchronous messaging on the client side which has advantages but is also harder to implement.
I would imagine that many architectures follow the WEB API route by using a web role cloud service exposing the API. The web role can then perform any business logic and connect to the database in the background.
A third option, which you didn't mention, is to use Windows Azure Mobile Services and implement your business logic as a service API there