devopsy.kinsta.cloud

Tag: IoT

  • Chip-to-Cloud IoT: A Step Toward Web3

    Chip-to-Cloud IoT: A Step Toward Web3

    During the first six months of 2021, IoT devices were breached 1.51 billion times, a significant increase from only 639 million breaches observed for the entirety of 2020. This problem can be attributed to the widespread adoption of the internet-of-things (IoT) and the Windows Server Message Block (SMB), and neither can be avoided in the age of remote work. 

    But while these technologies offer unprecedented levels of data mobility and oversight for many interconnected digital and physical systems in industrial settings, they also make it easier for malicious actors to penetrate the very fabric of our lives if left unsecured. 

    This makes it all the more important for DevOps teams and developers to prioritize cybersecurity while creating systems for the IoT. It is important to address the inherent flaws in security like easily-breakable usernames and passwords or saving data without protection on remote access servers. 

    There is a way developers and DevOps professionals can help curb the increasing instances of cybercrime, and it’s called chip-to-cloud IoT. Let’s explore how it is emerging as a viable way to construct a safer, more valuable and more decentralized system for everyone.

    IoT: Understanding the Inherent Security Challenges

    It’s best to investigate potential cybersecurity issues that may befall your organization before finding ways to secure your IoT platforms with solutions such as a shift left security approach (meaning security is embedded in the earliest phases of the application development process) or an IoT decentralization approach, as we’ll expand on below. 

    Some common security concerns include:

    Vulnerabilities in the Software and the Firmware

    It can be challenging to guarantee the safety of IoT systems because of the following security flaws:

    • Lack of computational capacity to provide adequate built-in security
    • Inefficient access control in IoT systems
    • Insufficient funds for adequately testing and further developing the firmware’s security
    • Lack of regular patching and upgrades as a result of IoT devices’ technical and budgetary restrictions
    • Unpatchable vulnerabilities because users don’t regularly update their gadgets
    • Older devices may not be compatible with newer software updates
    • Easy accessibility means attackers could insert corrupted chips or hack via radio waves

    Possibility of Cloud Breaches

    Hackers can gain access to the data processed by your IoT system by intercepting unencrypted messages. 

    Your device might contain sensitive information such as your location, bank account information and medical records. Attackers can access critical information in many other ways, including by exploiting weakly protected communications.

    Even if every piece of data is transported to cloud storage, intruders can potentially target cloud-hosted applications. Therefore, the risk of data leaks is not just from the devices themselves but also from the cloud environments to which they are connected. That is why DevOps pros, developers and software engineers must find ways to protect the technology from the start and prevent hackers from breaching the cloud.

    Risks of Malware

    A recent survey by Zscaler revealed that smart TVs, set-top boxes and smartwatches are most susceptible to malware attacks. 

    If attackers successfully infiltrate an IoT system or insert malware, they may be able to change its functionality, acquire personal data and carry out other malicious activities that can endanger device owners and users. 

    The trouble is that manufacturers struggle to maintain proper software security to keep their devices safe. Security often takes a backseat when these gadgets are built, leaving buyers to deal with the aftermath if they get infected with malware. 

    How Chip-to-Cloud IoT Minimizes Security Risk

    There are two ways for organizations to enhance their IoT security. 

    The first step is ensuring both device manufacturers and software developers adhere to sound security principles. If the value chain is exposed, the solution must be chip-to-cloud. 

    Second, they must take an in-depth approach to protecting key technology by layering security controls to create an iron-clad IoT infrastructure.

    The chip-to-cloud architecture enables the creation of secure, low-energy networks of IoT devices that can communicate directly with cloud hosting platforms. The collective effort to build a cloud-first technology stack has been costly, inefficient and unreliable.

    Traditionally, IT professionals have used non-machine-hosted security tools like firewalls to secure IoT devices. Chip-to-cloud architecture aims to fix this underlying flaw.

    Features of Chip-to-Cloud IoT

    Onboard security and computational power are two of the most significant shortcomings of IoT devices. In addition to being more powerful and safe than previous models, IoT devices built with chip-to-cloud security are also more energy-efficient.

    Here are the features that make the chip-to-cloud technology so effective:

    • An onboard cryptography engine
    • Generator of random numbers
    • Sufficient random-access memory (RAM)

    How It Works

    Reliable software design is essential for IoT devices and other internet-connected devices. It keeps hackers from stealing your identification or duplicating your device for their ulterior motives. Chip-to-cloud delivers on all fronts. 

    These chipset characteristics confer an extra security advantage. Each IoT node is cryptographically unique, making it nearly impossible for a hacker to impersonate it and access the more extensive corporate network to which it is connected. Chip-to-cloud speeds things up by eliminating the need for traffic delays between the logic program and the edge nodes that are ready to take action on the information.

    The chip-to-cloud architecture of the internet-of-things is secure by design. New tools are being developed to provide bespoke and older equipment with data mobility capabilities, just like the current IoT. 

    Nevertheless, chip-to-cloud chipsets are always connected to the cloud. As a result, the availability of assets and the speed of digital communication across nodes, departments and facilities will be significantly improved. Chip-to-cloud IoT is a significant step forward in the evolution of the IoT toward Web3. Experts predict IoT device customers and value producers will benefit more from these design principles than centralized providers.

    Chip-to-Cloud Enables IoT Decentralization

    The traditional approach to IoT is to cover an already-existing cloud of linked devices with third-party firewalls and other security measures. Its equivalent imagery would be a single umbrella covering a family of 12—or at least attempting to do so. The protocols that govern security must be central to decentralization.

    Chip-to-cloud IoT is a powerful, uniquely secured chipset that can be installed inside each device, giving it a far greater connection in the IoT chain than the average IoT gadget.

    The cloud manager or analytics application receives data from every node in real-time using the chip-to-cloud technology. The process does not add another layer of protection; instead, it reduces the latency and loss of data packets as they travel from one destination to another.

    The Future of IoT

    In the wake of recent global events, general cloud technology and chip-to-cloud architecture are receiving huge investments. IoT can supply the data that companies and organizations need to fuel their client engagement portals, machine maintenance platforms and enterprise planning tools.

    That said, the internet-of-things will not be entirely safe even with chip-to-cloud technology. Businesses must have a security-focused culture, standards for managing new IT investments and the expertise to pick the best technology partners.

    The Web3 transition will likely be coupled with future Web3 innovations such as blockchain to improve its utility and security. Seeing how the world’s genuine value-creators use these new solid tools will be intriguing.

    Conclusion

    Considering security at the very onset of any IoT project is critical. Maintaining comprehensive cybersecurity in IoT environments is challenging due to the rising frequency of cyberattacks and increasingly complicated system vulnerabilities. 

    The safety of IoT devices is essential to the operation of many businesses—and even entire economies. Engineers are under increasing pressure to ensure that the rapidly expanding number of interconnected devices is safe. This is why chip-to-cloud technology is poised to become the next big thing in this field. Are you ready to be the change?

  • How DevOps is Revolutionizing Embedded Development

    How DevOps is Revolutionizing Embedded Development

    There’s something curious happening on the desktops of embedded developers around the world. From home offices to cubes to labs, in lamp-lit rooms late at night and sun-lit rooms early in the morning, developers are doing something different. They’re beginning to implement DevOps practices in their embedded development.

    Something quite serendipitous has occurred to make this possible: The parallel rise of cloud-native computing and the explosion of internet of things (IoT) devices and edge technologies. A world with billions of embedded devices connected to the internet all the time, every minute of every day, requires a new way of designing, testing, deploying and maintaining these devices. At the same time, cloud-native computing has introduced continuous delivery (CD) and continuous integration (CI), among other methods, to enable automated software builds that are reproducible. This is creating a revolution in the embedded world.

    Until now, embedded software was written and deployed and then remained static in perpetuity because it was isolated. Not anymore.

    The Slog, Security Demand New Thinking

    Embedded software developers have traditionally faced a monumental slog to build projects. Typically, embedded developers have had to build an entire platform to build new software, including the kernel, the distribution and more. And all of that software would need to get (re)built anew every single time something changed. Everything had to be checked in. Everything had to be rolled out. There was a version control infrastructure team, a CI team, a QA team—and they all had to work together and be aligned to meet the production schedule.

    This approach to developing was incredibly slow, costly and clumsy and in no way architected for today’s world of connected devices, IoT and the edge. Consumer product makers (home appliances, for example) simply don’t have the resources to provide frequent updates. Additionally, consumers are not used to frequent updates on consumer devices that are not their phones or laptops. With the rise of modern applications, it is just no longer acceptable to build static software that is never changed or updated.

    With billions of devices connected to an always-on network, large-scale security vulnerabilities have never been a bigger concern or consideration among companies that have millions of nodes on a network. Today, companies need to be continuously connected to all of their nodes and devices to properly maintain and secure them.

    Enter DevOps and Embedded Innovation

    DevOps has already transformed the way cloud-native applications are developed. Software gets built often, but it also gets deployed often. That’s why web apps are constantly being upgraded. Now, embedded is poised to take advantage of this software version control system that automates software builds and that is reproducible. Bringing DevOps to the embedded software ecosystem is about providing a set of tools or a platform that does the version control, CI and CD all in a single package—a platform to simplify the workflows for companies that typically have to build all of this themselves now can deliver opportunities for tremendous efficiencies and innovation.

    Consider the airline industry as it was 60+ years ago. At that time, the airlines built their own planes from start to finish. Today, Boeing and Airbus build all airlines’ planes. Of course, each airline can customize their fleet from the overall flying experience to the interior branding, but everybody is leveraging the same core technology because airframes are really hard to build and the differentiation happens on top of that foundation.

    Similarly, embedded software developers can focus on the customization of their product, not the time-consuming build that provides no differentiation. This is the concept behind the cultural shift we see in embedded software: Buy the airframe and customize it rather than build it yourself. Also inherent in the DevOps model is a distributed development practice, where different team members in different roles can be anywhere in the world and still work together seamlessly.

    The pandemic certainly created more demand for this model, but distributed teams aren’t going away and are more prevalent than ever in technology development. Many embedded software developers are still working in the same way they were in the 1980s and 1990s. With DevOps practices and platforms in place today, embedded software developers can focus on the value-add of their application. By taking all the complexity out of building it yourself, companies today can simply leverage easily consumable and reusable tools to achieve what cloud developers have been doing for years.

  • Why the Built World Needs Standard APIs

    Why the Built World Needs Standard APIs

    Lately, new ESG initiatives have come front-and-center as companies seek to contextualize and limit their business’s impact on the environment. This is especially true for the built world—a term that refers to the human-made environment that provides the setting for human activity, including homes, buildings, zoning, streets, sidewalks, open spaces, transportation options and more—where monitoring energy efficiencies is becoming more commonplace and even required by law. For example, a New York City law now requires buildings of a certain size to post an energy-efficiency score at their entrances. Yet, calculating such a score isn’t that straightforward—there’s a lot of legacy technology in use within most large commercial and residential buildings, and pulling data from these systems is notoriously difficult.

    A building manager may seek greater visibility into these systems to not only determine a building’s energy score, but to program optimizations, inform building security or enact new digitization. But the answer isn’t to hastily rip out and upgrade old hardware—old equipment like AC units and elevators were built to last 50 years or more and could be functioning seamlessly. Instead, this is another area where REST APIs are set to accelerate by uniting legacy integration software and disparate hardware with a standard layer.

    I recently met with Shaun Cooley, CEO and founder of Mapped. According to Cooley, API-driven standards for built environments could open up transparency into hardware component behaviors and the interrelationships between systems within a building. Below, we’ll briefly consider the history of building protocols and look to standards like Brick Schema that aim to unite legacy and modern physical infrastructure. We’ll consider the competitive advantage APIs bring to the built world and how increasing data accessibility could assist operations.

    The State of Physical Building Digital Protocols

    The built world consists of various digital communications standards. Most buildings have many older on-premises protocols for lighting, HVAC, elevators and other systems. For example, many elevators and fire safety systems were installed by systems integrators in the 1970s and adopted connections using Modbus, a communication protocol based on serial connections. BACnet is also commonly used to control HVAC systems and is a step forward from Modbus in that it can more easily connect to IP networks.

    Fast-forward a few decades to the dawn of the cloud; many companies overlaid sensors onto these old systems, explained Cooley. These power-over-ethernet (PoE) or battery-powered systems relay data immediately to the cloud and often speak in proprietary protocols. A single commercial building could easily be juggling a bundle of these various communication protocols, all originating from installations that occurred at different time periods. These nuances mean that you are “constantly dealing with chaos across your portfolio,” Cooley said. There’s so much data, but getting it normalized and usable is very challenging, he said. One must integrate with many sensors and protocols, which he describes as “the dirty plumbing” that no one wants to build.

    There’s bound to be differentiation from building to building, too, which could place a further strain on managing multiple building operations. Without a window into building data, it isn’t easy to know things like the current occupancy of the lobby or how occupancy affects energy consumption. Unless managers can connect the dots between systems, it’s impossible to understand the relationships between components.

    Making a Data Graph for a Building

    For example, take an AC system in a commercial building. Such a unit isn’t as simple as a single-family home’s typical thermostat and furnace. It’s often a mix of a rooftop chilling unit, pipes, pumps and a VAV damper that controls the air. While protocols are good at describing how individual components are performing, the composition of components is really what defines a building’s system and its efficiency, said Cooley.

    According to Cooley, instead of adopting a vertical data schema, buildings require a graph data model to adequately represent hardware interconnections. This is why he’s rallying behind Brick Schema, an open source uniform metadata schema for buildings. Instead of a vertical data schema, Brick Schema is built on a graph data model, which enables more descriptive relationships in a system.

    End Benefits

    Pulling unstructured data from 20 different data lakes into a clean API could allow easier access to new solutions. “We want to make it very simple to build applications for these sorts of environments,” said Cooley. Typically, system integrators must reverse engineer and connect to legacy building hardware, which can become very expensive very quickly, he said. He recommended using a sandbox based on open standards that can easily be rolled out to any building to reduce those hurdles. A more consumable layer with common endpoints could increase developer usability when creating innovative building applications.

    Similar to how Twilio made SMS easy, Cooley said he hopes for a similar proliferation in the built world. Many applications could be built with such an abstraction layer. For example, managers could better understand energy usage to reduce consumption, meet regulations and save money. Or, such an abstraction layer could inform predictive maintenance to create automated alerts before failures occur. There are also plenty of ways to improve occupant experience or intelligently optimize the lighting and temperature in a space.

    “Entirely new business models and concepts emerge that we hadn’t considered previously,” said Cooley. For example, he described a “tailgating app” that uses Brick Schema for a security use case. The app prevents building occupants from letting other people “tailgate” into the building behind them after someone swipes their badge. To do so, the app interfaces with many separate building systems (the elevator system, surveillance system, telepresence systems and other sensors) to ensure the number of people in the building matches the number of occupants that swiped in. A lingua franca helps to connect the disparate hardware involved.

    The Future of Building Automation

    This is by no means the first attempt to standardize building data. For example, the Green Button Initiative provides a standard API through which to download utility use data for electricity, gas and water and share it with solution providers. However, according to Cooley, this information only goes so far. Building owners will require more contextual data on-site.

    For example, perhaps a building’s window glazing is causing specific rooms to overheat in the sunlight. Thermal sensors would spot this condition, but bulk energy consumption readings wouldn’t ascertain the root cause. Access to real-time granular data such as current occupancy count is also necessary for developing on-site applications that better refine exactly how human involvement impacts energy consumption.

    Of course, as building systems become more intelligent, there is the growing possibility of privacy infringement. For example, systems that use facial monitoring and recognition could end up storing personally identifiable information. In that case, you “need to give data owners the control to decide what applications can’t or can’t access PII,” said Cooley.

    While this field has many read-only applications, Cooley predicts future write operations will enable more automation with building hardware. This could allow applying ML/AI to anticipate elevator floor calls. Or, a predictive system could cool a room only when a meeting is scheduled. When such data is readily accessible and available for developers, it presents many innovative opportunities to optimize and interact with the built world.

  • IoT Developers: Get Familiar With LoRaWAN for 2022

    IoT Developers: Get Familiar With LoRaWAN for 2022

    IoT Analytics forecast the global number of connected IoT devices would grow to 12.3 billion active endpoints in 2021. That number is expected to grow exponentially in the near future as more and more industries make use of long-range wireless capability. For example, president Biden’s infrastructure plan promised major investment in smart cities and smart municipalities across the United States. 2022 will also see IoT growth in the manufacturing and utility sectors as ‘brownfield industries’ look to update their existing machinery for Industry 4.0. Both of these factors will bring about a massive surge in demand for low power wide area network (LPWAN) solutions using the long range wide area network (LoRaWAN) standard next year.

    LoRaWAN is the standard protocol for LoRa wireless technology. LoRa was built specifically for long range use cases (it’s in the name). This means that technology using LoRaWAN requires significantly fewer repeaters and gateways to cover a large area, like a city, than would be required using traditional technologies. Additionally, LoRa is robust in how it responds to interference, and LoRaWAN sensors use less energy than other sensors, making them more efficient. In fact, ABI Research forecast that, by 2026, LoRa will be the leading non-cellular LPWAN technology.

    In the grand scheme of IoT, LPWAN technology is relatively new. LoRaWAN became an open standard just six years ago when the LoRa Alliance was formed in 2015. This means the main challenge for IoT developers in 2022 and beyond will be educating themselves on the technologies needed to put LoRa-enabled plans into action. There are two big reasons why you should begin that process now: The rising demand for smart cities and Industry 4.0.

    Building Cities Smarter

    When it comes to infrastructure, roads and bridges might come to mind first, but in reality, infrastructure is much more holistic. Utilities like electricity, gas and telecommunications should all be included in any infrastructure discussion. These industries have already come to rely on IoT technologies to collect data and function in the modern world. 

    The government IoT endpoint electronics and communications market is expected to reach $21.3 billion in spending in 2022, according to projections by Gartner. As governments continue to modernize and implement more wireless technology, I expect a good amount of this money to go toward the development of solutions using LoRaWAN to create flexible networks on a very large scale for smart cities. 

    In fact, this movement has already begun. In September, the city of San Jose, California, announced its partnership with a blockchain-based provider to extend the city’s broadband access. In exchange, the city is now hosting and expanding its peer-to-peer IoT network infrastructure.

    Updating Brownfield Industries for Industry 4.0

    2022 will also see IoT advancements in ‘brownfield’ industries. These are industries with legacy, stand-alone machines and processes, such as in the manufacturing and utilities sectors, that weren’t originally created with internet connectivity in mind. Players in brownfield industries already have large install bases of machines that have no way of reporting status or other pertinent data.

    These industries have long been looking at developing IoT solutions to solve this issue. Most are prototyping now with the goal of getting data to flow between large, legacy manufacturing machines with the end goal of improving manufacturing processes. However, unlike other industries where modern updates are often needed to improve efficiency, these manufacturers aren’t going to replace equipment that already gets the job done and has done so for decades. Instead, they need to find an alternate way to gather data and insights from the equipment they already have in place. 

    For many, LoRa-enabled sensors will be the answer. Often, upgrading to new technology requires equipment be substantially changed. That isn’t the case with LoRaWAN solutions, which allow manufacturers to add LoRa-enabled sensors to existing machines. LoRa-enabled sensors are durable, don’t require much maintenance and have low battery footprints. They also allow manufacturers to keep their data on-premises and on their own internal networks, a common preference for these types of industries. These characteristics make LoRa-enabled sensors ideal for manufacturing purposes. 

    In the new year, we will continue to see more pilot deployments go into production to help these industries gather the data they need to improve their processes and, in return, their bottom lines.

    LoRaWAN Resources for Developers

    The intention of the Biden administration’s high-tech infrastructure plans in the United States and the benefits of LPWAN (and LoRaWAN in particular) for private, long-range networks are converging to present a lot of great opportunities for this technology this year. That’s why 2022 will be the year IoT developers need to brush up on their knowledge of LoRaWAN.

    If you are interested in learning more about LoRa, check out the LoRa Alliance or LoRa Developer Portal communities to get started.

  • Why Trust and Integrity Are Critical to IoT

    Why Trust and Integrity Are Critical to IoT

    We hear a lot about how the IoT is transforming people’s work and daily lives, but for me, its impact goes deeper. As a Type I diabetic, I depend on data from an IoT device to stay healthy. If I can’t trust my latest blood sugar reading, the results can be catastrophic. Health care use cases like mine represent some of the many examples that underscore the importance of data integrity. Stacey Higgenbotham expressed it perfectly in a recent post: “If a business or consumers can’t trust the data, the IoT fails.”

    The IoT is all about making better, more informed decisions, and data is the foundation that makes those decisions possible. As the IoT gains maturity, we’re seeing its impact across more and more industries and use cases. 

    In agriculture, smart sensors are in widespread use for real-time crop monitoring to help farmers track the state of their products. Tools like motion detectors, light detectors and moisture sensors can be brought together to support predictive analysis and enable smarter, more automated decisions. IoT sensors are also tracking the location and health of livestock to help farmers detect disease outbreaks and isolate animals if needed. 

    Most of us have seen how the IoT has revolutionized the safety and efficiency of the home, providing unprecedented control over appliances, heating and cooling systems, smart metering and lighting. Security cameras, alarm systems and smart locks are strengthening physical security and bringing residents peace of mind. As these smart home systems mature, they are also becoming increasingly integrated, personalized and automated.

    The global pandemic is also helping shape IoT adoption. Forrester predicts that manufacturers, pharmaceutical firms and utilities are increasingly switching to remote experts and technicians for support. To manage and repair their assets without extended downtime and costly travel, these industries have begun connecting previously disconnected machines.

    What do these diverse use cases have in common? Without trusted data from connected sensors and devices, all of them become vulnerable and the decisions they support become questionable. Inaccurate moisture data from a sensor could cause a farmer’s crops to fail. A compromised smart lock could leave a home vulnerable to theft. In a manufacturing environment, inaccurate telemetry from a connected machine could lead to factory floor shutdowns or damaged assets. The positive business outcomes enabled by the IoT all hinge on working with accurate, timely and trusted data.

    Signing Is Key to Strengthening IoT Data Integrity

    Establishing data trust should be top of mind for IoT device manufacturers, and it is imperative that they take steps to ensure that data is not being manipulated in transit or at rest. This protection applies not only to data packets exchanged by the devices and applications but firmware updates and supply chain processes.

    The recent executive order signed by president Biden underscores the need for measures like code signing. Focused on improving the nation’s cybersecurity, the EO presented guidelines and general best practices for federal departments, agencies and contractors. However, its impact is also likely to extend to technology and infrastructure companies. 

    Some of the strongest direction in the EO is intended to improve the security of software as well as supply chains for technology manufacturers. The order establishes baseline security standards for the development of software sold to the government, including requirements for improved visibility into that software and making security data publicly available. The order acknowledges that too many devices and software releases contain vulnerabilities that bad actors could exploit. 

    Effective Code Signing Requires Strong Management 

    Fortunately, a proven solution is available today to help manufacturers ensure data authenticity, confidentiality and trust for their IoT solutions. Best practices like code signing can help manufacturers bake security into each and every stage of their development processes. By applying digital signatures, organizations can assume full control of their development. They can confirm the integrity of their code before it moves further along in the development cycle and is put out in the field for devices and their customers. 

    Code signing is only as effective as the processes and best practices that support its implementation. To make the most of digital signatures, developers and engineers need a holistic approach to management. The signing process should be seamlessly built into their development processes to simplify and ease adoption. 

    A common management platform should enable manufacturers to fully protect private key usage and signatures, as well as monitor and manage access to digital keys. The process should also enable organizations to support granular monitoring of their code signing processes and include historical tools like reporting and auditing for full accountability and compliance. With a process in place to continually sign firmware, software updates and other components that can ensure data integrity in device interactions, manufacturers can be assured that their IoT solutions will work as intended, using data their end customers can trust. 

    There’s no question that as the IoT continues to extend deeper into our business and personal lives, the importance of data integrity is also rising. The stakes will only increase as more systems, processes and life-or-death decisions rely on trusted IoT data. To sustain the soaring growth of IoT use cases and solutions, it’s up to manufacturers to build security into the supply chain. With a strong data foundation underpinning today’s rapid innovation, the potential of the IoT revolution is limitless.

  • What Developers Need to Know About Edge Computing

    What Developers Need to Know About Edge Computing

    More and more companies are living “on the edge” as they move from “I’ll think about edge computing” to “I don’t think our business can optimally grow and compete without edge computing.” Developers will play a key role in helping organizations use the edge, but their effectiveness will depend on having edge-aligned processes, products and people in place.

    Edge computing takes place near the physical location of either the user or a data source. It’s one way that organizations can use and distribute a common pool of resources across multiple locations. The edge model provides users with faster, more reliable services while expanding the potential of hybrid cloud computing for organizations. Customers and businesses alike will benefit from the way in which edge computing optimizes the use and application of artificial intelligence and machine learning by running data-intensive applications closer to the data source.

    While it is in many ways a question of architecture, applications are key to effectively exploiting the edge. Here are some of the things developers—and their organizations—need to know.

    Edge computing and cloud computing are not mutually exclusive. The best solutions will leverage both platforms. For example, centralized computing might be used for storage and compute-intensive workloads, while edge computing would be used to exploit data at the source, in near-real-time. Infrastructure and company culture need to be in place to support this, but developers must be thinking in terms of building applications that can cross and bridge computing platforms.

    Consistent tooling is essential. Developing for legacy IoT was very specific and required specialized tools and skills. The modern edge, in contrast, is part of a technology continuum, and developers need tools that they can use across that continuum, including:

    • Provider/enterprise core: The “non-edge” tiers, owned and operated by public cloud providers, telco service providers or large enterprises.
    • Service provider edge: Tiers are located between the core or regional data centers and the last mile access.
    • End user premises edge: Tiers on the end-user side of the last mile access can include the enterprise or the consumer edge.
    • Device edge: Standalone (non-clustered) systems that directly connect sensors/actuators via non-internet protocols. This represents the far edge of the network.

    Containerization enables flexibility, scale: Linux container technology wasn’t built for the edge, but the model fits perfectly with edge requirements for modularity, segregation and immutability. 

    Keep an “open” mind. Open APIs open up new opportunities. Developers using open APIs can access real-time data programmatically, making it possible to build applications that can leverage data as it’s “born.” Likewise, a focus on open source development tools and platforms will help to ensure that organizations can continue to leverage the edge as the model evolves. 

    What’s different is the devices. Developing for the edge is just like developing for any other platform–except that developers must write consistent and secure code that can be seamlessly copied to all device types. 

    Edge computing may not start with developers, but developers will play a huge role in organizations’ ability to leverage the edge. A focus on flexibility, openness and the future will help ensure that developers build applications that fully exploit and expand the edge advantage. 

  • Closing the Education Gap for IoT Developers

    Closing the Education Gap for IoT Developers

    The most common thing I hear from developers who are building internet of things (IoT) solutions is: It isn’t easy. And it’s not. Not because of a lack of skill—the developers I interact with are incredibly talented. There’s also no shortage of technologies to choose from for deploying an IoT solution. The challenge often comes down to a gap in available educational materials and learning support when in the development phase.

    We’ve moved from the early stages of the IoT when there was a lot of talk but not a lot of application. Now, we’re coming into the “reality phase” where cheaper, large-scale IoT solutions are feasible. In this phase, developers are tasked with identifying, building and deploying technologies that they’re likely having to figure out as they go. It’s a tall order to expect today’s developers to know the ins and outs of all of the moving pieces required for an IoT solution, including the wireless technologies that help to enable them. 

    While developers are renowned for being effective at independent learning, they still need better access to educational resources and tools when it comes to IoT technologies. This is especially true for newer technologies that you won’t yet find in a textbook or college course. 

    One example of this newer IoT technology is low-power, wide area networks (LPWAN)—specifically using the LoRaWAN standard. It’s an area that I not only expect to become increasingly relevant for IoT developers but also one that can greatly benefit from more robust educational resources. 

    IoT Development Is Relatively New 

    Modern LPWAN technologies have only been around for the past decade, and LoRaWAN became an open standard when the LoRa Alliance was formed in 2015. In the grand scheme of things, that’s pretty new. It’s not a concept that’s widely included in higher education curricula and, although we see more inclusion each year, it can be difficult for developers to find peers who have experience in building with LoRa devices. 

    ABI Research forecasts that by 2026, LoRa will be the leading non-cellular LPWAN technology. This means that over the next five years more and more developers will need to understand the basics of LoRaWAN but may not have foundational knowledge or experience to draw from. 

    From what I’ve seen, that gap can lead to teams biting off more than they can chew. Without enough training or support, developers risk building LoRaWAN deployments that may have inadequate coverage or go over scope or budget or that simply don’t live up to their vision.

    Complexity in Developing With IoT

    The other major reason IoT technologies operating with LoRaWAN need more robust educational support is due to their complexity. Developing an IoT solution requires several different skillsets that well-equipped teams either have to account for in their staffing or—as happens in many cases—rely on a single developer to figure it out and wear many hats.

    There are many aspects to building and deploying a LoRaWAN solution; for instance: Hardware engineering, device stack choice and application fit, gateway deployments and networking coverage, cloud considerations and application development involved for deployment. That’s a lot of moving parts.

    So, if enterprises and IoT vendors are expecting developers to make large-scale IoT deployments a reality, we have to provide the proper resources and training.

    Resources and Communities for LoRa Developers

    As the industry works on ways to better educate developers about LoRa technology, there are some good places to start for developers who want to hit the ground running. Here are some resources where you can learn the basics, build prototypes, get advice from other developers and test and certify solutions. 

    • LoRa Developer Portal—A hub where IoT developers can learn, connect with peers and accelerate their builds with resources like tutorials, dev kits and a free network server. Helpful for every level of expertise, from learning the basics of LoRaWAN to creating a network to rolling out a full-scale commercial solution.
    • LoRa Alliance—A nonprofit association where members collaborate and share experiences working with the LoRaWAN standard. They offers events, webinars, a resource hub and more. 
    • LoRa Basics Station —A GitHub Repository for the open source software that runs on gateways operating with the LoRaWAN standard.
    • AWS IoT Core for LoRaWAN—A guide for AWS IoT developers, spanning coverage development and deployment from connecting gateways to monitoring and logging. 
    • Azure IoT Hub—Guide for connecting the ChirpStack open source network server using LoRaWAN to the Azure IoT Hub.

    I expect higher education institutions to begin further integrating LoRaWAN into their curricula over the next several years, which will help to fill the education gap for the next wave of developers. At the same time, IoT vendors can step up and provide additional support to developers who are learning how to build with technologies like LoRa for the first time. This is critical for the success of large-scale deployments that all of us IoT believers hope to see across enterprise environments, cities, regions and beyond.

  • JFrog Acquires Upswift to Push DevOps to the Edge

    JFrog Acquires Upswift to Push DevOps to the Edge

    JFrog today revealed it has acquired Upswift as part of an effort to extend its DevOps reach to edge computing platforms. Terms of the acquisition were not disclosed.

    Upswift has created agent software that is deployed as a binary file on an edge computing platform that makes it possible to continuously deliver software across a fleet of edge computing devices and platforms. That approach makes it possible for organizations to deploy software regardless of whether the target platform is only running Linux, containers or a virtual machine.

    JFrog CEO Shlomi Ben Haim said the agent software developed by Upswift will be integrated with the continuous integration/continuous delivery (CI/CD) platform created by JFrog to make it easier for organizations to manage the full life cycle of application workloads deployed on edge computing platforms.

    JFrog Upswift

    Organizations that deploy software on edge computing platforms and devices today typically have massive backlogs of updates that they are unable to deploy in a timely manner, said Ben Haim. By connecting the Upswift agent software to a (CI/CD) platform designed from the ground up to support binaries, it becomes possible to reduce that backlog as part of what JFrog describes as its ‘liquid vision’ for deploying software, he noted.

    In addition, after acquiring Vdoo to gain access to a set of analytics tools that discover vulnerabilities in application binaries, JFrog will also be able to bring DevSecOps best practices to edge computing applications as well, noted Ben Haim.

    The number of application workloads being deployed on edge computing platforms is rising sharply as organizations seek to process and analyze data closer to the point where it is being created and consumed. In fact, that shift is at the core of digital business transformation initiatives that depend on edge computing platforms and devices running, for example, internet of things (IoT) applications to process data in near-real-time.

    Upswift CEO Amit Ezer said it has already become apparent that the existing processes of updating software on edge computing platforms and devices are capable of handling that influx of software. Upswift created its tool to enable developers to assume more control over those processes, as responsibility for managing and securing software continues to shift left, he added. The issue in many cases is that organizations lack the ability to consistently deploy software on edge computing platforms, which results in a hodgepodge of homegrown tools being created to deploy software on edge computing platforms using largely manual processes.

    It’s too early to say just how much software will be deployed on the edge, but there may come a day when there is more software at the edge than there is in the cloud. Of course, the real challenge will be unifying the management of DevOps processes, regardless of where any given piece of software might be deployed. In fact, as edge computing continues to evolve, the line between edge computing and cloud computing will continue to blur until they are little more than natural extensions of each other.

  • Engineering Applications for DevOps (Part 5)

    Engineering Applications for DevOps (Part 5)

    This blog series explains how to engineer applications for DevOps.

    Topics covered in this blog series:

    • Factors to decide whether an application is a good candidate for DevOps.
    • Practices to engineer designs for DevOps.
    • DevOps applied to enterprise apps and software services.
    • DevOps applied to COTS systems.
    • DevOps applied to manufactured (embedded) systems software.
    • Five levels of application maturity.

    This blog covers DevOps applied to manufactured (embedded) systems software. You can read part one here, part two here, part three here and part four here.

    DevOps Applied to Manufactured (Embedded) Systems Software

    In the late 1970s (yes, forty years ago!) as a young engineer, I was given an assignment to figure out how to accelerate the software development and delivery cycles for an innovative packet switch called SL-10, (predecessor to the more recent model called Data Packet Node [DPN]) manufactured by Northern Telecom. Each SL-10 “node” consisted of millions of lines of original embedded software source code and custom hardware configured with many interconnected processors and protocols interfacing with other nodes, host devices, and terminal devices.

    Given the complexity of the system and lack of automated build, test and deployment tools, it was taking more than twelve months to generate each release of the system, and there typically were lots of bugs even after the release. Without knowing much about DevOps (the word “DevOps” was not invented for another twenty-nine years), we proceeded to implement a continuous delivery system that included automated build, test and delivery tools and workflows.

    The result was remarkable. Lead times for releases to manufacturing were reduced more than tenfold, from twelve months to one month, and quality, measured as defects found by customers per release, also reduced tenfold. This dramatic shift in performance and capabilities made it possible for the engineering and manufacturing teams to accelerate the rate of innovation and trample the competition. The SL-10 product, and its rebranded DPN version, quickly dominated the connection-oriented packet switch market, and it became the pride of the Nortel corporation and the Canadian nation. Even cooler, I got a nifty president’s pin and promotion which paved the way for my career that led to writing a book and this series of blogs! If this real-life example is not sufficient to demonstrate that DevOps can be applied to manufactured embedded software products, then I don’t know what is.

    There have been many other examples published that show how DevOps practices applied to embedded manufactured systems have reaped similar benefits. A notable example was published in 2013 by Gary Gruver in A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware.

    That is not to say that DevOps applied to manufactured software embedded systems is the same as applying DevOps to enterprise applications or COTS systems. A paper published on the CloudBees blog, Five Aspects that Make Continuous Delivery for Embedded Different, explained some of the key DevOps practices used with embedded systems.

    DevOps Benefits for Embedded Systems

    Benefits of DevOps for embedded systems are summarized as follows:

    • Retrofitting the huge code base typically found in legacy embedded software systems into a DevOps model is not easy. It is likely to be expensive, but it is almost guaranteed to be a worthwhile effort, especially if you have a longer-term vision and intend for your product to stay competitive in the future.
    • Developers of embedded software need access to massive amounts of computer resources for testing their real-time embedded code on powerful hardware simulators.
    • Developers and testers need access to physical product hardware to run their binaries for system tests that cannot be run on simulators alone. Lab-as-a-service (LaaS) systems that orchestrate testing topologies of real devices can improve sharing of critical resources. LaaS systems provide a test framework that can be integrated through APIs into a continuous delivery pipeline.
    • Long build and test processes may need to be reengineered to reduce serialized lead times into quicker build times made possible by scaling build and test resources.
    • Long compliance and conformance test processes for embedded systems need to be accelerated with automation and resource scaling.
    • Focus on continuous delivery rather than continuous deployments in which shippable product versions are frequently delivered to manufacturing for verification, but the frequency of deployments to end customers is determined by other business factors.

    What This Means

    This blog is one of a series explaining how to engineer applications to be most suitable for DevOps. This blog series explains how to engineer applications for DevOps including:

    • Factors to decide whether an application is a good candidate for DevOps.
    • Practices to engineer designs for DevOps.
    • DevOps applied to enterprise apps and software services.
    • DevOps applied to COTS systems.
    • DevOps applied to manufactured (embedded) systems software.
    • Five levels of application maturity.

    This blog covers DevOps applied to manufactured (embedded) systems software. You can read part one here, part two here, part three here and part four here.

    For more information regarding how to engineer applications for DevOps refer to my book Engineering DevOps.

  • Thread is the Future of Wireless Mesh

    Thread is the Future of Wireless Mesh

    Over the last decade or so, interest in IoT technology and connecting devices to one another, and to the internet, has increased. Of course, one of the key elements necessary to connect devices is wireless communication. There are several wireless interfaces, such as cellular, Wi-Fi, Bluetooth, ZigBee, LoRa etc., that are prominently used in different industries to make these connections. However, choosing the right wireless technology is vital for the success of any product. One should consider several factors before zeroing in on the right wireless technology for your goals. Some of the factors to consider include:

    • Wireless range/ coverage
    • Throughput
    • Power consumption
    • Scalability
    • Security
    • Ease of provisioning

    Selecting the right technology to get the best results and satisfy all your requirements is a challenge, and what’s “right” may vary depending on use case. For instance, cellular technology is often preferred for a mobile device used in logistics applications, as it has excellent coverage. However, cellular technology is power-hungry; it would be difficult for the battery-powered device to operate for long periods of time. Similarly, LoRa, with a wide wireless range and low power consumption, is an excellent choice for applications such as smart metering. But it has a relatively low data throughput, and therefore may not be the ideal choice for certain industrial applications.

    What is Thread?

    One of the recent entrants to the wireless communication space is Thread. Thread is an IPv6-based, low-power, open source, mesh networking protocol for connected devices, backed by Nest Labs (a subsidiary of Google) and other industry bigwigs. Like ZigBee, it uses IEEE 802.15.4 wireless mesh protocol, but, being internet protocol (IP)-based means a Thread network can seamlessly connect to the internet without needing a translator or a gateway in between. Thread operates on the 2.4GHz ISM radio band, the same as ZigBee, and offers a throughput of 250 kbits/s with a typical range of about 30 meters. It employs spread-spectrum techniques to provide immunity to interference. Thread’s low power consumption means that a coin cell could power it for almost two years.

    Thread as a Mesh Network

    As a mesh network, Thread can have several hundred devices communicating with each other and the cloud. A typical Thread network would consist of an endpoint device, router node and a border router. A typical endpoint would be a battery-powered device that communicates with a parent router. A router node would receive packets from devices on the network and forward them to the rest of the network. The border router is a device that facilitates communication between a Thread network and a non-Thread network, such as Wi-Fi or Ethernet, by forwarding packets.

    Benefits of Thread

    Because Thread is a self-healing mesh network, it offers many benefits. One is avoidance of a single point of failure. That is, if any router in the network fails, another router automatically takes its place. Unlike ZigBee, for example, Thread devices can be linked to multiple border routers, making the network more reliable. Another advantage is that, being mesh, the Thread network is highly scalable. Each Thread network can scale to hundreds of devices. Thread also benefits from being built on IPv6 to take advantage of end-to-end routing and addressability. Any two IPv6 endpoints, whether on the same Thread mesh or across networks, can communicate, end-to-end, with easy and well-understood internet routing mechanisms moving packets from one endpoint to the other.

    One of the biggest benefits of Thread is that it can provide a high level of security. Security breaches associated with IoT and connected devices are on the rise, and are a major barrier to legacy device connectivity. All devices in a Thread network are automatically authenticated and communication is encrypted. Thread networks use a secure, financial-class encryption and the technology has plugged the obvious security loopholes found in other wireless protocols.

    An IoT device should be easy to deploy in the field, which is another factor in selecting the right wireless technology. Thread devices can be easily set up using a smartphone or a tablet. Users can securely connect devices to each other, and to the cloud, for easy control and access from anywhere.

    Thread is built on 6LoWPAN, which is the same radio protocols as that of ZigBee; an IEEE 802.15.4-based specification for high-level communication used to create personal area networks with digital radios. It’s possible that, with just a software upgrade, an existing ZigBee module can be converted to a Thread module. For legacy ZigBee users, it would be relatively easy to migrate to Thread technology. Availability of OpenThread, an open-source implementation of Thread, is likely to accelerate the development of products that leverage Thread. However, the limited availability of off-the-shelf border routers, and the use of less preferred mesh topology, is a challenge for its adoption into IoT devices.

    The Future of Service Mesh

    Thread has great potential, and can be considered a very good alternative to existing wireless communications options with the added benefit of Wi-Fi-like features. Because it’s open source and backed by large semiconductor manufacturers and technology heavyweights, Thread technology is poised to gain substantial momentum over the next few years. It may eventually emerge as the primary choice for medium throughput, low power IoT applications.