staging-devopsy.kinsta.cloud

Tag: software defined delivery

  • 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.

  • Software Delivery: Shaking Loose of a Local Optimum

    Software Delivery: Shaking Loose of a Local Optimum

    This is an article about software delivery, that magical or onerous field between pushing code to version control and using it in production. Why does software delivery matter? Because software matters, and because software developers matter. I don’t want my software delivery to get out of the way; I want it to make me a stronger developer.

    The path from code to production is crucial because it determines the length of our feedback loop and, therefore, our rate of improvement and that all-important lead time.

    Our current tools think of delivery as generic—they take control, and we fill in the blanks. They let us build, test, deploy. But these words mean something different for every application, on every team and within every business. And there’s a lot more that goes on, or can go on, between the writing and the running of code. There’s often linting, approving and coordinating. There’s data to think about and security policies, business team structure and auditing. There are other steps we don’t bother with, because there’s no slot for them: updating libraries, fixing the code to meet standards, taking a different set of steps for a documentation-only change.

    What else have we not thought of, because it doesn’t fit inside the current set of tools? I want to think about delivery from the top. In doing so, I can gain a greater understanding of my work.

    We’ve seen major shifts in Operations technology: containers, log aggregation, observability, programmable infrastructure and Kubernetes. In my opinion, the killer feature of Kubernetes is its API—it is controllable by automation. It accepts instructions and sends out events.

    The potential here is even bigger than we have realized, for operations and for delivery.

    Modern options for operations have achieved new levels of abstraction and potential. Yet progress in delivery has only been incremental.

    Our tools are very configurable, with plugins and scriptable bits, and we can always fall back to running shell scripts of unlimited length. But are we stuck in a local optimum? Are we thinking big enough?

    What We Have

    Today’s popular software delivery tools are fill-in-the-blank. This is great for getting started, when you don’t know what you’re doing. What about when your business grows, when your delivery is no longer cookie-cutter? Let’s look at two examples.

    Travis CI is a favorite of mine because it’s so easy to get going. It will happily build any public GitHub repository, on its infrastructure, for free. If my repository fits a few simple profiles, such as a Rails app that deploys to Heroku, poof! Some very simple YAML in your repository:

    I like that YAML. It is declarative. It contains data. It fills in the blanks that Travis provides. But the real measure of a tool comes when you get off the happy path. You can do just about anything in Travis; just call out to a shell script. Here’s a small piece of one of my .travis.yml files:

    It has shell commands. Shell syntax for an if-condition. And that infinity of flexibility, a call to a shell script. That travis-build.bash script happens to contain four functions, eight conditionals and (if I’m reading it correctly) up to seven program calls.

    This is programming, OK? As soon as your YAML calls out to a shell, it is not declarative. It is imperative. Or a mix. 😕

    This is programming, but my YAML and Bash do not qualify as software. Bash is a scripting language. It is designed to glue programs together, not to construct programs; it lacks composable modules with encapsulation. I can live without types, but in Bash you don’t even declare function parameters! And it’s full of pitfalls. Use Bash for what it’s good at: calling other programs. As a fallback for flexibility that we lack at a higher level, Bash does not shine.

    YAML is not a programming language, although it does support variables and has its share of pitfalls. Until the YAML contains commands that get executed; then it becomes a program, with even fewer options for error-handling or clear naming than in Bash. Please use YAML for data, not for code.

    There is a gulf between programming and software. We have standards for software: it has design—domain-driven design that we’ve worked through with experts. It has automated tests. It has modularity. It uses libraries and abstractions. I want to use a language designed for all this.

    Skip ahead to Jenkins. This is more widely used than Travis for more extensive delivery flows. It can run on-prem. There are hundreds of plugins available. So many blanks to fill! So many options! And now, there’s pipeline as code. For one thing, you can write a piece of Groovy to define which repositories and branches get a pipeline. That makes Jenkins more responsive to new repositories and branches. It’s a step in the direction of responding to new projects.

    The people building Jenkins recognize that delivery needs to be controlled by the people who control the code. Instead of constructing each repository’s build in a GUI (hello, TeamCity), we put a Jenkinsfile in each repository. That file is in Groovy. Groovy is a programming language with all the modularity and libraries of the JVM behind it. Except, you don’t get all that in your Jenkinsfile. You’re limited to what is available when Groovy runs within Jenkins. If you want consistency from one repository to another, you can install custom-shared libraries in Jenkins and call them in each Jenkinsfile. Rolling out change is challenging; any of those disparate Jenkinsfiles can break after the shared library changes. It’s pretty fragile and still limited. It’s progress.

    This is a step up as programming, but I still wouldn’t call it software. When I write an application, I work in more than a programming language; I work in a language system. A language system includes dependency management, frameworks, linters, build systems, editors, community and the whole ecosystem of libraries available in the language. Great language systems exist around the JVM, Node and .NET, for instance. Groovy that you run can participate in the JVM language system, but Groovy running within Jenkins does not have this access. The Jenkinsfile DSL is still fill-in-the-blank.

    What We Need

    Conceiving delivery as software invites us, development team members, to sit down with the local experts on our deployment environment and security and other concerns. It invites us to have a conversation: What does delivery mean for this application, on this team, in this organization? Where do we want consistency and variability? Then we can create and encode a model—a model of the domain of software delivery, within the context of our business and our environment. We can brainstorm events such as a push or a new repository and what we want to always happen. We can divide the parts into team-specific, organization-specific and community-wide (open source).

    Instead of, “How do run the build? How do we run tests?” we can ask, “What needs to happen after a code push?” And we can think carefully about how we work, how our software works and how our business works with it. We are the domain experts in our own delivery.

    This is the top reason I want delivery as software from the top down. By thinking about delivery as software, we think rigorously about our work as software developers. And we get better at it.

    I want more than delivery-with-some-code. I want delivery as software. Controlled top-down by my team, with a rich ecosystem of libraries, with frameworks and services for the parts that are common in the community. I want delivery that’s event-driven, that’s testable and that communicates with me when it’s time for a decision.

    We’ve come a long way since the days before automated deployment. Our existing continuous integration/continuous deployment solutions have served us as far as they can. Incrementally better (fill-in-the-blank) won’t take us to the next level of software delivery, and it won’t help us reach the next level as software developers. It’s time to break out of this local optimum.

    Let’s Go

    To this end, we composed the Software Defined Delivery Manifesto. Say what you want about manifestos: They have a certain flair, a certain impact, a certain dramatic longing for a better world. That is what we are expressing here. Yes, it’s a better world only for development teams, and only for development teams in complex organizations. But we matter! Software has a huge impact on the world, and to make that software better, we need to get better at delivering it. Let’s push past what we’re used to. Accept that our job is not writing code, but running useful software in production. Let’s get better at delivery by modeling it in software.

    If you’re in, join the movement. Sign the manifesto.

    — Jessica Kerr