Google’s having a go at the Internet of Things, but how will it sit with developers and device manufacturers?
The long rumoured Project Brillo, Google’s answer to the Internet of Things, was finally unveiled this week at the company’s annual I/O conference, and while the project shows promise it comes at time when device manufacturers and developers are increasingly being forced to choose between IoT ecosystems. Contrary to Google’s stated aims, Brillo could – for the same reason – hinder interoperability and choice in IoT rather than facilitate it.
It’s difficult to see Project Brillo as anything more than it really is – an attempt at grabbing highly sought-after ground in the IoT space. It has two key components. There’s Brillo, which is essentially a mini Android OS (made up of some of the services the fully fledged OS abstracts) which Google claims can run on tiny embeddable IP-connected devices (critically, the company hasn’t revealed what the minimum specs for those devices are); and Weave, a proprietary set of APIs that help developers manage the communications layer linking apps on mobile phones to sensors via the cloud.
Brillo will also come with metrics and crash reporting to help developers test and de-bug their IoT services.
The company claims the Weave programme, which will see manufacturers certify to run Brillo on their embeddable devices in much the same Google works with handset makers to certify Android-based mobile devices, will help drive interoperability and quality – two things IoT desperately needs.
The challenge is it’s not entirely clear how Google’s Brillo will deliver on either front. Full-whack Android is almost a case-in-point in itself. Despite have more than a few years to mature, the Android ecosystem is still plagued by fragmentation, which produces its fair share of headaches for developers. As we recently alluded to in an article about Google trying to tackle this problem, developing for a multitude of platforms running Android can be a nightmare; an app running smoothly on an LG G3 can be prone to crashing on a Xiaomi or Sony device because of architectural or resource constraint differences.
This may be further complicated in the IoT space by the fact that embeddable software is, at least currently, much more difficult to upgrade than Android, likely leading to even more software heterogeneity than one currently finds in the Android ecosystem.
Another thing to consider is that most embeddable IoT devices currently in the market or planned for deployment are so computationally and power-constrained (particularly for industrial applications, which is where most IoT stuff is happening these days) that it’s unclear whether there will be a market for Brillo to tap into anytime soon. This isn’t really much use for developers – the cohort Google’s trying to go after.
For device manufacturers, the challenge will be whether building to Google’s specs will be worth the added cost of building alongside ARM, Arduino, Intel Edison or other IoT architectures. History would suggest that it’s always cheaper to build to one architecture rather than multiple (which is what’s driving standards development in this nascent space), and while Google tries to ease the pain of dealing with different manufacturers on the developer side by abstracting lower level functions through APIs, it could create a situation where manufacturers will have to choose which ecosystem they play in – leading to more fragmentation and as a result more frustration for developers. For developers, at least those unfamiliar with Android, it comes at the cost of being locked into a slew of proprietary (or at least Google-owned) technologies and APIs rather than open technologies that could – in a truly interoperable way – weave Brillo and non-Brillo devices with cloud services and mobile apps.
Don’t get me wrong – Google’s reasoning is sound. The Internet of Things is the cool new kid on the block with forecast revenues so vast they could make a grown man weep. There are a fleet of developers building apps and services for Android and the company has great relationships with pretty much every silicon manufacturer on the planet. It seems reasonable to believe that the company which best captures the embeddable software space stands a pretty good chance at winning out at other levels of the IoT stack. But IoT craves interoperability and choice (and standards) more than anything, which even in the best of circumstances can create a tenuous relationship between developers and device manufacturers, where their respective needs stand in opposition. Unfortunately, it’s not quite clear whether Brillo or Weave will truly deliver on the needs of either camp.