Systems Engineer
AnsibleFest Day Two was, if possible, even more amazing than Day One. Here’s my recap but be forewarned that you will have some to-dos after reading this blog!
Living (and Automating) on the Edge
The first big announcement came in the form of “Edge” computing. The point was made that Edge computing isn’t new. It’s been around for some time now and has had different names from Point of Sale (POS) to ROBO. Generally, the Edge is something outside of the Data Center and, these days, outside of “the cloud”.
The difference in today’s world is that the number of and types of devices in the Edge has greatly expanded, both in type and number. What was once called “pervasive computing” has led to computers in just about anything that you can imagine. Edge can include IoT, you might recognize that as a sensor, actuator, or small appliance. Some common edge use-cases might be found on a factory floor, vessels at sea and even the International Space Station!
As just one example, Ansible has been developed around the idea that you’ll usually access devices through one of three ways: SSH, RESTful API, or winrm if you’re using a Windows device. Then when you’re executing your code, the de facto standard is for the modules and plugins to be written in either Python or PowerShell. But, in some of these Far Edge environments that’s just not the case. Moreover, they don’t necessarily allow connectivity outside of their network.
During the presentation, we were told about some upstream collections being developed for lifecycle management in some of these disconnected environments, using an immutable OS technology called “OSTree”. This will allow users to take advantage of Ansible execution nodes to manage the complete lifecycle of these edge devices.
Beyond that, we also heard about devices that do not use the typical protocols. Red Hat revealed that they’ve been working with a customer (who is now a partner on an upstream project) who uses Common Industrial Protocol (CIP). As you can imagine by the name, this isn’t something that’s really used in the wider IT space. It’s just used in industrial settings and is being used, in this project, to automate Programmable Logic Controllers, which is an entirely new class of device for the Ansible world.
With EDA, Ansible can, quite literally, be used to automate any device over any native protocol. (We’ll talk about EDA in the next section.) There’s additional code that would need to be written for each new protocol, of course. But thanks to the way that Ansible was rearchitected in the Ansible Automation Platform 2.0 release (2.3 should be released soon, possibly November), this is absolutely a reality.
This means that if you have been looking at Automation as something that just happens around your core systems, you’re going to need to take another look at how Automation can, and will, change your entire business even out to the furthest systems.
Event-Driven-Ansible
Ansible, as we have known and loved it, is great. You create a playbook and you run it to get your managed nodes into the desired state. There are even great ways that people have used CI/CD pipelines to automate the automation. But one of the big announcements on Day Two was about Event-Driven-Ansible (EDA).
As the information streams in, Ansible will have “Rulebooks” that specify the source of the stream and then what rules will be followed in response. And, as with Ansible Playbooks, you don’t need to be a programmer to understand what you’re reading. You just need to be able to read English.
You did read that correctly. You can find the lab to give it a shot right here: GitHub – ansible/event-driven-ansible
Project Wisdom!
As exciting as EDA is, Project Wisdom is probably the development that made the deepest impression on me. When I got into the room and went to the front row, I asked the ushers if the front row was reserved (the previous day there had been some seats reserved for analysts, which is pretty normal). I was told, to my surprise, that there were six seats reserved for IBM Research.
I’m going to digress a bit here and express my admiration for IBM Research which most people primarily know from Watson playing Jeopardy. And that Watson Jeopardy series was pretty cool. But IBM Research really goes well beyond that. They are a legitimate R&D group with a level of pure science.
You would assume that most R&D done by a large corporation would be geared towards applied sciences that will drive product. So much of what we hear about science today is what research will or won’t lead to. However, scientific research in its pure form is really about figuring out how things work. And sometimes, but not always, this leads to great products. But what it always accomplishes is the expansion of our collective knowledgebase and that is something that, as an engineer and the husband of a biologist (and the father of a smart 8 year old daughter), I have hold the greatest admiration.
I’ve had some interactions with IBM research in the past – 20 years ago I was on a Redbook project in Almaden Research Center. Around the same time, I had a mentor working with researchers on a project that they called ice-cube (Lego-like locking servers and storage). Years later I heard a great presentation from IBM Research where I learned that they have a 3D printer in Almaden that prints out magnetic tape, one layer of molecules at a time, and on which they would manually position six iron atoms to represent a bit. All of that was great. But that brings us to Wednesday morning at AnsibleFest and Project Wisdom.
We had an incredible presentation from Dr. Ruchir Puri – Chief Scientist on Project Wisdom and IBM Fellow. And he went into a great discussion about software, and automation, and the concept of Computers programming Computers. (Do not worry about computers taking over the world even if they can program themselves. He also showed us how much energy is required to run the cluster that runs Project Wisdom and then pointed out that the human brain is much smaller and runs on sandwiches… so we’re safe for now.) I cannot begin to express how fascinating this is, and I encourage you to watch the demonstration (given by Matt Jones) that was shown during his presentation.
He made the point that many of the people who would benefit most from automation, lack the skills to take advantage of it. And, yes, Ansible is easy to work with. But let they among us who have not had to figure out the correct module or collection, or who haven’t been completely waylaid from a line starting in the wrong column cast the first stone!
IBM research worked closely with the Ansible community to develop this project. It doesn’t try to be a “Jack of All Trades and Master of None”. It just tries to be really good at programming Ansible.
It looks at the “– name:“ for each task and is able to create syntactically correct and functional roles and tasks. It was truly amazing to watch the demonstration.
The impact of this could be massive, because if you can define what it is that you want to do, there’s a good chance that Project Wisdom (integrated into Microsoft Visual Studio Code) will give you the correct code and you’ll only have to make minor changes. If we want to really automate the entire world, then this is an incredible start.
But, as with Event-Driven-Ansible, I want to make sure that you are aware of your part in this. Project Wisdom needs interested parties to get involved as part of the community. So, if you go to the website, you can volunteer to try it out and maybe even break it! Please consider signing up for it as it has incredible potential!
Summary
Automation at the Edge, EDA, and Project Wisdom were certainly highlights of AnsibleFest Day Two. For a recap of AnsibleFest Day One, check out my “Recap – The Culture of Automation” blog.
To explore how Ansible could be used in your environment, please reach out to me or to your Account Executive or
contact us here.
You may be interested in:
BLOG: Red Hat AnsibleFest 2022 – Recap – The Culture of Automation (Day One)
Video: Red Hat Ansible Automation Platform 2.x (10:13)