Monthly Archives

January 2018

Running EdgeX Foundry on Kubernetes

By | Blog, EdgeX Foundry

Guest blog post by Rohit P Sardesai, System Architect, Huawei Technologies India Pvt Ltd.

Why Kubernetes for Edge?

An edge computing platform comprises of many management and application services deployed on tens of thousands of edge-gateways managing millions of devices. Ensuring reliability and scalability of these services at such a large scale can be ensured by a platform like Kubernetes which orchestrates containers in a scalable and highly available way.

Kubernetes Pods and Deployments

Pods are the smallest deployable units of computing that can be created and managed in Kubernetes. A pod is a group of one or more containers logically co-located to share the same network, volumes etc.

A Deployment is a controller which manages pods and ensures the desired number of pods are always running.

An EdgeX core-metadata deployment yaml could be defined as below:

Figure 1. Metadata-deployment.yaml

 

The spec defines the containers to run, docker image to use, and ports to expose.

Kubernetes volumes

A Kubernetes volume is just a directory to store some data. To use a volume, a pod specifies what volumes to provide and where to mount those into containers. In Fig 1 above, volumes and volumeMounts are specified for the mongodb data, logs, and consul-config and consul-data directories.

Kubernetes Services

A Kubernetes Service is acts an intermediary for pods to talk to each other, providing features like load balancer and service-discovery. It routes the requests to backing pods based on matching labels.

Figure 2: EdgeX Services Communication

 

An EdgeX core-metadata Service yaml could be described as below:

Figure 3: Metadata-service.yaml

 

The config-seed service in EdgeX currently provides service discovery for all other services. Kubernetes Services serve the same purpose, so we don’t need to run the config-seed service in Kubernetes.

All other EdgeX micro-services have a dependency on the config-seed service which can be removed by setting the setting spring.consul.enabled to false in bootstrap.properties and rebuilding the docker image.

Figure 4: Disable consul dependency

Setting up a single node Kubernetes cluster

kubeadm tool can be used to setup a single node Kubernetes cluster :  https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/

Kubernetes supports different pod network add-ons implementing the Container Network Interface (CNI). I used Weave as the pod network add-on.

If using weave, make sure you start kubeadm with the correct pod-network-cidr range:

$kubeadm init –pod-network-cidr=10.244.0.0/16

Next, install the Weave pod network:

$kubectl apply -f “https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d ‘\n’)”

Creating Services and Deployments

Create Service objects for all the EdgeX micro-services using the kubectl command line tool.

$kubectl create –f <service.yaml>

Next, create the Deployment objects for all the services.

$kubectl create –f <deployment.yaml>

The order of creation of the deployment objects is similar to the Docker Compose approach. The only difference being we don’t bring up the volume and config-seed services.

Deployment and Service yamls and scripts to create the EdgeX Services and Deployments can be found here: https://github.com/rohitsardesai83/edgex-on-kubernetes

Figure 5: Project structure

 

The scripts in the hack folder can be used to bring up/down the EdgeX services.

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

EdgeX F2F TSC Meeting and the evolution of the EdgeX Cadence

By | Blog, EdgeX Foundry

Written by Dell’s Jim White, EdgeX Foundry TSC Member and Chair of Core Services Working Group

Last week (Jan 16-18), the EdgeX Foundry Technical Steering Committee (TSC) had our 4th face-to-face meeting in Orlando.  Our previous meetings were held in Boston (June), London (July) and Barcelona (October).

All of the EdgeX project business is conduct in an open fashion, so we invite anyone with input and something to contribute to join us in our face to face meetings.  To that end, while we had 10 TSC members in attendance, we also 14 non-TSC members attend, with another dozen joining at some point during the week by conference call.  The EdgeX technical community is certainly alive and well!

Our meeting topics were far and wide, but the central themes were focused on:

  1. The work tasks and duties around getting the California Release out (scheduled for June 2018)
  2. Architectural issues that need addressing for the California Release and beyond

California Release Planned

