The purpose of communication between things and apps will become more critical to understand and act upon as the number of things continues to grow
One of the neat things about microservices is the ability to segment functional actions into scalability domains. Login, browsing, and checkout are separate functional domains that can each be scaled according to d.... While one hopes that checkout is similarly in demand, it is unlikely to be as popular as browsing, after all, and the days of wasting expensive money on idle compute resources went out when the clouds descended.
In that same vein comes the ability to also create performance domains. After all, if you're scaling out a specific functional service domain you can also specify performance requirements for that domain - and do something about it. Whether it's through caching or minification or TCP optimization techniques, you can improve the performance of a specific logical domain right along with its scale.
Cool, eh?
The lines between IoT and microservice architectures are not usually made, but if we view part of the benefit of microservices as being the creation of logical, functional domains then we should be able to see a parallel on the device - the thing - side of the house. Things connect to other things and applications for a variety of reasons. Licensing, activation, sending and receiving data, updating, patching, etc... They connect to perform a specific and sometimes very granular set of functions.
Functions. Like those described in when decomposing applications into microservices. Verb-based computing. Purpose-driven.
It stands to reason, then, that like microservices, there are discrete set of functions - of purposes - for which a thing might be connecting to a corresponding enterprise app (or service). That purpose is likely (almost certainly in an age driven by RESTful APIs ) to be able to be identified by some key name or value in a URI.
Given that information, the network (or at least the application-aware top 4 layers of the network) should be able to apply policies based on that purpose. Checking for an system update? Not necessarily critical, don't worry about performance too much. Updating a profile? That's a user interaction - pump up the performance, get it done fast because impressions matter to people, not devices. Security update? Let's prioritize that, shall we, because security is critical to maintaining trust not only between things and apps but between people and providers. I'm sure you get the gist at this point.
Purpose-driven networking.
The ability to not only scale to meet demand but interpret the context in which a request is being made will be important to enabling the efficacy of an IoT-enabled data center architecture. Purpose-driven networking means not just recognizing this is Thing 1 or Thing 2 and routing requests to the appropriate service, but recognizing what Thing 1 or Thing 2 is trying to do and delivering in such a way as to meet expectations with respect to its performance.
Purpose-driven networking requires collaboration and thus a NetOps or DevOps approach to architecting such solutions may be necessary. A well-defined set of purposes - of actions - will be needed from the business and developers in order to put such a technical implementation into play. This is as true for scale as it is for performance. Both need to be understood from a higher level perspective than bits, bytes and URIs, and implemented accordingly. That takes communication and collaboration. It takes measurement and analytics to ensure expectations are met (or hopefully exceeded). It takes agile and programmable infrastructure able to intercept, evaluate and interpret each request with an eye toward user, device and, now, purpose.
IoT and microservices are each, on their own, going to put a lot of pressure on the network (that's all 7 layers). Together they're going to force changes and adaptions of not just traditional but emerging network architectural principles to meet the unique conditions the two will create.
