Looking Back on EdgeX Foundry’s First Year and Preparing for Continued Growth in 2018

By February 9, 2018Blog

Written by Jason Shepherd, Chair of the EdgeX Foundry Governing Board and Dell Technologies IoT CTO

I can’t begin to express how exciting it is to see how what we started as a small team at Dell in July of 2015 has blossomed into a vibrant community of nearly 70 member companies with much more activity brewing behind the scenes. It truly is the most rewarding collaboration I’ve been part of in my career and I want to thank the many people that have helped along the way.

We’ve accomplished a lot as a community in just the past nine months since the April 2017 launch:

  • The Technical Steering Committee (TSC) and work groups are running smoothly and we have established a bi-annual release roadmap that we’re already meeting schedule commitments against – both with the first ‘Barcelona’ community release that dropped Oct 20 and the ‘California Preview’ last week.
  • Last October we announced an alliance with the Industrial Internet Consortium to collaborate on test beds and best practices and we’ve also established liaison agreements with multiple standards bodies and other open source projects.
  • More alliances are in the works across the board. Part of the power of EdgeX is that it’s a tangible foundation that can help standardization efforts work better together.

EdgeX Road Map

 

We’re all ears for new collaboration ideas that further the cause for greater IoT interoperability and adoption.

As with any open source project you don’t have to be a member to download or use the code, join the TSC meetings or participate in the working groups, but membership does come with benefits.  In addition to being visible on the logo boards as a thought leader and having direct (Platinum tier) or indirect (Silver tier) representation on the Governing Board we also offer a variety of events where members can join at a subsidized cost.

EdgeX Foundry Members

 

For example, we had our first official joint project presence at IoT Solutions World Congress in early October with 12 EdgeX member companies in attendance demonstrating their commercial value add on top of the EdgeX foundation. The booth was packed throughout the show and more events are in the works including Hannover Messe in April where we’ll celebrate our first birthday in the same spot it all got started a year prior.

Many EdgeX members have struck up new strategic relationships and even business since the project tends to act as a vendor-neutral IoT partner program.

Every day we’re seeing more and more active contributions from the community, a number of which are highlighted throughout this blog.

The blog on the Schlumberger contribution is a great example of the power of the project – just like that any existing southbound device connectivity now has a path to Google IoT Core.  We also already have an EdgeX Export Service for Azure IoT Suite and AWS is in process along with numerous other targets including the industrial clouds, tools like OSIsoft Pi, SAP Leonardo and IBM Watson.

Late last year the Dell team did a hackathon to tie AR tools into EdgeX to enable an entirely new UI experience. We’ve even prototyped with voice assistants like Amazon Alexa, enabling voice control of connected equipment through any number of underlying communication protocols.

Each of the posts below is a great example of the scale and innovation possible when developers stop reinventing the plumbing of an IoT stack and start focusing on value creation around the wheel.

On the south side, we’ll see device makers start providing EdgeX-compliant drivers with their products for greenfield applications, plus we’ll see a business models for creating and selling Edge-X compliant device services that interface with legacy equipment.

Beyond the core project we’ve seen the community expand in the form of university-sponsored EdgeX research efforts plus EdgeX-focused hackathons.  Throughout 2018 we’ll be encouraging more developer engagement through various types of channels.

We can always use more help so if you’re a developer and would like to get involved just dive in!  In terms of spreading the word in general a great starting point is by joining our Speaker’s Bureau.  And finally, nothing brings together a community like free food and drinks – so help us spread the word on EdgeX at your local IoT meetup and we’ll provide $250 for your tab.

Closing on the community aspect, while we greatly appreciate our founding and new members and their ongoing contributions and commitment to our cause what’s equally exciting is the activity that most don’t see behind the scenes – hundreds more companies in various forms of engagement spanning active evaluation to building PoCs to even incorporating EdgeX into their commercial products.

Are we there yet?

Speaking of commercialization, customers ask me all the time when EdgeX “will be ready”. My first answer is always this – whenever you package up a version of the code and pick up the phone to offer customer support. But then I expand by saying that I see field PoCs beginning to scale out this summer after the June California release and production deployments increasingly spinning up later this year.

Frankly, the EdgeX code base is more mature today than what a lot of people are hacking together out there for PoCs but at the same time we want to make sure we do things right. Aside from the massive reduction in footprint from the original seed code (more on that later) the biggest inflection point in June will be the addition of key security and manageability features.

From a Dell perspective, we purposely didn’t include much for security in the initial seed contribution because we felt it was important that these features are defined by the community so they’re universally trusted. So, for the past 9 months there has been a global collaboration between security and manageability leaders to define layer upon layer of security modules and management practices with the first wave of functionality from a broader roadmap hitting in June.

And like everything else, the baseline plumbing APIs and reference services for this functionality will be open to enable a variety of best-in-class commercially-licensed EdgeX-compliant plug-ins for security and manageability functionality.

Most importantly, we’re starting to see the EdgeX framework being included in projects by end customers.  I haven’t yet met an end user who doesn’t love the benefits an open ecosystem that provides freedom of choice to make or buy value-added components. Important to any open source project is the commercialization aspect as while many end customers love the benefits of EdgeX they don’t necessarily want to support the open source baseline themselves.

Numerous companies are already launching their own commercially-supported versions of EdgeX together with developer support. I need to stay vendor-neutral here but definitely keep an eye out for more on this front!

Size (and speed) matters.

When Dell started incubating the code that became EdgeX, we were more interested in the right architecture for facilitating and building an ecosystem than optimizing the starting footprint.  As such, our original contribution that was based on Java and some Javascript and Python had a pretty large footprint.