The California Release will include the first EdgeX security and system management features.  There is much work to be done, but the committee agreed on the implementation of these first elements toward offering a more secure and better managed EdgeX platform by June:

  • An open source reverse proxy will be selected and integrated in to EdgeX to protect against unauthorized access of the micro service REST APIs.
  • An open source authentication/authorization service will be incorporated in to EdgeX and be used by the reverse proxy, but other elements of EdgeX in the future.
  • An open source data protection service will be integrated in to EdgeX to provide key management, certificate services, and encryption capability – which can and will be used by several elements of EdgeX.
  • Each micro service will be outfitted with a system management API that allows it to set the service’s administrative state, stop the service, or get/set its configuration among other operations.
  • A system management micro service (call the system management agent) will facilitate 3rd party requests (eventually in a system management API of choice like OMA LwM2M, SNMP, etc.) while also performing more broad operations such as restarting all micro services.

Architectural Resolutions

As with any software system, there are a number of architecture issues which need to be addressed – or on occasion readdressed – as the platform evolves.  With EdgeX, we are learning that face-to-face meetings are a great place to tackle the architectural decisions where brainstorming, whiteboarding, and extended conversations over lunch/dinner/drinks can really help to resolve issues that don’t fit in our weekly working group conference calls.

The architectural topics discussed and resolved during our meeting last week include:

  • EdgeX will officially support one main “reference implementation” of any micro service at a time going forward. With Go Lang micro services being created to help reduce the footprint, startup time, and performance associated to some of our Java micro services, the question was raised as to what happens to the Java micro services once the Go Lang replacements are ready?  We decided that going forward, the community would have one main implementation of each micro service, but if others in the community were willing to help maintain/support other implementations, they could be retained as “alternate” implementations – otherwise they would be archived.  EdgeX remains committed to its polyglot tenet – that is, any micro service can be allowed to be created using any programming language of choice.  The reference implementation of each micro service will be the implementation that the community believes is the best implementation – regardless of language – while also meeting the API requirements and quality agreements for that service.
  • EdgeX is starting to receive some sizable contributions. How do we take on large code contributions from the community?  What’s the process for ingesting the code, making sure it fits the current architecture (or plan-fully rethink the current architecture if necessary), and meets quality levels expected of the project?  A new contribution process and tooling framework was designed by the community to deal with this need.  More information will be made available on the Wiki as this is drafted and formalized.
  • EdgeX uses Docker and Docker Compose for its deployment architecture today. What does EdgeX want to support in the future?  The community agreed to continue to use Docker and Docker Compose but also allow members of our community to present alternatives and ideas for additional solutions – like Kubernetes – in the near future.
  • With multiple Device Service SDK’s to be constructed in different languages over this release cycle, what elements of design should the different SDKs share and where can they be different? Our Device Services Working Group chairman is going to lead a requirements session followed by a design session in the coming months to bring some conclusions to this issue.

Other Significant Work

What else was covered in our face-to-face meeting?  Plenty!  You can see a deck of resolutions and action items here.

Additionally, if you want to see the agenda or listen to recordings of the meeting, you can also find them on our Wiki.

Other highlights include:

  • We resolved to make the California Preview available by Jan 31st. The Preview will include the Go Lang Core service replacements and demonstrate, dramatically, improvements in micro service footprint, memory and CPU usage, and start up times.  I’ll have another blog post in the near future to outline the performance improvements we are seeing with Go Lang.
  • In addition to security and system management, the California Release will include more complete blackbox testing as well as performance tests, native ARM testing, SDKs in C and Go Lang, and improved documentation
  • We revised and updated our roadmaps for the Delhi release (Oct 2018) and newly named Edinburgh Release (April 2019). Look soon to our project Wiki for details on these updates.
  • Plans were made to participate, formally as a community, with presentations/demos at Hannover Messe and IoT Solutions World Congress among other potential conferences this year.
  • We also resolved to meet again for our next face-to-face in June, right after the California release, to plan the Delhi release at a venue to be determined.

