EdgeX Foundry Architectural Tenets Spur Sustainable Open Source Ecosystem Development

[vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”20613″ alignment=”center” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]From the outside, open source projects may seem somewhat messy and chaotic with no obvious central leadership or reporting structure. But most successful open source projects actually have a great deal of structure and method behind their technical decision-making.

If you explore the Wiki pages of EdgeX Foundry, you will see several references to the project’s architectural “tenets”.  These are the principles that guide how the project’s contributors and technical steering committee decide what changes are accepted into the project, what features will be pursued, and ultimately what technology the group will advance together.

The tenets of EdgeX did not get established overnight.  They are not some sort of religious doctrine or commandments (although some of us would like to see them carved in stone someday). We didn’t blindly establish them because it fit within today’s software mantra.  

No, the EdgeX tenets have evolved from industry-wide collaboration that addresses the use cases and challenges of edge computing.  More specifically, they evolved through trial and practice in Project Fuse, which Dell started more than two years ago and donated to The Linux Foundation earlier this year to seed EdgeX Foundry.  These tenets represent the imbued lessons learned while building EdgeX Foundry, and they are the bedrock that will allow the EdgeX community and the commercial ecosystem around the project to continue to grow and thrive.  

If you are considering joining the EdgeX community as a developer, these tenets allow you continue to live those principles in your contributions, or work with the community to suggest other means to achieve the same results.

And if you aim to see widespread adoption of your own open source platform, you will find many of the same principles of openness, flexibility, and portability will apply.

I. EdgeX Foundry must be platform, protocol, and stack agnostic.

This first principle is key to attracting a diverse user base and developer community.

Dell built Fuse, which became the source code base for EdgeX, to support the software needs on our own gateway.  So why would we want to build a software platform that runs anywhere and can be created with any programming language or tool set? Simple – one size does not fit all edge/Internet of Things (IoT) needs. EdgeX must be agnostic with regard to hardware, operating system (Linux, Windows, etc.), distribution (allowing for the distribution of functionality through microservices at the edge, on a gateway, in the fog, on cloud, etc.), and protocols.

IoT solutions are being implemented with Raspberry Pi and Arduino as well as industrial grade hardware. These will often be distributed from cloud systems to the sensor edge (often referred to as the fog), where the platform choices expand even more.  [/vc_column_text][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”20625″ alignment=”center” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]An IoT architect should be concerned with “what runs best where?” based on use case and other requirements, instead of“will it even run there?” questions. – that defeats the interoperability concern that EdgeX Foundry is trying to address.  The nature of IoT / fog deployments is heterogeneous platforms not homogeneous platforms.

EdgeX also needs to be protocol agnostic. Today, IoT developers face a “protocol soup.” Legacy equipment isn’t going to go away anytime soon, and newer protocols like BLE and Zigbee are being used by more modern sensors/devices.  All of these devices and sensors, regardless of protocol, need to talk to each other.

EdgeX has to serve as the United Nations in the protocol soup – offering a universal translator to all the devices/sensors as well as the north side enterprise and cloud applications.

[/vc_column_text][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]When people ask “why doesn’t EdgeX just use X?” in communicating and representing edge data/commands, where X is their favorite protocol, format, or object model for IoT communications.  My answer is always the same…as soon as the entire edge/IoT/fog community has adopted X then EdgeX will adopt X as its only means to deal with and provide the sensor/device data and commands.  Until then, EdgeX will try to adopt X with community help as an option at the south, north or both edges, but it cannot only offer that.

EdgeX is even agnostic with regard to development environment/tools used to create microservices. Two things are accomplished by being inclusive and supportive of all development communities.  First, it allows existing solutions, new best-of-breed solutions and alternative solutions for certain use cases – embodied through microservices – to be incorporated into EdgeX with the lowest barrier of entry and without impacting the other parts of the system.  Second, it allows the EdgeX community to grow without requiring potential community members to learn and adopt a certain set of technologies that will most certainly change over time.

Our attitude with EdgeX must be BYOT – “bring your own technology” – and abide by the EdgeX API set.  It is the microservice APIs that serve as the thing we must agree on – not the technology stack.

II. EdgeX Foundry must be extremely flexible.  

