This was a fascinating week at the TechIntersection conference. TechIntersection is a new conference with three intertwining tracks, Architecture, Security, and IoT (Internet of Things}. The need for such cross pollination is obvious. Apps built for the Internet of Things rarely take account of the issues they will require to scale to millions of installations, each potentially interacting with other Apps from other developers. Security doesn’t really understand the special needs of things, just as IoT Apps often violate enterprise expectations for security and privacy. Enterprise architects have some nifty new tools that will provide great value to IoT developers, but they have no idea what an avalanche of data and connections that is headed toward their data center.
On the IoT side, we had developers of domotic systems, and mobile vehicle systems, intelligent floor pad market awareness systems and even a church missionary group working at the intersection of water and power and gospel in integrated delivery systems.
The architecture sessions covered approaches to modularization, project management, performance engineering and security from the always solid iDesign team. It included surveys of internet-centric design {notice I did not say web-centric), platform optimization, and microservices. There were also in-depth drill downs into the latest Azure technologies and service fabrics from Microsoft. My favorite demonstration requested a
The security was driven by a developer-centered approach to security with an emphasis on not doing stupid things. It included always enjoyable live penetrations of live sites using google tools and a little creativity. One government site still had an exposure of its own security and of the database behind it that had persisted for years. It also included a live hijacking of all the phones and PCs in the room.
It was truly a high-powered set of speakers.
In my presentations, I shared some scars from my own decades of development, and cautioned about optimistic notions about how many IoT points could simultaneously deliver high speed telemetry to the cloud. People always seem to think that getting one point and then another one is the same as getting two point in one request. Emotionally (by which I mean not analytically), they seem to leave out the traffic to create a session, establish security, and then send a packet. They don’t think of the inefficiencies of sending half empty packets. Caching and batching of telemetry is going to matter much more than the glib presentations.
I mentioned microservices before. Microservices are isolated bits of code that provide some service. The Azure service fabric is able to support very large numbers of simultaneous microservices, both within a system, and across systems. Barry Briggs demonstrated the amusing and powerful open source Cloud Sheet. Each microservice was a small bit of code that was able to interpret an equation, including an equation the referenced another service by name. The services were all assigned names similar to A1, A2, and C3. There was also a web-based interface in which each microservice was referenced by a single on-screen cell. Cloud Sheet is a cloud-based scalable spreadsheet, able to spread across multiple cores, multiple systems, and even multiple data centers.
Well that was fun, but it almost does not seem worthwhile. That judgment, though is before considering additional code in each service. Barry went on to load million-row data sets into some of the “supercells”, some pulled from web sites such as NOAA, and some from “local” text files. The supercells would parse the data and support statistical queries (average of all humidity readings in 1984) from other cells. Suddenly a cute demonstration was a tool of surprising power.
My talks focused on a time and resource-based model for interactions between apps. If Apps, while performing their functions, influence the use of a constraining resource, i.e., power, then they can communicate between themselves to smooth and optimize that resource use, using lightweight services based on the three market oriented communication specifications (ws-calendar, EMIX, Energy Interoperation) of smart energy. WS-Calendar can be used even in non-resource constrained decision-making to negotiate optimum run times.
After the conference I drove up California 1 along the coast to Half Moon Bay to visit my nephew. As always, my world tour of coffee shops, writing in each one, continues.