And We Had Fun!!!

Being a part of EdgeX has been a highlight to my career.  The community of experts that participate in EdgeX Foundry are just plain good people to be around.  There are some spirited discussions, but egos are always checked at the door in these meetings.

We always manage to get in at least one community dinner, and for this meeting, our dinner was at the top of the Orlando airport’s Hyatt hotel.  Plenty of good spirits and spectacular views to go around.

A number of our community planned to go to Cape Canaveral to see a rocket launch on the last evening.  Unfortunately, the launch was cancelled due to weather.  But this gave us all an appetite to one day see EdgeX in “SpaceX” and come back to see another launch.

EdgeX Foundry Member Spotlight: Kodaro, LLC

By | Blog, EdgeX Foundry

The EdgeX Foundry community is comprised of a diverse set of member companies that represent the IoT ecosystem. The Member Spotlight blog series highlights these members and how they are contributing to and leveraging open source solutions. Today, we sat down with Larry Andriunas, President of Kodaro, to discuss analytics, the EdgeX ecosystem and the role software plays in the Internet of Things. 

What does your company do and what is your your role?

Kodaro is a building software company primarily aimed at helping contractors and controls companies find value in building data from the edge to the cloud. We’re a company of engineers and computer programmers who believe building analytics should empower people to solve problems and make facilities more efficient. In addition to Analytics as a Service, analytics rules packages, and cloud hosting services, we make a variety of products to integrate and expand the capabilities of the Dell Edge Gateways for building systems. I’m the Founding President of Kodaro, overseeing the team as we unpack building data and turn it into actionable information for building controls managers.

Why is your company investing in the IoT ecosystem?

In a very short time the IoT has gone from something people whisper about to a keyword at the heart of countless analyst reports from here to Dubai. This has been driven by consumer-facing sectors like smart home devices and wearable technologies and we in the buildings industry are realizing it’s only a matter of time before all those people and all those devices impact the way we operate buildings. We’re investing in the IoT ecosystem because we believe that buildings of the future are connected and full of data that adds value, through energy savings, increased occupant comfort, equipment longevity and better connections.

How has IoT impacted your company? What benefits have you seen or what do you expect to achieve?

The IoT essentially is our company. Without a network of connected devices transmitting data within and between each other, we couldn’t do what we do. Some of our software facilitates the data transfer, others translate and analyze the data once it gets to where it needs to go. As building controls and integrators advance into this open and connected world we as a software company will be able to find, understand and act on more information about what’s happening in buildings than ever before.

Businesses currently have to invest a lot of time and energy into developing their own edge computing solutions. What are some of the business or technical challenges you have faced when adopting edge computing technologies? How have you overcome them?

As a software company in building automation, we’re often working between hardware and third-party applications. Each piece operates at opposite edges, and in many cases they use different languages or frameworks to conduct similar operations. So, much of our time and energy is spent bridging those gaps with software. One exciting example is our machine learning algorithms that automatically tag data so that it can be integrated into the building automation system more quickly and cost effectively.

Why did your company join EdgeX?

By creating an open source community, we believe EdgeX will attract the best minds to solve the most complex problems of the IoT. As a software company for the IoT, it was important that we part of the team that’s stitching it all together.

EdgeX Foundry Ecosystem

 

How are you going to use the framework?

We plan to deploy the EdgeX Framework from edge to cloud to create easier, faster connectivity so that we can better run data analytics in building systems.

Where do you see enterprise and industrial IoT in 20 years?

IoT is now compartmentalized into homes, buildings, industrials. In 20 years, I see seamless integration across verticals. Our lives will be integrated into buildings, buildings will be integrated into cities and so on. As the IoT advances, it will change how our lives are connected.

 

 

Learn How to Connect New Devices and Sensors Quickly with these EdgeX Device Service/Device Profile Tutorials

By | Blog, EdgeX Foundry