This second principle allows rapid iteration and technology development. It also provides the basis for commercial interests to realize ROI (return on investment) which incentivizes them to contribute back to the project.

Any part of the platform may be upgraded, replaced or augmented by other microservices or software components.  It must allow services to scale up and down based on device capability and use case.  EdgeX Foundry should provide “reference implementation” services but encourages best-of-breed solutions.

EdgeX is essentially a Lego set of microservices.  It became very evident to those on the Dell Fuse Project that IoT solutions are going to be different for everyone.  Your analytics are not my analytics.  The connectors you need to your devices are not the connectors I need for my sensors.  How you log issues may not be how I log issues.  In his book Building the Internet of Things, Maciej Kranz states that no single company will be able to build and provide a complete IoT solution for your organization.  It’s too big.

We needed to build a system that allowed for the service to exist, but to be implemented or extended in unique ways for the use case or circumstances of the environment the system was used in.  As I have said to several people joining EdgeX – don’t look at the existing code as the crown jewel.  It is the flexible architecture that welcomes and adopts rapid change by having well defined APIs and a strong craving for interoperability that is the crown jewel.  Microservices are at the heart of trying to satisfy that craving.

Each EdgeX microservice must perform certain duties.  How it does the work may change based on use cases and other requirements.  Let’s face it, you have different resource capabilities when you are running on a cloud server versus running on a Raspberry Pi.  Microservices can be written to take advantage of the resources it has.  The analytics or rules engine microservice might be a simple if/then event processor on a smaller platform, but could be IBM Watson in much more expansive resource settings.  Logging services may persist the log entries for long term search, or an alternate logging implementation may use simple circular files in a file system to keep only the latest entries and reduce resource needs.

While building EdgeX, pesky business questions continued to emerge.  How do we pay for all this?  Where is the “ROI”?

We at Dell call the implementation of the EdgeX microservices provided in the community project today the “reference implementation” of the services.  They provide an implementation to be used by the community and users to get an understanding of what the service needs to do and how it fits into the broader system.

However, it is anticipated that over time, others in the community are going to build better implementations.  They may be faster, smaller, provide additional capability, etc.  These other implementations may address needs of specific use cases or needs of a specific vertical market.  These other implementations may be offered back into the community as open source editions or may be proprietary products where creators can get a return on its participation investment in EdgeX.

Going forward, I see a place for commercial value add – organizations that develop EdgeX replacement services that do more (or less with some intelligence to know when to apply each) for an EdgeX deployment based on cost and resource availability.  That which is “table stakes” and just providing the base platform will probably be part of the open source product.  But even table stake propositions will change over time as better technology, approaches, and process find better ways to tackle common and standard needs.  We need to allow for better reference implementations going forward – that is we need to accept the better mouse traps.

EdgeX is built on an Apache 2 license.  One way that ROI can be achieved through EdgeX is through the replacement services. EdgeX serves as a platform that enables interoperability and establishing a base platform while simultaneously offering growth of the ecosystem and emergence of better solutions.

The organizations participating in EdgeX are not in the project as an academic exercise.  We want to grow the IoT marketplace and generate more revenue.  EdgeX provides a base to start, but allows for commercial endeavors based on value add.

III. EdgeX Foundry must provide for store and forward capability (to support disconnected/remote edge systems).  

The next three principles are aimed at solving specific technical problems that the EdgeX project aims to address. But they also help to demonstrate the flexibility needed to grow user adoption and developer contributions.

Systems at the edge are going to operate in variable environments.  Continual connectivity to the enterprise and cloud cannot be taken for granted – in fact, in some environments, it is almost a guarantee that the systems will be disconnected for extended periods of time.  In transportation use cases, the shipping container or box car where EdgeX is deployed that moves across geographies will often drop in and out of connectivity.

Therefore, EdgeX must provide the means to be self-sufficient for extended periods – collecting its data and doing what it can to use local analytics/intelligence and actuation as needed until connectivity is re-established.  When reconnected, the data collected can then be pushed northward and any new instructions pushed southward.

Some IoT solutions emphasize “streaming.”  Streaming everything all the time is not supportive in many deployments.

IV. EdgeX must support and facilitate “intelligence” moving closer to the edge.