However, the beauty of a microservices framework is that each component can be individually replaced with more compact versions that leverage the same APIs.

Fast forward to now and the Go Lang-based microservice alternatives in last week’s “California-preview” release demonstrate a path to reducing the footprint and boot times by an order of magnitude.

The code is in the GitHub now – download and give it a spin!

The net effect is that soon the full EdgeX stack will run on a Raspberry Pi-class device and of course microservices can be broken apart in any combination to run on even lighter weight devices.

Further, there’s no reason various sections of the code can’t be combined in commercial implementations using the same foundational APIs – it really comes down to a tradeoff of performance over flexibility.

Get on the bus!

In addition to the massive footprint reduction, work is already underway for a message bus option to improve throughput for streaming data between microservices as compared to the current REST-based intercommunication.

This combined with the overall Go Lang work for reducing footprint is driving increased interest across the board. We purposely didn’t start with a high performance, low footprint foundation because it’s important to allow the community to creep up on what’s table stakes for open source versus valuable to make proprietary while still leveraging the common APIs for interoperability.

It’s all about the APIs.

This ability to build proprietary, interchangeable components brings me to one of the first misconceptions that I encounter when I talk with people about EdgeX.

Some think that you have to give away all of your IP because it’s an open source project. However this is far from the case because the EdgeX project has been carefully architected to enable commercial value-add around a lowest-common denominator open source foundation, more specifically the associated APIs.  As such, you don’t have to contribute any value-added functionality you develop to open source, rather you’d just leverage the specified open SDKs and/or APIs to create them if you want to be “EdgeX-compliant”.

The bottom line is that EdgeX is more about the community-governed APIs than the code itself and you can replace every lick of code and still be “EdgeX-compliant” by following the baseline APIs.  So, in the future we’ll see proprietary high-performance versions that use the same foundational EdgeX APIs.  For example, by replacing the current Core Services baseline with a compressed C-based binary you could enable PLCs that can be software-defined with plug-in value add from the ecosystem.

There are many opportunities for proprietary value add beyond the EdgeX foundation spanning functions for real-time operation, workload orchestration, load balancing, failover, redundancy, TSN, security, system management, analytics and device drivers. This ability to monetize within an open, hardware- (e.g. x86, ARM), OS- (e.g. Linux, Windows, Unix, RTOS) and protocol-agnostic ecosystem while minimizing reinvention is what’s driving so much interest in the project.

What’s with that ‘X’?

Clearly “Edge Foundry” plays off of Cloud Foundry but we sometimes get the question “what’s with that X?”

The answer is that the X allowed the project name to be trademarked for use as a future certification mark. We’re targeting a launch of a certification program within the Linux Foundation project early in 2019 and this vendor-neutral effort will enable providers to certify that regardless how much they added to or changed the baseline code for their commercial offering they maintained the specified EdgeX APIs that facilitate interoperability.

Stability for key elements in the certification program (e.g. required APIs and overall process) will be maintained through the EdgeX Technical Steering Committee (TSC) and a versioning system.  This certified value-add can be a full EdgeX-compliant IoT platform, a value-added plug-in microservice(s) or a services model that taps into the APIs.

Imagine your offering accompanied by the EdgeX logo which gives customers the confidence that they can readily plug it into their solution… now that scales!

It’s not just about gateways.

A second misconception I often see is that EdgeX is only about edge gateways.

While it’s most tangible to first talk about the project in the context of gateways because these devices are inherently a place where “south meets north” in an IoT stack, the loosely-coupled microservices architecture enables interoperable value-add to come together across any sort of distributed computing model.

Microservices serving various functions can be deployed in any number of different types of container or VM technologies – all on one device or spread across many devices working together in a broader networked system.

Device Services can be broken out and deployed on capable smart sensors that in turn communicate directly with a server in a datacenter or in the cloud – look ma, no gateway!

Further, we’re starting to see people experiment with the idea of co-processing within one device by running the Core and Export Services on the main host processor and analytics on a co-processor (e.g. GPU or FPGA) for acceleration.

In all cases these functions – whether based heavily on the open source code or 100% net-new proprietary code – can be written in any different programming language and be bound together by the common EdgeX APIs.

Net-net, we’ve had thousands of conversations with partners and end customers regarding the project approach and every day it becomes even clearer how EdgeX benefits end users in the inherently heterogeneous IoT market.

The enablement of distributed computing is what really sets EdgeX apart – there are many great open source efforts out there but there remains to be nothing like EdgeX for facilitating a truly open ecosystem for distributed IoT edge computing.

Putting things in perspective.

The IoT market is messy and there are a lot of solutions looking for problems out there, so as the code takes shape to facilitate grater interoperability we’re also working together to put the project in perspective for valuable real-world use cases.

Samsung is chairing a Vertical Solutions Working Group that will host specific use case-focused projects that drive requirements from end users back into the roadmap in addition to developing and deploying test beds.  They’re organizing one themselves for smart factories and the TSC recently approved a proposal from National Oilwell Varco (NOV) to spin up a project for Oil and Gas.

The working group will host similar efforts for many other industries and use cases and each will be a great way to prove out the platform in real-world settings. Building Automation is likely one of the next efforts to spin up and we encourage you to step forward and collaborate with industry peers on other key use cases spanning transportation to retail to healthcare and beyond.

As things progress we’ll group common paradigms as appropriate (for example needs for remote oil and gas and mining sites are very similar) while recognizing unique needs, ecosystem players and standards by industry.

Last month we launched an effort to post relatable stories about these use cases enabled by EdgeX in online communications.  Stay tuned for more details there.

With that I’ll close for now.  Again, thanks to everyone for their contributions to date and I look forward to what’s in store for 2018!

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