The Internet of Things (IoT) is becoming a bit more than a fun three letter acronym. And while internet connected devices have been around for a while, turning it into a practice is an important evolution. It allows the establishment of best practices, better integration into standard software development, and thus more robust applications, sometimes too robust. And because software drives everything, and software quality is key. How can you ensure quality in all those connected devices?
Tag: IoT
-
The Internet of APIs
The Internet moves at the speed of light. Not only that, but the terminology used when describing The Internet seems to change with the tides. One of the newest phrases to start making the rounds is “The Internet of APIs.” In an attempt to understand exactly what it is, I went looking for a definition and was unable to find anything at all. As such, it’s time to put a definition out there.
There are two important words in the phrase: “Internet” and “API”. Let’s start with the last word first and work backwards. What exactly is an API? Luckily, the definition of API is pretty settled. For our purposes, I like the definition given to us by API Evangelist:
An API, or Application Programming Interface, at its most fundamental level, is how software applications talk to each other using the Internet. An API allows you to open up data and other digital resources, to public developers, businesses, or even between departments and locations within a company. APIs are increasingly the way in which companies exchange data, services and complex resources, both internally, externally with partners, and openly with the public.
And while we’re at it, let’s look at the popular definition of “Internet” given to us by Webopedia:
The Internet is a global network connecting millions of computers. More than 100 countries are linked into exchanges of data, news and opinions.
So we’re narrowing down on a definition of The Internet of APIs. But we’re not quite there yet. Let’s look back at recent history to see if we can clarify things a little bit. The modern-day web API has been around since Salesforce introduced it’s API at the turn of the century. In the year 2000, they introduced an XML-based API that kicked off the web services API era. And while there were a few other web services APIs that came out afterwards (including eBay and AWS); but things didn’t really start getting serious until Flickr launched their API in 2004. The social network revolution, sparked by companies like Friendster, MySpace and Twitter, brought about a real need to securely exchange information between multiple applications. So when Facebook and Twitter announced their own APIs in 2006, that was when the usage of APIs grew to include identity management in addition to the exchange of data it had become known for.
And then came smartphones. APIs exploded in popularity once the smartphone industry took over the continent thanks to Palm and Blackberry; then came iOS and Android. Why the popularity explosion? Well, applications needed to be made for these new (popular) form factors. However, these new form factors had very specific requirements around data usage, drastically different screen sizes than application developers were traditionally used to, along with previously unseen device capabilities. Add to that the fact that mobile applications needed to figure out a way to share data with each other securely and a perfect storm of needs presented itself.
While all of this was going on, the wireless capabilities available to the consumer also changed. In the year 1999, one year before Salesforce released their web services API, 802.11a and 802.11b hit the market. WiFi was still a growing technology, but the introduction of 802.11a and 802.11b changed everything. The prior iteration of 802.11 had a transfer rate of 2 Mbps; while a allowed for short range speed of 54 Mbps and b allowed for longer range speed of 11 Mbps. The cost of b was also a lot lower than a.
Also in 1999, the first full Internet service available on a phone was launched in Japan by NTT Docomo. This was during the days of 2G networks. In the US, around the same time, cell phones became affordable to everyday consumers. It was a time of incredible growth in the wireless industry and over the following years, cellular networks were stretched to their limits.
This is the environment that led to the growth of the web service API. There were a few things that were extremely important to the upcoming boom:
- A speed boost in wireless networking was required; and
- Wireless networking hardware needed to get into the hands of more people; and
- The cost of wireless networking hardware needed to drop; and
- Cell phones needed to get in the hands of more consumers; and
- Internet service needed to hit the cell phone.
Add all of that to the growth of social networking and identity management via API, and a perfect storm of circumstances presented themselves. More and more APIs were built utilizing a person’s identity for personalization and security.
Thus the Internet of APIs was born.
So, based off of the existing definitions as well as recent history, what exactly is “The Internet of APIs”? The Internet of APIs is:
A global network of structured data, digital resources and commands accessible via a growing interface that allows applications and devices to exchange information using any and all communications protocols available.
Since the creation of the ARPANET (arguably, the Internet’s predecessor) packet-switching networks have been utilized as an efficient and reliable way to exchange data. So what’s different about the Internet of APIs since at its core it’s about exchanging data? The main difference lies in the fact that the data provided by the Internet of APIs is data with structure. It’s data that is being shifted around and meant to be consumed in ways that may not possibly have even been foreseen by the creator(s) of the data. The Internet of APIs allows data that may have been designed for one thing to be used for something completely different; thus facilitating the connection of two completely different applications in ways sometimes unimagined.
The Internet of APIs is the underlying foundation to the Internet of Things. Without the capability for connected devices to personalize their usage according to the individual, as well as share data, the Internet of Things could not exist. Without the improvements in specifications in both wireless and cellular hardware, the Internet of Things could not exist.
The Internet of Things is powered by the Internet of APIs; and as the Internet of APIs grows in scope and capability, the same will happen to the Internet of Things. Without regularly updated data and personalization, a hardware device is dumb. A thermostat is just a thermostat without the underlying API. But with the API, a thermostat becomes a Nest. Without an API, a light bulb is just a light bulb. But with the API, a light bulb becomes a Philips Hue light bulb. Without the Internet of APIs, a person walks in to their home, walks in to their living room, flicks a light switch and turns their heat up. With the Internet of APIs, a person walks in to a warm, well lit home because their thermostat turned on five minutes before they got home and their lights turned on one minute before they walked through the door.
Data and personalization: that is the power of the Internet of APIs.
About the Author/Kurt Collins
Kurt Collins is Director of Evangelism at built.io (link). Before that, he started his engineering career as an intern at Silicon Graphics (SGI) where he worked on debugging different parts of their UNIX-flavored operating system. Two years ago, Kurt co-founded The Hidden Genius Project along with eight other individuals after they all saw the screaming need to increase the amount of Black men in the technology industry. Mentoring young people interested in the technology industry is a personal passion of his. Today, he continues his work with tech startups and non-profits alike. -
I Like Your Backend
Back in the early 80’s, dumb terminal networks ruled enterprise IT. Mammoth mainframe IT infrastructures worked as centralized corporate computing platforms feeding a vast nexus of thin clients performing mundane IT operations as intended. Perhaps that was all what end-users longed for.
-
DevOps + IoT
The Internet of Things (IoT) is part marketing hype and partly a real movement. After low power WiFi chips have allowed small devices to connect to the web for a long time. Remember Eye-Fi founded in 2005?
But there is no denying it is BIG. Service revenues rooted in micro-controller-based IoT are expected to reach a whopping $7.3 trillion by the year 2017 according to a recent IDC report, with the radical new paradigm shift of DevOps leading to the perfect storm of IoT adoption.
IoT is set to be a disruption those building and connecting things. It forces a transformation that is largely driven by the integration of development, IT operations and quality assurance practices delivered for IoT under a single automated umbrella in the DevOps-oriented world.
-
Internet of Things (IoT) poses challenges for DevOps and security
One of the hottest things in tech today is the Internet of Things (IoT). Everything will be connected including every gadget, kitchen appliance, wearable device and vehicle. But one of the biggest areas for IoT are controllers embedded into just about everything. These controllers will report back, generating reports and information that can be analyzed and acted upon. IDC says technology and services revenues rooted in components, processes, and IT support for the IOT will reach US$7.3 trillion by 2017, up from US$4.8 trillion in 2012. When you are throwing around numbers in the trillions that is no small feat.
New IoT implementations require projects (such as application development and backend integration, for example) that many enterprise customers don’t have the resources or custom development experience for. Vendors such as Microsoft and AT&T are responding with IoT consulting services. These vendors must be flexible to meet the needs of enterprise customers whose IoT can include machines and devices from a variety of makers. As such the bigger vendors are generally agnostic towards partnering with otherwise competing vendors in order to pool the necessary resources to complete an IoT project.
When management contracts a vendor / consultant for this kind of engagement, a DevOps mindset really helps to ensure the new IoT ‘glove’ fits the existing IT and information security ‘hand’. As challenges appear, a DevOps approach utilizing best practices is the best way to meet them.
A common challenge with IoT projects is the disconnect between management desires and IT realities. IoT projects often begin because management has a goal to receive specific information. Many IoT projects involve installing controllers in business and manufacturing to retrieve data from their IoT. The controllers themselves are of course hardware. This of course is a challenge to traditional DevOps approaches. By its very nature IoT is dealing with hardware that is difficult to upgrade. Of course more and more it is the software that is driving the innovation
“In many cases, management may hear good things from a competitive company they know who uses a specific controller device that they really like,” says Jerry Irvine, CIO, Prescient Solutions. Management may request that the vendor pull in that maker and product and that IT work with them to make it work. Unfortunately, IT will often find that the device is not compatible with the proprietary systems they use. Then the business will often ask them to find a compatible substitute and may still want it by a given deadline. This is not how anyone should acquire controllers.
The best practice solution is for the enterprise to have an R&D team including IT set up to work in an on-going fashion to provide requirements for the IT environment and the business function. “In this way, IT and executive management can proactively and consistently look for new offerings with compatible features and functionality,” says Irvine.
Another way DevOps can help in IoT projects is to maintain the environment in the least customized way possible. When a vendor puts in a controller, they will certainly be able to customize it to provide the specific reports and functionality that the customer wants. If the customer wants to go beyond the standard reports and capabilities however it now can pose a challenge to automation and further development.
The issue is that when the enterprise needs to apply updates to the hardware, device software, or management application, the vendor must customize that as well, and the updates come at a hefty premium rather than standard (gratis) with the product. The best practice solution, says Irvine, is for the enterprise to take the entire report that the controller can provide standard, and customize the data from the report on the end afterwards. Customize as little as possible.
Security is another challenge for IoT projects. The fact that these devices are connected via the Internet can make them a target for hackers. Companies deploying controllers should ask themsevles “how sensitive is the data that IoT devices and wireless communications will handle, and how dangerous can the IoT machine or device be? ” If developers/IT and operations can say with a certainty that the IoT application will never handle extremely sensitive data such as credit card numbers, and that the IoT device is not a car, dangerous machinery, or a potentially dangerous medical device, for example, then of course security is less of a concern. But part of goal of DevOps should be how do we build security organically into the device, software and process.
John Pescatore, Director of Emerging Security Trends, the SANS Institute. IT and management says we will have to limit what IoT applications can do. If the application must use sensitive data, it has to be encrypted and the end device has to have enough processing power to do encryption or it cannot be part of this application. Likewise, for security of life and death critical applications, there is a part of the DevOps model that does not make sense. That part is the “build a little/fail a little/fix” type model of the evolution and perfection of the device. “Letting your customers find failures in MRI machines or 787 Dreamliners is not a good idea,” says Pescatore.
So how do we reconcile the DevOps model, along with security when building components for the IoT? The challenges are there, but they can be overcome when we are talking about trillions of dollars at stake.
