The more I learn about the Internet of Things, the more enthousiastic I become. The software architect in me is already thinking about scenarios in which IoT devices connect to my CRM environment. As the world becomes more and more hybrid, we have more and more questions to answer:
- Are we operating from an on-premise environment?
- Are we operating from the cloud?
- Do we have a hybrid environment, both cloud and on-premise?
Furthermore thoughts are running through my head about security, scalability, availability, performance. What is the load of calls we can expect to receive from those little devices out there?
How do I set up my infrastructure to have a performing environment? How do we interact with the little devices out there? How do we handle complexity on the little devices (as the embedded systems do have limited CPU power and memory)? How do we send out data to the little devices out there?
Questions, questions, and even more questions….
Every question seems to create new questions…
But then, out of a sudden, I realized myself that most likely we only have to handle inbound communications.
The IoT devices are going to contact our CRM system and not vice versa. Of course our CRM systems are going to respond in some way to the requests sent from the little devices.
For now, most likely the response from our CRM system will be in de form of a phone call from one of the customer representatives or in the form of an email sent to the owner of the device.
What I don’t want is to allow direct communication from the little devices to my CRM system. By allowing direct communications, I’ll expose the internals of my company, making the company vulnerable to possible hacking attacks. Therefor we need to provide a Web API controller to which the little devices will communicate. The Web API controller will dispatch the incoming message to the company’s CRM system.
See image below.
By creating a gateway, we provide a great deal of flexibility in the integration scenario. I’ll explain why:
- We can provide a simple and effective REST API that even the simplest devices can handle. This API can be access anonymously.
- in case we are running on-premise, we can add additional load balanced Web API controllers to handle any load).
- in case we are running on Azure, we can scale up by adding more bandwidth, memory and CPU (the sky is the limit ).
- we can have seperate processes for both the web API controller and the dispatcher (even over multiple servers).
- we can use mechanisms like message queues to deliver the incoming message to the dispatcher (think: BizTalk in case of an Enterprise Service Bus).
- Flexible: We can change our internal network (and it’s application landscape) without affecting the communications with the IoT devices.
- we can keep the security internal. No hassling with user accounts and passwords from the outside.
- for external security we can use industry standard mechanisms like MD5 hashing and encryption.
- We can move our company’s infrastructure to and from the cloud (depending on our needs/budget/wishes etc).
As you can see, there is not much difference in the way we integrate with IoT devices compared to regular applications. As software architects we have to comply with normal design considerations like security, scalability and flexibility. Giving us more room to focus on the new devices out there.
In the next weeks I’ll take you into my journey; building a sample IoT application scenario, connecting to Dynamics CRM. *YAY!*