The IoT is massively dynamic in nature. Platforms, standards, data types and devices themselves change all the time. But deeper down, an even more fundamental dynamism and propensity for erratic change affects the way the IoT is being built.
Software applications, including the embedded software that populates large parts of the IoT, are also changing.
Memory has become a lot cheaper in recent years. From the smartphone in your pocket to the hugely less sophisticated elements of software that run your web camera-enabled smart doorbell, devices now ship with enough memory to handle an increasing amount of compute power.
More front-end logic on the device means smarter devices, yes. But it also means that the remaining back end (at the cloud datacenter, or any other connected back-end basepoint) has become dominated by ‘engine room tasks’ – storage, data retrieval, security and privacy.
This cloud-centric back end also has to shoulder workloads associated with integrating and composing the various services that an application needs. That’s a lot of back-end work if we’re going to maintain front-end agility on the parts of the IoT that the user actually sees.
To compound this trend, we’re also seeing a divorce (albeit an amicable one) between our IT devices’ ‘systems of engagement’ (the user interface elements with which a user interacts) and their ‘systems of record’ (the engine room ‘guts’ with which the data interacts).
What all this rumination leads us to is a simple enough technology proposition: the IoT and its applications are now straddling an increasingly demarcated gulf and they have to be able to bridge this gap comfortably. In order that they can land in more places when they get across the front-end/back-end gap, that back end needs to be open, supple, dynamic and flexible in terms of the schema in which data is stored.
(When we talk about a schema, we refer to the organizational structure of a database in terms of its tabular and columnar format and defined internal relationships. A schema is what allows us to express what information can exist inside a given database. If information won’t fit into a particular database’s schema, then it can not necessarily be held, expressed or analyzed.)
With so many data dependencies (dependencies as in ‘needs’ not as in ‘application library dependencies’) changing at the front-end of the IoT, the argument here is that a traditional pre-NoSQL database (with columnar short-sightedness) will eventually fail to be able to cope with the dynamism happening at the upper device level.
How the IoT messes things up
When information emanating from the IoT changes, then a ‘standard’ relational database can start to struggle. A whole new schema has to be created and an extraction, transform and load (ETL) process has to be performed, to move the data from one area to another.
Open source document-oriented database company MongoDB says it has watched this whole argument play out and it has guided the thinking behind its latest product. MongoDB Stitch works to give applications a route to handling all the engine room ‘boilerplate coding’, including controlling data access and orchestrating commonly used services such as authentication, executing payments, handling messaging and so on.
“In recent years, we’ve gotten a tantalizing glimpse into a world where developers can spend all their time writing the code that distinguishes their applications,” said Eliot Horowitz, CTO of MongoDB. “In this world, services become the building blocks of innovation and the need to re-implement the same commodity components disappears completely. But the mere existence of services isn’t enough, because there is still the drudgery of tying those services together, implementing tricky but essential access control… and of course managing data.
MongoDB Stitch, he claims, removes those barriers and gives developers “the tools they need to build ground-breaking applications with less friction than ever before.”
Chicago, the smart city
Tom Schenk Jr is chief data officer for the city of Chicago. Speaking at this week’s MongoDB World conference in his home town, Schenk explained that his firm has built a city-wide command and control software system, with MongoDB on the back end to track municipal services information in a world of changeable schema. This is a world where one canonical single version of the truth could not persist for long.
“We are able to receive 911 calls, reports on where potholes need filling, which restaurants need to undergo food inspections and so on, around our city. The city of Chicago is 245 square miles, so how do we know where to send our maintenance staff? The answer must lie in predictive analytics, based upon an open back end with dynamic schema,” said Schenk.
Schenk also explained the data team is starting to look at other key variables such as weather, whether particular bars have alcohol licenses, whether major events are being staged in the city and a variety of other changing factors.
Analyst at RedMonk James Governor agrees that developers today want platforms that maximize convenience and minimize back-end coding, with managed services for functions like user-based access. He characterizes MongoDB Stitch as a “back-end as a service platform”, designed to make it easy for developers to build rich and secure apps.
“MongoDB Stitch has huge potential to streamline the development process for integrating with third-party services and REST-like end points,” said Charles Nelson, developer at OK GROW, a web and mobile app development shop based in Toronto. “The ability to separate some or all of an app’s logic, authentication, authorization, and processing from the primary servers opens up a world of possibilities that is both exciting and refreshing.”
Read more: Telefonica & Huawei launch NB-IoT open lab