Navigating The Internet of Things

-

Having worked a number of years with connected devices, I thought I'd like to briefly share some observations and pitfalls that folks just arriving to the field should heed.

The network isn't always there

Many folks arriving on the scene of connected devices come from a background where their applications ran in the datacenter and connectivity was a user's problem. That is, if someone tries to use your site, can't, then tries google and it doesn't work...they assume the problem is on THIER end. While this isn't universal, it's much more likely than someone who tries to turn off the lights in their house or start their car and it doesn't work. While wireless providers do a very good job of connecting when devices are reachable, there are so many variables that impact coverage for a wireless device, it is almost impossible in most cases for a user to make a determination what is casing their "thing" to not work. This is especially aggravated when the device is mobile...that is, a Nest connected via WIFI is generally "working" once it initially establishes a wireless connection but a connected vehicle moving at highway speeds will very often lose connectivity for periods of time (never mind parking in "dead" zones like underground parking garages or dead zones in rural areas). While a consumer device normally has an indicator of signal strength, many vehicle manufacturer still don't provide for this functionality.

Manage battery life

Designing a device to be "always on" with a high speed data connection is a recipe for designing a device that isn't really useful. Having just purchased a Samsung Gear S, the need to charge every day is a bit of a drag. Yes I could disable all connectivity and stretch to battery life to days, but then...it's just a watch. Don't get me wrong, I love the connectedness of my gear, but it's been sitting dead on my desk for a week now because I keep forgetting to charge it. Power management is a "big deal", don't drain your user's battery necessarily and give them options to help manage the tradeoffs between "battery life" and "connectivity". For folks used to writing desktop and server applications, the idea of managing power is a completely new thing that embedded folks might understand...but surrendering to embedded notion of conserving every last milliamp hour at the expense of usability is not going to cut it.

Open wins

Too many folks in the IOT space are hoping to win market by using proprietary APIs and locking them down to keep competition at bay, this is a short sighted position. Apple realized this early on and Google forced the issue by creating an open platform. While Google itself may not directly be reaping the benefits of proprietary licensing schemes, they have succeeded in fragmenting the market and creating new opportunities for revenue that sticking with a proprietary network and stack would never allow (remember RIM?).

Comments

Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules ...
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u...
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa...
Read more