Tag: IoT

  • Synopsys: IoT, ICS More Vulnerable to Security Exploits

    Synopsys: IoT, ICS More Vulnerable to Security Exploits

    A new report shows that internet of things (IoT) implementations and industrial control systems (ICS) are more vulnerable than most to potential zero-day exploits of the open-source protocols, common file formats and APIs they rely on. The report, prepared by vulnerability test firm, Synopsys Inc., is based on 4.8 billion fuzz tests conducted on the company’s customers throughout 2016. The report focuses on six key vertical areas: automotive, financial services, government, health care, ICS and IoT.

    To rank the vulnerability of different protocols, Synopsys measured the time it takes between the start of fuzz testing and when a protocol crash is recorded along with how many crashes occurred over longer periods of time. Newer, less mature or proprietary protocols proved to be the most vulnerable. In some cases, time to failure was measured in minutes or even seconds. Fuzz testing is a method of testing code for flaws and security vulnerabilities that involves throwing large amounts of malformed, random data at the system being tested.

    Industrial control systems are the most vulnerable of the six areas covered by the report. To a great degree that’s driven by the fact that ICS uses a lot of proprietary or ICS-specific protocols, some of which may not have been tested thoroughly enough. Three of the most vulnerable protocols are IEC-61850 MMS, IEC-104 SERVER and MODBUS PLC. The ICS protocol IEC-61850 MMS failed in just 6.6 seconds.

    IoT is the next most vulnerable system. It mixes older, better-tested core IP protocols with newer niche categories such as wireless and ICS. The three most vulnerable protocols for IoT are CoAP Server (failed in 8.5 seconds), CIP and OPC UA.

    It’s important for enterprises to prioritize security in their zeal to build IoT solutions. In some cases, Synopsys revealed that security vulnerabilities stemmed from an incomplete or improper implementation of protocols or unpatched code.

    “The applicability of IoT across all vertical markets and within enterprises of all shapes and sizes has brought us to an important inflection point,” said Brad Shimmin, service director for IT Technology and Software at GlobalData. “Thanks to ubiquitous and readily accessible APIs, development frameworks and even pre-built but extensible apps, virtually anyone can stand up an IoT deployment with very little experience in the way of application development practices. This will undoubtedly reveal the many dangers inherent in building highly distributed systems—dangers affecting both data and logic.”

    Some interesting data from the report: The overall average time to first failure of a protocol was 1.4 hours. When the time to first failure is measured in seconds instead of hours, it indicates a higher potential for criminal exploitation. The most vulnerable protocol tested was the previously mentioned IEC-61850 MMS; the least exploitable was the TLS client, which had an average time to first failure of 9 hours.

    Of the vertical areas the report classifies, the two least risky sets of protocols are the ones used by government and financial services. Synopsys attributes this to the more mature aspects of the categories of protocols used by these industries. They had fewer overall failures and longer test times to their first failure. It would take black hats a lot longer to fuzz them into vulnerability.

    — Scot Finnie

  • Cybersecurity Improvement Act of 2017:  The Ghost of Congress Past

    Cybersecurity Improvement Act of 2017: The Ghost of Congress Past

    It seems like yesterday when when Representative Ed Royce proposed legislation titled the “Cyber Supply Chain Management and Transparency Act.” Almost three years have passed since Congressman Royce introduced his bill in November 2014 and helped educate the world about serious security vulnerabilities (such as Apache Struts and Heartbleed) lurking inside open-source components that are commonly used by anyone and everyone building modern software applications.

    Broadly speaking, Royce’s bill would have required technology vendors selling software to the U.S. government to do the following:

    1. Provide customers with a bill of materials documenting all open-source components utilized in the software application;
    2. Demonstrate that the component versions utilized in the application have no known vulnerabilities (CVEs from NVD) for which less-vulnerable alternatives are available;
    3. Provide a mechanism to promptly remediate new vulnerabilities when they are discovered.

    Despite dying a quiet death, the Royce bill helped to pioneer an important conversation between government and industry leaders with respect to the age-old question of software liability.

    This conversation continues to evolve—and just recently Sen. Mark Warner, a Democrat in Virginia, and Sen. Cory Gardner, a Republican from Colorado, introduced the “Internet of Things Cybersecurity Improvement Act of 2017“—an attempt to force companies selling IoT devices to federal agencies to adhere to new security standards.

    Just like the Royce bill before it, the newly proposed legislation from Sen. Warner would require vendors selling IoT-connected devices to government customers to do three simple things:

    1. Provide written certification that IoT devices do not contain hardware, software or firmware components with any known security vulnerabilities or defects listed in the NVD or similar databases.
    2. Notify government customers of any new security vulnerabilities or defects subsequently discovered.
    3. Provide a mechanism that allows for any future security vulnerability or defect in any part of the software or firmware to be patched or fixed in a timely and secure manner.

    As Bruce Schneier observed more than a decade ago, there are no real consequences for having bad security or having low-quality software of any kind. Even worse, the market often rewards low quality. More precisely, it rewards additional features and timely release dates, even if they come at the expense of quality.

    Although the Royce bill failed and the future of the Warner bill is yet to be determined, there is an increasingly steady breeze blowing from Washington, D.C., that is gently nudging the entire software industry toward a future in which vendors will no longer be immune to liability for damages due to known security vulnerabilities or defects.

    About the Author / Matt Howard

    A proven executive and entrepreneur with over 20 years experience developing high-growth software companies, Mr. Howard leads Sonatype‘s corporate marketing, strategic partnering, and demand-generation initiatives. Prior to Sonatype, he co-founded, developed and successfully sold two software companies. Earlier in his career, Howard led sales and marketing at USinternetworking (acquired by AT&T) and Groove Networks (acquired by Microsoft), where his teams distributed workgroup collaboration products to enterprise customers. Howard holds a Bachelor of Arts degree from The George Washington University and a Master of Arts from George Mason University.

  • All Day DevOps: Taking Lambda to the Max

    All Day DevOps: Taking Lambda to the Max

    Lambda is the 11th letter of the Greek alphabet, and it is also the name of the Amazon Web Services (AWS) service that lets you run code without actually configuring a server. Amazon chose the name Lambda because—well, okay, I have no idea. Comment here if you know.

    Thankfully, you don’t need to know that to understand how to utilize Lambda. Matt Williams, DevOps Evangelist at Datadog (@technovangelist), outlined how to set up AWS Lambda at the 2016 All Day DevOps conference in his talk titled, “Hold the Infrastructure: Getting the Most Out of Lambda.”

    First, to understand what Lambda is, we must look at the evolution of servers.

    williams1.png

    We started with physical boxes—we had to buy and maintain these boxes, and no matter how much we used, we had to pay for all of it. We then evolved to multiple virtual machines on a physical server so that we could maximize the resources of physical boxes. Now, AWS and similar cloud services are common. We create a virtual machine that we need, and the service provider maintains the physical servers. We also have containers to keep environments identical across machines and, finally, we arrive at Lambda, which is service that runs code but doesn’t require you to set up the server. It takes care of all of that automatically, and you only pay for the time that the function is actually running. So, if your function takes 500ms to run, you pay for 500ms to run it once.

    Lambda is trigger-based. When it receives a trigger, it executes a specified function. The trigger can be a variety of actions with AWS services, such as when a file shows up on S3 or an Alexa skill is requested.

    Lambda is serverless, as far as you are concerned.

    Lambda is stateless. This means you can’t rely on local states, so, if you need to retain information between function calls, you have to save that data somewhere else.

    Lambda executes functions. Each function:

    • Is code in a container on LXC on AMZN Linux
    • Does not have restrictions on what it can do
    • Is priced based on exec time, quantity and memory

    Lambda links to various AWS services, such as:

    • Files (S3)
    • Database Updates (DynamoDB)
    • Streams (Kinesis)
    • Messages (SNS, SES)
    • IoT (Echo, API Gateway)

    Matt mentioned several good use cases, such as bootstrapping (the first 1M requests per month are free), cron jobs, file manipulation, API translation, social media stream processing, scaling infrastructure, mobile/IoT backends and Alexa skills, to name a few.

    He also mentioned three specific examples to explore:

    Matt then outlined how you can get started and noted that setup is simple as long as you think of application development as simple (write the code, set up on AWS, and debug). He walked through a specific example of automatically resizing images on S3 when they are added. You can watch his full presentation with screenshots here.

    Matt also provided a list of some AWS Lambda Tools:

    Matt rounded out his 30-minute presentation with a discussion regarding the need for monitoring and how to use Lambda for monitoring.

    You can watch Matt’s entire talk online here, where you can dig deeper into this subject. If you missed any of the other 30-minute presentations from All Day DevOps, they are easy to find and available free-of-charge here.  Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here.  This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed). It’s all free and online Oct. 24.

    — Derek E. Weeks

  • DevOps Chat: DevOps, Cognitive, IoT & Blockchain

    DevOps Chat: DevOps, Cognitive, IoT & Blockchain

    CJ Paul and Cliff UIn this DevOps Chat we sit down with Cliff Utstein, director of Offering Management, IBM Cloud DevOps and CJ Paul, distinguished engineer and chief architect, IBM Cloud DevOps. Cliff and CJ give us some insight into how some of the biggest trends in technology today—DevOps, cognitive, IoT  and blockchain—are connected. It is a great discussion with some of the people at IBM who are dealing with these subjects day in and day out.

    As usual, the streaming audio file is immediately below, with the written transcript of our conversation below that. Enjoy!

    Audio

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel of devopsy.kinsta.cloud and we’re here for another DevOps Chat. We have a really interesting DevOps Chat today and it’s regarding how DevOps kinda interacts and can help you get started with some of the leading sort of technology trends out there today and talking about things like cognitive and blockchain and IoT, etc. So a lot to cover in our 15-minute show, but we’re gonna do the best we can. I’m joined today by two friends from IBM. First of all, a returning guest to DevOps Chat, our friend CJ Paul, distinguished engineer and chief architect, IBM cloud. CJ, welcome to DevOps Chat.

    CJ Paul: Thank you, Alan. Glad to be here.

    Shimel: Thank you and welcome – glad to have you here. And, secondly, we have Cliff Utstein, and, Cliff, if I mispronounced your last name, I apologize, but Cliff joins us from Boston and he is the director of DevOps product development for IBM Bluemix and cloud. Cliff, welcome.

    Cliff Utstein: Thanks, Alan.

    Shimel: Did I mess up the title or the name?

    Utstein: I actually lead product management for IBM’s Bluemix – IBM’s cloud DevOps.

    Shimel: I apologize. So much for me for following the show notes. That’s what you get. [Chuckles] But, okay, fantastic. So, guys, you know, three big, kind of meaty topics out there—cognitive, blockchain, and IoT—and then how does DevOps help you get started with all of them. Let’s start with cognitive because, certainly, IBM is a market leader in cognitive and it seems like they’re building cognitive into everything. So let’s talk a little bit about that. CJ, I’ve probably spoken about this with you in the past, so, if you don’t mind, let’s start with you. How can DevOps help you get started with cognitive?

    Paul: Well, we find many customers evaluating several of these cognitive services that Watson provides. They are available as APIs in Bluemix, so this is – such as natural language understanding, natural language classifiers, the Watson conversation service, and many others like that. And many companies are looking at how to take advantage of those combination services to build interesting applications, like chatbots, that they can deploy for various use cases. So, as they look to build these applications, clearly, the way you build these applications is important.

    What DevOps proposes now is an iterative model where you rapidly take ideas and get them into code and deliver them out to market and see how effective they are. And then, you know, measure the usage and iterate rapidly from there, so using the DevOps practices and toolchains that we provide, it can greatly speed up a company’s ability, the developer’s ability, to build and deliver these leading-edge cognitive applications.


    — Alan Shimel

  • The Big Digital Transformation Trends Through 2017

    The Big Digital Transformation Trends Through 2017

    For a number of years now, the enterprise has been well underway in their digital transformation efforts, as they use data analytics, mobile, cloud services, IoT and other technologies to transform their organizations. But while some companies have embraced digital transformation, others have lagged. They’ll be playing catch-up in 2017, while their counterparts will be busy improving and accelerating processes where they can and building upon what has been achieved.

    Based on my interviews in recent months with CIOs, chief digital marketers and chief digital officers, here are a number of big trends in digital transformation that I see in the year ahead:

    Some CIOs continue to struggle to shake role as IT plumbers

    As enterprise digital transformation continues, even accelerates, those CIOs who focused on keeping the lights on through ensuring the infrastructure and services were in place to keep data available rather that on driving digital initiatives forward will continue to see their relevance diminish.

    Those who will lead forward with increased relevance will be the CIOs who focus on new ways for their organization to better support the business with the technologies they need to succeed and partner with the business units, rather than just provide the technological infrastructure for them to do it themselves.

    Business alignment with IT remains a challenge

    If you are a reader of devopsy.kinsta.cloud, you know alignment between the business and DevOps is crucial for enterprise success. In other words, IT leadership must deliver the technology the business actually needs and wants. Seems obvious and straightforward. And it is. It’s just proven to be a not very easy thing to accomplish.

    According to the Deloitte 2016 – 2017 Global CIO Survey, the “business expectations of IT and IT capabilities are out of sync in several areas, including customer focus, technology-enabled business growth, and business innovation. For example, even though 57 percent of the CIOs surveyed said that customers were their organization’s top business priority, less than half were involved in delivering customer experience (45 percent) or working on customer acquisition, retention and loyalty (44 percent).”

    That’s interesting enough. But the survey results got even more dismal: “Even though 78 percent of CIOs said that strategic alignment of IT activities with business strategy was critical to their success, only 5 percent said it was a leading-class capability in their IT organization.”

    CIOs that want to not only thrive but—at the very least—survive are going to need to close this alignment gap.

    Bimodal IT gains more traction

    The concept of bimodal IT is a controversial one. Essentially, bimodal IT is a descriptor from the research firm Gartner that remarks how IT organizations have a need for both agile delivery of technology services and traditional delivery modes. In the Gartner model, so-called Mode 2 teams are focused on DevOps and agile delivery methods, while Mode 1 teams focus on delivering the more established applications in traditional and more predictable ways. A brief explanation of these terms from Gartner is available here.

    Also, according to Gartner, nearly 40 percent of CIOs are currently practicing bimodal, with the majority of CIOs saying they will embrace bimodal sometime in the next three years. This signals to me that the proof of bimodal success is coming in and more enterprises will continue to follow.

    The trend toward Citizen Developers increases

    More enterprises in the year ahead will embrace the so-called citizen developer to provide some of the apps enterprises need. According to the QuickBase State of Citizen Development Report, 75 percent of those enterprises surveyed said that they develop more than three-fourths of the app and leave the “last mile” to the citizen developer. And, not surprisingly, most (65 percent) are building apps to get work done, while 42 percent build apps to run the business and 27 percent build apps targeting customers.

    “These citizen developers can go a long way to help clear the application backlog. Per the report, 29 percent have seen a 2X or more increase in application development speeds. Over three-quarters or 76 percent of respondents cited operational efficiencies as the primary reason for using the platform. And a whopping 62 percent of Citizen Developers responded that it takes less than two weeks for them to complete an application, on average,” QuickBase’s John Carione wrote in this blog.

    With increased demand for more mobile and web-based apps, and the ease with which many of these apps can be started using low-code and even no-code platforms, I fully expect more enterprises to find ways to encourage citizen development within their organizations.

    CMOs, others outside traditional IT, continue to drive more IT budget

    This trend has been underway for some time now, and I fully expect it to not just continue but accelerate. As was discussed in Sarah White’s story, “As CMOs Start to Outspend CIOs, Collaboration Remains Key,” “marketing has a growing influence on technology spending, with CMOs slated to spend more than CIOs by the year 2017. In fact, companies reported that 25 percent of their annual budget was spent on digital marketing efforts in 2014; and out of those companies, 51 percent plan to increase digital marketing budgets in 2015.”

    As that continues, that means marketing is going to have a larger say in what technology services and platforms get investment in the year ahead. CIOs in organizations where the chief marketing officer is getting more and more budget will need to partner to stay relevant.

    Digital transformation accelerates

    According to this Digital Transformation Survey, a surprising 70 percent of c-suite respondents believe they are ahead, or way ahead, of others in their digital transformation initiatives. Compare that to only 30 percent of those in the line-of-business and other employees who believe the same.

    For whatever reason, those in the c-suite are suffering from some form of cognitive disconnect when it comes to their digital transformation efforts. In the year ahead I think more c-level executives will see the reality of their digital transformation efforts and get to work on mobile and IoT and putting data analytics to better work.

    — George V. Hulme

  • DevOps Lessons from the Dyn Attack Fiasco

    DevOps Lessons from the Dyn Attack Fiasco

    Dyn’s DNS servers suffered a major DDoS attack last week, slowing a host of major websites. Does the drive for DevOps automation increase the risk of similar attacks? Maybe, but it doesn’t have to.

    As almost every geek knows by now, a DDoS attack on Oct. 21 overwhelmed Dyn’s DNS servers, and websites that depended on those servers slowed to a crawl. The attack was made possible because a large number of Internet of Things (IoT) devices were compromised using Mirai, a malware tool that breaks into devices using default access credentials.

    While it’s not yet clear exactly why so many IoT devices were configured with default login credentials, it’s likely that at least part of the reason included the following factors:

    • IoT devices are so numerous that securing them all is very difficult, especially when they are configured with weak security out of the box.
    • The need to give multiple users access to the devices encouraged installers and service providers to keep the default credentials in place. For example, if you have a smart thermostat that is installed by a contractor, managed by a utility company and owned by a homeowner, each of those parties could potentially need access to the device. Sticking with default login credentials is a lazy but effective means of providing it to all of them.

    In certain ways, the shift to DevOps makes challenges like these more common. Consider the following:

    • DevOps encourages the use of microservices. That means more services and logins to manage. It increases the risk that some services will not be secured properly because default login credentials will remain in place.
    • Under DevOps, the entire software delivery team is supposed to have access to all platforms and resources that are part of the delivery chain. That’s different from waterfall development, in which developers only had to be able to access developer tools; IT ops only needed to access management tools; and so on. The need for broader access could encourage teams to take the easy way out by using default logins—or even just sharing login information, which is risky even if the credentials are not the product defaults.

    A shorter way of saying this is that to increase agility, DevOps increases complexity. Greater complexity translates to more potential security risks.

    Conclusion

    The Dyn attack was not a DevOps problem, and none of the above means that securing a DevOps environment is not possible. It is, but it takes more work.

    Still, the Dyn outage is a reminder of just how badly things can go if developers and admins make mistakes such as relying on default login credentials. This challenge will become more difficult, not easier, as DevOps continues to reshape the way software is written and deployed.

    — Chris Tozzi

  • Fog Computing Meets Cloud Computing, and the Forecast Is Sunny

    Fog Computing Meets Cloud Computing, and the Forecast Is Sunny

    Fog computing is more than just cloud computing meeting edge networks, but for practitioners more interested in results than in new buzzwords, the question is whether fog’s IoT promise deliver real-time data storage, processing and analysis.

    One thing all new technologies share is the lack of a consensus on what exactly defines the technology. Ask some folks what “fog computing” is, and they’ll tell you it’s synonymous with edge networks. That’s the claim made in a July 29 post on Nanalyze, which traces fog computing concepts back to the days of mainframes and dumb terminals.

    On the contrary, ReadWrite’s Ryan Matthew Pierson explained in an August 5, 2016 article the many ways that fog computing is distinguished from edge networks. The primary distinction, according to Pierson, is that edge networks connect sensors to programmable automation controllers (PACs) for data storage and processing, while fog computing requires that the sensor data be transferred to local gateway at the end of the cloud “chain.”

    Pierson claims the fog computing model is more scalable than edge networks because each gateway has more power to “make more complex and dynamic decisions.” The gateway approach also accommodates a range of data at various flow rates. However, he said, this design creates more potential failure points.

    Fog Computing = Edge Networks + Analytics?

    As you might expect, there’s a third, middle-ground approach that defines fog computing as edge networks to which real-time analytics have been added at the node level. That’s how FogHorn Systems CEO David King explained the technology in a Sept. 13 article by CIO’s Stephen Lawson. FogHorn’s Lightning software platform is designed to deliver real-time analytics to IoT gateways, as well as to existing industrial products, including hard-wired controllers deeply embedded in equipment such as locomotives. Some of these embedded controllers are based on proprietary OSes that have been around for decades.

    The key feature of Lightning’s design, according to King, is its close ties to cloud servers, which ensures that the data collected at the edge of the network is available to analytics tools that reside in the cloud. CIO’s Lawson quoted Machina Research analyst Aapo Markkanen as stating that linking IoT data sources to cloud analytics is the only way to get the “big picture” view required to ensure accurate analyses.

    In an Aug. 19 interview with App Developer Magazine’s Richard Harris, King explains how fog computing addresses the shortcomings of previous distributed edge networks in terms of bandwidth use and the resulting “performance-killing application latency.” The FogHorn system is designed to move the “intelligence layer” closer to the machine data, resulting in faster and more cost-effective analysis. King claims the company’s software makes possible “real-time remote monitoring, asset optimization, proactive maintenance and operational intelligence applications.”

    data-management-middleware-for-fogedge-computing-iot-4-638

    Fog computing adds a new layer that connects mobile, IoT (sensors, embedded controllers), and vehicle control systems to the depth and breadth of data resources in the cloud. Source: SpinalCom via SlideShare

    Many of the features promised in fog computing systems—remote monitoring, asset optimization and proactive maintenance—are available today in best-in-class tools. You should be able to monitor SSH and Agent-based connectivity to apps running in private, public and hybrid clouds.

    Fog Computing Delivers Analytics for Time-Critical Applications

    The cloud’s centralized nature has never been a good match for the short response times required by data processing and analytics in IoT environments. Ben Dickson wrote in an Aug. 2 TechCrunch article that fog’s decentralized architecture moves the analysis tools and other resources closer to the edge, where the data is being collected and actions applied. Telemedicine, autonomous vehicle control and remote security systems are examples of time-critical applications requiring near-real-time analytics.

    Another advantage of maintaining data at the edge of a widely distributed network is the privacy and security benefits of keeping sensitive data off the internet, where it would be subject to strict privacy regulations. Dickson presented the “fog layer” of the network as offering the compute, storage and network resources required to “mimic cloud capabilities.” By ingesting data locally, you can analyze it and convert it into action almost instantly.

    09_22_16_fog_cloud3

    The complete IoT model extends from the data source (human or machine) to the data center in the cloud, with much analytics-driven decision making occurring in the “fog layer.” Source: Moor Insights & Strategies, via Forbes

    Dickson pointed out that the fog layer serves as a complement to cloud computing rather than as a replacement. In fact, fog computing couldn’t exist without all the data, tools and other resources now residing in the cloud. The larger data sets and deeper analyses being done in the cloud serve as the foundation for the fog layer’s quick-turnaround analytics. The fog’s capabilities are constantly being updated and enhanced based on the big-picture view the cloud affords.

    Fog Computing Standards Take Shape

    Today’s mobile networks simply can’t meet the needs of tomorrow’s data operations. Dropped connections, bandwidth bottlenecks and latency—the time it takes for data to travel from point to point on the network—are all too common. Upgrading the “infrastructure” at the edge of the network requires a concerted effort to ensure open access for diverse tools and resources—some of which we can’t even imagine, let alone prepare for.

    Princeton University’s Edge Lab is taking the lead in bringing together tech vendors, organizations and customers of all stripes to create the Open Fog Consortium, which is intended to design an architecture for fog computing. The official announcement of the group was announced at the Internet of Things World Forum in Dubai Dec. 6, 2015; John Sullivan reported on the announcement in a Dec. 16 post on the Princeton University blog.

    Open systems have proven their worth many times over, but an open architecture for IoT networks is even more important. Estimates are that by the end of 2018, there will be 22 billion connected devices generating an unending stream of unstructured and semistructured data, according to numbers from IDC research quoted by Forbes’ Gil Press in a Nov. 10, 2015 article.

    The flood of data would overwhelm the bandwidth and network capacity organizations currently have, as Jelani Harper explains in a March 10 article on Data Informed. Only an open, decentralized model that keeps the bulk of data and its supporting resources at the edge of the network will prevent a “datapocalypse.”

    09_22_16_fog_cloud2

    For many network requirements, cloud computing and fog computing complement each other. Source: Cisco Systems

    How much of a company’s data can be maintained in these edge-network nodes? Harper projects that as much as 90 percent of the data that will be collected by IoT devices will never reach the data center. Not only does this reduce strain on the network, it also speeds up “time to action” because analyses are performed where the data resides: on the edge.

    The advent of fog computing can be seen as an expansion of the cloud via the creation of a “fog layer” in which many data assets and resources are reallocated. That layer is where IoT’s incredible data reach meets the cloud’s infinitely scalable compute, storage and big data analytics. What is fog, after all, but cloud you can feel?

    — Brian Wheeler

  • Vivint Meets Smart Home IoT Challenges Using DevOps

    Vivint Meets Smart Home IoT Challenges Using DevOps

    Smart home technology vendor Vivint  serves more than 1 million U.S. and Canadian consumers with services including broadband internet, cloud storage, home automation products, home security services and energy automation controls.

    The company, which got its start in home security, leverages door and window sensors, motion detectors and glass-break sensors, as well as those that detect flood, heat, freezing, smoke and carbon monoxide in the home, said Nick Brown, director of Platform Architecture at Vivint. “We have a bunch of indoor and outdoor cameras such as doorbell cameras and the ping camera that is an interior camera supporting two-way audio.” For the smart home, Vivint extends automation devices, intelligent thermostats and Amazon Echo into the household.

    Vivint used DevOps to get the software platform behind these sensors and smart home devices up and running within a year. Vivint continues to use DevOps to meet the needs of its growing platform.

    Building a Software Platform for the Smart Home

    Vivint started its expansion from home security company to the largest smart home provider with a challenge of growing a platform that could serve a million customers. This was necessary to fold in the 700,000 home security customers it already had in with the 200,000 new smart home customers its leadership knew were coming in a matter of months.

    “We were building this new infrastructure from absolutely nothing and we needed to support 200,000 new installations in the first few months of operation,” Brown said. Vivint had its existing home security customers on a legacy platform supported by a third-party company; that company had a full 10 years to build out its infrastructure. Vivint had one year to bring those 700,000 existing customers into a new system and less time than that to prepare for the influx of new customers.

    Vivint accomplished its goal, serving more than 900,000 homes in the first 12 months.

    What DevOps Now Accomplishes for Vivint

    DevOps enables Vivint to manage stateful and historical data at scale, Brown said, which allows the company to power the biggest smart home platform in the world. Customers see everything that is going on in their house, including current and 45-day history of what happened, through a 7-inch control display.

    The real value the Vivint platform provides is in the integrated in-home experiences, which the company virtualizes and makes available anytime, anywhere around the world, giving customers a real-time view into their home data, he noted.

    To build, use and evolve this platform, Vivint uses MongoDB, RabbitMQ, Nginx, ELK (once the ELK stack, now the Elastic Stack), Salt and homegrown tools. Vivint applies its homegrown code to the task of guiding a communication protocol that enables the smart homes and the Vivint cloud to talk to each other.

    The company uses RabbitMQ, an Erlang language-based open-source message brokering tool that supports Advanced Message Queuing Protocol (AMQP) to disperse those messages in and out of its software platforms, driving them to and from Vivint’s services in its internal infrastructure. Vivint uses Nginx, a multifunction web server/reverse proxy server to serve web applications and services.

    Vivint runs an ELK stack, which consists of Elasticsearch, Logstash and Kibana for monitoring. Its ops team uses Salt, a Python-based configuration manager to manage everything. “We’re looking forward to adding Kubernetes as a new infrastructure solution to make this a little more modular,” Brown said.

    The DevOps Path to Modularity

    Vivint needs its software platforms to be as modular as possible. “Each piece of the infrastructure must support a modular paradigm. Because we are following a high-risk, urgent schedule, we need to make sure that any mistakes we make along the way are easy to tear out and replace,” Brown noted. Vivint uses virtually countless services to make this possible while pushing out weekly software releases.

    “From a DevOps perspective, we have a lot of things to manage here,” he said. Vivint uses AWS to support its infrastructure in the cloud and the company has its own private cloud as well. Vivint needs to move safely and quickly while retaining its agility and orchestrating all these different elements.

    To bring all the smart home technologies into the new system, Vivint chose MongoDB because its data models and code tend to naturally mesh with the data models in that database. “We took advantage of the flexible schema, and the document-oriented architecture of Mongo really allowed us to write very little data access code,” Brown said. This significantly cut back on implementation time.

  • Resin.io Secures $9 Million in Funding to Accelerate Growth of Next Generation IoT DevOps Platform

    DFJ, GE Ventures, Ericsson, and Aspect Ventures Make Strategic Investment in Emerging Start-Up to Modernize Deployment to Connected Devices

    SEATTLE, WA–(Marketwired – Jun 27, 2016) – Resin.io, provider of a modern DevOps management platform for connected devices, today announced that it has secured $9 million in funding from DFJ, GE Ventures, Ericsson, and Aspect Ventures. Resin.io was founded in 2013 with a mission to use linux containers and other open technologies to simplify the way developers build, deploy, and manage software for IoT devices. Since then, businesses across a range of vertical industries have adopted the resin.io platform to safely and iteratively deliver software over the air for security patches, new feature deployments and device configuration changes. The new round of funding will be used to expand the company’s product footprint, grow its open source community, and broaden its global reach through new strategic partnerships and channels.

    “As billions of complex devices come online, IoT project leaders are faced with the dual challenges of safety and speed. They must securely maintain mission-critical remote devices, while also delivering new software features and functionality to their customers,” said Alexandros Marinos, Founder & CEO of resin.io. “Resin.io is a modern software deployment and management platform that builds on Docker, Git, Yocto and other open technologies to solve these challenges. With the support of GE Ventures and Ericsson we are exceptionally well positioned to help IoT project leaders use software as a strategic advantage.”

    The management challenge for IoT devices is impacting companies across every major industry. Whether it’s a major retailer employing industrial lighting systems across hundreds of stores, a manufacturing firm struggling to keep track of expensive inventory in real-time, or the next generation of connected home devices that require frequent firmware updates, the massive scale and complexity of these connected devices is causing a slew of new problems for companies with wide-scale IoT deployments. With resin.io, device fleet owners can corral all of their connected devices into a unified console, enabling developers to iterate faster, securely push updates to hundreds or thousands devices at once, and gain ongoing visibility into the overall health of their device fleet.

    “Advancing the Industrial Internet requires the ability to deploy and manage software in remote environments,” said Sam Cates, Director at GE Ventures, a unit of General Electric Co. (NYSE: GE). “Resin.io is uniquely positioned to bring the speed and safety of DevOps to the Industrial Internet and we are excited to help them do so.”

    “In a world of end-point liberation, software becomes the means of innovation and where billions of connected devices perform increasingly complex tasks, traditional over the air (OTA) update approaches are simply not enough,” said Diomedes Kastanis, VP, and Head of Technology and Software Solutions for Ericsson. “We are thrilled to support resin.io as it helps transform entire industries with the ability to safely deploy new software containers whenever and wherever is necessary.”

    About Resin.io

    Resin.io brings modern DevOps tools and practices to the Internet of Things. Resin.io’s software deployment and management platform makes it simple to deploy, update, and maintain code running on Linux-based connected devices regardless of their location. With Resin.io, businesses and developers can jumpstart their IoT projects and applications quickly, slashing development time, cost and management overhead. Resin.io has offices in Seattle, Washington, London, England and Athens, Greece. For more information go to https://resin.io

    CONTACT INFORMATION

    • Press Contact for Resin.io
      Robert Nachbar
      Kismet Communications
      206-427-0389
      Email Contact
  • What Can Digital Transformation Do For You?

    What Can Digital Transformation Do For You?

    Contrary to what the massive articles around digital transformation suggest, your business lines’ primary concern isn’t the amazing technology innovations that pop up every day but how well they’re going to deal with your industry’s disruption. Something is sure, your IT organization’s digital transformation cannot be narrowed to technology changes; that’s a simplistic vision which ignores the disruptive impacts on businesses, particularly on the IT function.

    Howard King, writing in “What is Digital Transformation?” published in The Guardian, makes it clear, “Transformation is a whole scale change to the foundational components of a business: from its operating model to its infrastructure. What it sells, to whom and how it goes to market.” He’s right, the business-oriented vision of IT demands a transformation of your IT organization including its infrastructure, applications delivery approach and operating model, and DevOps increasingly is cited as the foundation of the new IT.

    This article shares my experience and lessons learned implementing DevOps as the foundation of digital IT organizations.

    Top Priority: Dealing with Your Industry Disruption

    The belief that implementing a continuous delivery infrastructure is all your business need to survive digital disruptions is a marketing hype DevOps practitioners have grown accustomed to. It’s a myth that prevents you from making informed digital transformation decisions. Emphasizing the technology at the expense of your industry’s disruption forces you to make technology change prematurely; your priority actually should be to figure out how to deal with the disruptions hitting your industry.

    Ask yourself this: What’s the interest in investing in scattered continuous delivery infrastructure implementations, when your favorite vendors and consultants aren’t able to clearly address these concerns:

    • How can you restructure your business value stream to make it lean and agile so that the right services are timely delivered to the right market segments?
    • How can you integrate DevOps, IT as a service, cloud, Internet of Things and big data into a coherent and consistent business capability so that the right services are timely delivered to the right market segments?
    • What’s the architecture of your future information system, including your virtual data center and application delivery infrastructure?
    • What will your role be as the CIO? How will the relationships with your business lines and vendors be managed?

    Make no mistake about it, these are your business line concerns of the moment. Unless you address them, Chef, Puppet, CodeDeploy or any other software application alone won’t help to keep up the pace imposed by Uber, Apple, Google and the like. You’ll need to bring together your business and IT staff in a lean and agile capability, which demands a re-engineering of your IT structure, processes, practices and governance.

    DevOps is the Foundation of Your Digital IT Organization

    Let’s remove the ambiguity: Infrastructure as code isn’t DevOps. The increasing confusion of DevOps with continuous delivery infrastructure is slowly but surely killing it—it’s even disqualifying it as a competitive advantage. That vision focused on tools has nothing to do with the logic underneath DevOps.

    As I’ve been making clients happy with it, DevOps is primarily an application delivery model that seeks to make businesses responsive to market opportunities through accelerating added-value applications delivery and with the goal of continuously generating value. It’s based on three principles helping businesses survive digital disruptions, then grow and prosper:

    • Using continuous delivering infrastructure to speed application delivery doesn’t make sense unless tangible business benefits are generated.
    • Applications are the means by which value is brought to customers and business benefits are brought in.
    • Agile principles across your software development life cycle makes your value stream lean and agile which in turn results in continuous value.
    DevOps Delivery Model - Philippe Abdoulaye
    DevOps Delivery Model – (Credit: Philippe Abdoulaye – ITaaS Now LLC)

    The delivery model uses three levers to implement the above principles and establish DevOps as the foundation of your digital IT, they include:

    • The rules of the game, which are agreed-upon principles, practices, roles and responsibilities and tools institutionalized to ensure agility and accelerated applications delivery;
    • The operating model, which is the lean and agile work environment resulting from the application of the rules of the game; and
    • The continuous delivery infrastructure, which is a platform that leverages infrastructure-as-code solutions to accelerate applications development and deployment.

    The Digital IT Organization: Approach, Principles, Tools

    Success in IT organization transformations often come more from a stream of small wins than from a one-time flood. That’s what I call incremental transformation, illustrated in the following digital five-stage transformation journey:

    The digital IT organization implementation process
    The transformation journey – (Credit: Philippe Abdoulaye – ITaaS Now LLC)

    The following recommendations definitely will make you instrumental to your IT transformation and help your business meet the digital economy’s competitive challenges.

    Strategize

    A CIO who’s expected to help business lines survive their industry’s disruption, grow and prosper first must clarify their business objectives; estimate potential gains, losses, and risks; and create a consensus on the DevOps delivery model to implement in terms of high-level architecture and implementation timing. That’s the purpose of the Strategize stage.

    Never skip this stage—it’s where the executive buy-in is obtained and the vision of the future IT capability is developed. Make sure the following is accomplished:

    • Creating an executive task force co-led by the CIO and a business representative;
    • Scheduling one to three workshops addressing your transformation business case, transformation road map, high-level blueprint of the future IT capability and the DevOps adoption plan;
    • Designating a project manager; and
    • Communication by task force members regarding the whys and wherefores of the transformation initiative.

    Plan

    Digital transformation involves many functions within your business in the form of a cross-functional team: the concerned business and IT staff. Your responsibility as the CIO is to bring the voice of the business across the transformation journey, from business objectives clarification, to design and implementation, to pilot experiment, to deployment.

    Again, do not overlook this stage—it’s about translating the effort into team structure, implementation schedules and operational and strategic reviews. It’s where the risks likely to hamper projected objectives are anticipated. Make sure workshops involving the business and IT are set up to address the following:

    • Team structure and roles and responsibilities;
    • Transformation road map steps translated into operational timelines associated along with expected outcomes; and
    • The project’s operational and strategic reviews, including a risk management plan.

    Design and Implementation

    The third stage is when the three dimensions of the digital IT organization are designed and implemented. They include the DevOps rules of the game, the operating model and the continuous delivery infrastructure.

    Never improvise this stage—use a proven approach to address the dimensions. Favor a collaborative approach that includes workshops or brainstorming sessions with the concerned business and IT staff.

    In the rules of the game brainstorming sessions, make sure the following is addressed:

    • Organization and operational dysfunctions preventing cross-functional collaboration, rapid problem-solving and decision-making;
    • Recommendations to the dysfunctions in terms of agile processes, practices, roles and responsibilities and tools;
    • Recommendations mapping to the appropriate DevOps principles, practices, roles and responsibilities and governance structure; and
    • The IT organization’s DevOps charter, thought to accelerate the rules of the game and the operating model adoption.

    In the continuous delivery infrastructure workshops make sure the following is addressed:

    • A delivery pipeline, including steps and for each of them what follows:
      • Required staff, skills and background
      • Implementation, testing and deployment agile processes and practices
      • Implementation, testing and deployment tools, such as Chef, Jenkins or CodePipeline

    Experiment

    For this stage, set up a pilot experiment involving, in a small-scale real-business setting, a panel of business and IT staff to evaluate the likelihood of the project benefits.

    Neither skip nor overlook that step, it’s where improvements are identified. Throughout the pilot project, make sure the following is in place:

    • Executive task force monitoring the pilot project through bi-weekly reviews;
    • Concerned business lines and IT business lines are involved;
    • Training campaigns are organized around the DevOps charter, the operating model and the continuous delivery infrastructure;
    • Strategic management tools, such as balanced scorecards to monitor progress, risks and achievements; and
    • Measurement of the impacts of the operating model and the continuous delivery infrastructure against the projected benefits.

    Deploy

    This final stage is a Go-No-Go milestone in which your task force, based on the pilot’s outcome, decides whether to deploy your digital IT capability at the scale of the company. Throughout the deployment:

    • Capitalize on the benefits generated by the pilot experiment to launch an information campaign emphasizing the benefits for the company and for the staff; and
    • Train business and IT staff on the DevOps charter, the operating model and the continuous delivery infrastructure.

    Wrapping up

    Today’s DevOps practices focused on continuous delivery infrastructure aren’t likely to help businesses grow and prosper in the digital economy. Thought leader Joe McKendrick in, “The road to digital bliss is paved with service thinking and DevOps,” confirms that fact.

    The approach discussed in this article are detailed in my recent book, written to help make IT leaders instrumental to their business digital transformation:

    Rethink Your IT with DevOps

    If you’re considering a DevOps-focused IT transformation, what will be your first steps? I’d love to hear your thoughts, let’s meet @TheFutureOfYourIT.