Have you priced the cost to ship all the data from the hundreds of sensors you are going to have to the cloud?  Have you priced out the size of the pipe you need to deliver that data to the cloud?  Once it gets to the cloud, have you priced out what it is going to cost to store all the data or comb through it to get the gems of intelligence from the data?  Early IoT solutions had suggested a “sensor-to-cloud” model. It became evident that this model was not often going to scale for many use cases given the volumes of data being produced.

At the edge, something has to do a better job of filtering the information – that is determining real news from what is just run of the mill readings.  A sensor that reports “it’s 72 degrees” every second isn’t typically important until it detects a significant change in temperature.  The platform at the edge has to have more intelligence in order to lower the cost to ship, store and munch through all that data.

In a similar fashion, what is the timeframe your systems have to read the data and make conclusions about how to act on that data?  In a car, there is but a millisecond or two to determine there is a crash and to actuate the airbag.  Do you want the system in your car to make a long-distance call to the cloud to ship the crash data, await a cloud process to determine what to do, and then have your car get a response call back to pop the airbag?

There are plenty of these types of edge use cases.  In fact, the leading premise within IoT circles is that intelligence moving closer to the edge is what will reduce costs and improve ROI (be it safety, cost, maintenance, etc.).  EdgeX was built to operate as close to edge as we can get it and to facilitate the southward tendency of intelligence – whatever level and sophistication of intelligence that may be.  And, per tenet III, it was made to operate independently and disconnected when/where it needs to as well.

V. EdgeX Foundry must support brown and green device/sensor field deployments.

It is said that IoT is the convergence of IT and OT – the convergence of the information technology community and the operational technology community.  IT moves pretty quickly.  If we don’t get a new laptop with new software every few years, we get frustrated at how “slow” things are moving.  Better productivity comes from better, stronger, faster tools.

In OT, the cycle of change works much more slowly.  Factory floors, once running smoothly, don’t like to make a lot of change.  Change is costly and prone to creating new issues which create more costs.  It’s a vicious cycle.  The argument can be made that in OT, better productivity comes by minimizing change once something works.

Some IoT solutions have suggested that we need to upgrade the old OT environments to better facilitate today’s connect-everything world.

In building EdgeX, we did not take that approach.  The life cycle within the IT and OT worlds was taken into account, which is why we created the device service layer and device service SDK.  EdgeX must support the communication with devices (and their associated protocol) across a wide spectrum – from the very old to today’s more modern sensors and protocols.  Modbus was invented in 1979.  It is still used heavily in industrial environments and PLCs.  OT knows it, relies on it in particularly noisy environments, and would be reluctant to replace it.  It’s not going anywhere.  There are many “Modbus” type protocols in the OT world.  Asking OT to move it or lose it is not an effective strategy if IoT is going to scale quickly.

We must be accepting of these old protocols, yet provide a path forward into new protocols when the time comes.  At the same time, we must support newer protocols and even those that are proprietary.  True interoperability is dealing with the full spectrum of devices and sensors not just those found in IT or OT worlds.

VI. EdgeX Foundry must be secure and easily managed.

And finally, anyone in IoT knows that one of the top concerns of organizations implementing IoT solutions (and open source technologies, in general) is security and management of the IoT solution.  We know that in order to succeed in the marketplace, these concerns must be addressed.  It’s a non-starter if EdgeX or any IoT platform cannot be trusted and well managed in today’s IT and OT environments.

Admittedly, this is the tenet EdgeX has the farthest to go to fulfill its mission.  We quickly realized that however we end up accomplishing this, it needs to be adopted by the community.  Community participation and influence are the only way to build this trust.

Conclusion

Hopefully, this post has helped you understand the tenets of EdgeX architecture, how we arrived at them, and how they will help us achieve our goals for the technology as the community and commercial ecosystem grow.

You may have other tenets you think we should adhere to.  You may have an opinion as to how we might want to adjust some that we are using to guide EdgeX design and implementation today. We invite you to join the conversation at https://wiki.edgexfoundry.org/.

We know the implementation has a way to go, but the beauty of the EdgeX architecture is that evolution and improvement can happen (is happening) microservice by microservice.  Join us and bring that opinion into the fold.  Help us make EdgeX even better!  Help us change lives through a better IoT platform.[/vc_column_text][/vc_column][/vc_row]