Continue Reading Previous Brain-boggler at ESC Boston 2017Next The app I tried Different product pipelines In IoT, there is more variation to be expected on product delivery for multiple customers (both in terms of customization and enhancement) as well as market segmentations (low, medium, and high). This presents varied production environments that may be difficult to reproduce and maintain at the development stage.Release cadence Different component of solution including firmware, web app, mobile app, and PC app have different release cadences making a unified release plan a challenge. The development of multiple features of different releases becomes challenging unless there is a well-defined process followed through, for regularly integrating the code.Also, there is a curiosity to know the true extent to which IoT developers take advantage of “mainstream” approaches like continuous integration. Based on our own project experiences, we have seen that IoT developers can leverage anything between fifty to sixty percent of DevOps implementation in areas comprising continuous integration, testing, deployment and monitoring. The IoT ecosystem has the additional complexity of people with different skillsets following a scrum of scrum agile methodology.There are already many commercial mainstream tools available in the market for continuous integration. For IoT, it helps us offer great assistance but would need some modification and enhancement. For example, continuous integration in IoT would require the integration of multiple and fragmented development pipelines like device, web and mobile devices and prepare main and customized builds. This would include automating environment configuration, code review, regression testing and reporting.Continuous testing in IoT can be more effective with sensor virtualization and simulation of physical devices (vCloud, VSphere etc.). A CI tool (Jenkins, Bamboo etc.) can be leveraged to integrate the automation framework.Hence all these varied skillsets, tools and processes have to merge together to deliver DevOps in IoT.It is also a concern for enterprises that how developers (product manufacturers) in IoT should balance advantages like frequent updates with the practicalities of remote device update. To solve this, one has to note that the release cadence in IoT differs from traditional software release deployments. IoT release cadence differs due to components. For example, a web patch application upgrade can be a monthly release cycle whereas a device upgrade release can vary from three to six months . So continuous testing has to evolve to devise a more optimized way of testing solution exhaustively. IoT testing is costly because infrastructure is huge along with exhaustive test coverage. eInfochips engineering teams have been able to reduce time to testing with improved quality for clients in various industries with our proven IoT testing methodologies. Embedded devices security and memory concerns The next important question is, How does DevOps for IoT work within robust security policies such as authentication, secure over the air update , etc.As there are multiple deployment endpoints in IoT, security has to be looked at from multiple aspects. There are fundamentally three types of risks here: data at rest, data in motion and data in cloud. There is a computation risk within devices or within the cloud. Also there are hardware tampering risks with physical device. The DDoS attacks on Oct 21, 2016 (now known simply as 10/21 attacks) using a network of hacked cameras and DVRs had crippled the Dyn server, effectively hurting traffic at high profile sites such as Twitter, Amazon and Netflix Clearly, enterprises working on IoT solutions will have to figure out creative ways to improve the trust factor of their end products. The security concerns in IoT development environment can be greatly mitigated by inserting improved visibility and control over devices, giving each device its own identity with the business environment and humans.Embedded systems may have limited resources including memory. This can definitely impact the targeted system for implementing DevOps. Within the purview of DevOps, continuous deployment and continuous monitoring on embedded systems with limited resources will have an impact.For continuous deployment, for example, a lot will depend on the design and architecture of how the firmware update is deployed on a particular device. For continuous monitoring, non-functional parameters like reliability and performance assume prime importance as a lot will depend on how remote updates and monitoring can be implemented without hindering the performance of the device. Also. methods to extract data and pre-processing with a dynamic rule engine before it reaches the cloud is very important.Looking Forward The common refrain of enterprises working on IoT projects is that at a given time, there’s simply not enough talented resources with the right skills and expertise to sync with project timelines. Ensuring the timely availability of technical staff and skills is an important and desirable trait. Additionally, one has to factor in resistance to new technologies, practices and processes by the workforce. Depending on the requirement, outside expertise may be in order with service providers plugging the gap by bringing in additional skills.References  Manyika, James; Chui, Michael; Bisson, Peter; Woetzel, Jonathan; Dobbs, Richard; Bughin, Jacques; Aharon, Dan. “Unlocking the potential of the Internet of Things.” June 2015. McKinsey.com. 19 January 2017. John Roberts, Jeff. “Who to Blame for the Attack on the Internet”. Oct 24, 2016. Fortune.com . 19 January 2017. Share this:TwitterFacebookLinkedInMoreRedditTumblrPinterestWhatsAppSkypePocketTelegram Tags: Design Methods There is no doubt in anyone’s mind today that enterprises across all verticals are viewing the growth of the Internet of Things (IoT) as a playground of endless opportunities with somewhat undefined rules – clearly a market that they don’t want to miss out on. A McKinsey & Company analysis estimates the total economic value of IoT technologies in the range of $4 trillion to $11.1 trillion a year by 2025. In order to weather the big changes of IoT transformation in near future, IoT application developers and product companies must understand that faster time-to-market is very critical to success in the IoT marketplace. To achieve that, you must allow IoT development platforms to do most of the heavy lifting . This is currently a major focus for large IoT enterprises right now, and can indeed play a very key role in the development of scalable IoT applications and services, leading to faster time-to-market because of reduced costs and time of delivery. There is also reduced need for coding and testing.To really get off the mark though, we have to understand that present day enterprise structure is really the single biggest roadblock to success in IoT . In journeying a traditional enterprise through the complex labyrinth of changes in IoT, what we require is a supportive culture and environment which celebrates collaboration and efficiency , cutting across departments, a far cry from the silos of the past.Considering the high stakes involved, if there’s one thing early adopters have learned about the nature of the IoT marketplace, the biggest obstacle to success lies in the way the modern enterprise is structured in terms of their development and operational efforts . When you’re dealing with connected devices and large chunks of data strewn among multiple delivery touchpoints, the way your people, processes and tools are geared together will play a decisive role in determining whether your solution is ready for lift-off, or everything will regress back to square one.DevOps has recently emerged as one of the most viable ideas to bring quick turnaround, speed, agility and scale in IoT solutions development. Basically, connected devices bring with them the need for continuous software deployment, for which the present day enterprise is poorly equipped to deal with the challenges that emerge during an ongoing project.DevOps in IT versus DevOps in IoT There are some fundamental differences in the way DevOps is applied for IoT solutions, as compared to a simple software engineering practice. In IT industry, the application of DevOps looks fairly straightforward.Figure 1. DevOps application in IT. (source: eInfochips) However, when you’re dealing with connected devices, sensors, unified protocols and gateways, the complexity becomes much greater. This manifests in the following ways:Complex and fragmented development pipelines: In IoT, DevOps implementation is in same as it is in pure play IT Software. The different development pipelines i.e. firmware, server side code, mobile app, desktop app adds to multiple delivery end points . Over and above hardware design/upgrades adds to further complexity. The team composition for each one of the pipeline requires different skills and follows different processes. Development teams might be able to deliver a quality code for the given pipeline, but it is challenging to integrate all the pipelines to ensure end-to-end product testing is quality proven. This requires processes to be enhanced to support the integration of code with regular Build-Verification-Tests that ensure that the code is always ready for deployment and is available to make emergency fixes/upgrades as and when needed.Legacy device and solution support Products along with cloud infrastructure usher in requirement for managing, updating, and maintaining existing devices on the field along with new additions, again increasing the variations and complexities in DevOps. The solution should be to support legacy devices/edges such as sensors and cameras to sustain the market. Further to this, there is a need for rigorous testing in end-to-end workflows. For example, a new thermostat launched in the market with its own self-learning features and cloud data collection/analytics would be definitely a preferred choice of end customers for their home automation product; but this can pose indefinite challenges for the solution designer as well as the involved test teams.Environment as code (when infrastructure as code is not enough!) Product engineering space brings additional challenges of virtualizing multiple associated devices along with the server infrastructure. The concept of ‘Infrastructure as code’ (IAC) needs to be extended to offer complete ‘Environment as a code’. Within private and public clouds, organizations are moving from capital expenditure (CAPEX) to operating expenses (OPEX) models – pay for what you use. The virtualization of the edges is needed to simulate legacy as well as new sensors for testing of Consumer Premise Equipment (CPE) in integration with cloud data analytics. Leave a Reply Cancel reply You must Register or Login to post a comment. This site uses Akismet to reduce spam. Learn how your comment data is processed.