Written by Dell’s Jim White, EdgeX Foundry TSC Member and  Chair of Core Services Working Group

As you explore EdgeX Foundry, one of its strengths is its ability to bring on connectivity to new devices and sensors quickly.  This is facilitated by the device service SDK and device profiles.

Recently, Chad Young of Dell helped create some wonderful additions to the EdgeX tutorial set in these areas.  Chad create a collection of videos to give better examples of how to use the SDK to create a device service in a step by step video guide.  These videos can be found on the EdgeX Foundry YouTube channel: https://www.youtube.com/c/EdgeXFoundry. He also created a Wiki page in the EdgeX documentation that covers the same:  https://wiki.edgexfoundry.org/display/FA/Modbus+-+Adding+a+device+to+EdgeX.

For additional background, Tyler Cox also from the Dell team added more documentation about the device profile, providing more details and linked in references to examples (https://wiki.edgexfoundry.org/pages/viewpage.action?pageId=7602686).

Device services are the micro service connectors interacting with the devices or IoT objects that include, but are not limited to: appliances in your home, alarm systems, HVAC equipment, lighting, machines in any industry, irrigation systems, drones, traffic signals, automated transportation, and so forth.

The device services communicate with the devices, sensors, actuators, and other IoT “things” through protocols native to the IoT object. The DS Layer converts the data produced and communicated by the IoT object, into a common EdgeX Foundry data structure, and sends that converted data into the Core Services layer, and to other microservices in other layers of EdgeX Foundry.

As one might expect, the device service SDK helps developers create the device service micro services.  The SDK provides the boilerplate code – what we can the device service scaffolding – to which a developer can more quickly add the specific elements for communicating with a type of device/sensor and get it plugged into EdgeX.

Each specific device and sensor that is managed by EdgeX Foundry must be registered with Metadata and have a unique ID associated to it. Information, such as the device’s or sensor’s address is stored with that identifier. Each device and sensor is also associated to a device profile. This association enables Metadata to apply generic knowledge provided by the device profile to each device and sensor that is connected via the device service to EdgeX.

The additional tutorials and documentation were as a result of requests from the EdgeX community for more help.  We heard and continue to listen to community requests.  Please keep the feedback coming!

We hope the community will find these additions in the tutorials and documentation around the SDK and device profile helpful, and our thanks to Chad and Tyler for their great work.

EEJournal: Living On the Edge: EdgeX Defines an “Edge” Framework

By | EdgeX Foundry, In the News

Ah, words… Simple audio utterances that contain meaning. Well, except when they don’t. Or when each of us parses a different meaning out of a given collection of phonemes, making even morphemes morph.

In our world of technology, in particular, we deal with inordinately complex concepts, and we have to find shorthand ways of referring to them, or else we’d forever be locked up with convoluted phrases like, “a single binary unit of information” instead of “bit.” And, in most cases, for purposes of communicating in the English language, we borrow from the vast English lexicon (or occasionally from other languages, but English has a rather large vocabulary from which to choose). We take words that mean some specific mundane thing – like “bit” – and leverage them for some technical concept that evokes the simple meaning of the word.

Read more at EEJournal.

Automated Buildings: What’s Happening at the Edge of IT/OT Convergence

By | EdgeX Foundry, In the News

Technologies with the power to transform lives, industries, and societies almost always spring from the meeting of science and art. Author Walter Isaacson has documented how innovation happens at these crossroads in his biographies of Leonardo da Vinci, Benjamin Franklin, Albert Einstein and Steve Jobs. His book The Innovators is a compendium on the topic, offering highlights from the lives of other ‘hackers, geniuses and geeks’ that made the discoveries that have led us to today’s digital revolution. This moment in Tech feels particularly transformative in that the silo mentality that has kept various engineering disciplines apart and evolving along different lines is breaking down. Experts in enterprise computing, telecoms, embedded systems, automation & controls are all contributing their brain power to a common goal—realizing smart and connected systems, aka the Internet of Things (IoT).

Learn more at Automated Buildings.