http://www.techradar.com/pro/linux December 2019 LXF257 43Jason Shepherd INTERVIEW
function out of the OS, out of the
protocols, because there will never be one
protocol. You need a de facto standard
and de facto standards are created
through consensus – and a great way
to get consensus tangibly is with open
source code. You need to make it OS-
agnostic, hardware-agnostic, protocol-
agnostic, agnostic to Kubernetes, Mesos,
Docker... We don’t make choices on
infrastructure in EdgeX.LXF: I feel it’s hard for a lot of hobbyists
or app developers getting into IoT to see
why a middle layer is necessary. They
have a small device like a Raspberry Pi
that we love so dearly, and that can
juggle data locally fine – and if the
application needs some kind of
centralised data management, there’s
varying degrees of services and clouds
that are available commercially.
JS: I think for lots of the new IoT use cases
people are in what I call ‘Pi in the sky’
mode. I take something like a Raspberry Pi
and I connect it to a public cloud, and I
don’t know yet that I’m going to have aproblem with pumping data mindlessly
into the cloud, or that I’m going to have to
pay egress charges to get my own data
back. So you want to decouple the edge
from the cloud quickly. The clouds – and
some of them are doing great things, I
don’t want to be too negative about them- but they’re trying to give people IoT
gateway drugs. Y’know: let me get you
hooked on my cloud... here, have a dev kit
that makes it all too easy to get locked in
to my APIs. EdgeX DevKits will give you
choice as a developer to work with other
cool projects like Akraino, or things like
Blockchain and Ledger.
LXF: So in a lot of ways it’s quite abstract
and imaginary, or up in the air, in the
sense that it doesn’t care about what it’s
running on? Traditional embedded
computing is so tied to a particular bit of
hardware, for reasons of smallness. I’ve
been hearing ‘cloud native’ a lot lately.
JS: Right. So EdgeX is a cloud-native
framework, pushed down or shrunken so
it can run on something like a Raspberry Pior BeagleBone or whatever. The thin
compute edge, I would call it. There will
still always be embedded computing, but
the thin compute edge is basically the last
point before you get into controllers and
other embedded stuff like sensors, very
constrained microcontrollers and PLCs in
the manufacturing line. It’s the last point
where you’re still software definingworkloads through containers. It’s driven
by memory – it takes about 256MB where
I can run a hypervisor and EdgeX, or
something like it. Maybe some security
and management plug-ins, maybe a basic
rules engine, but you’re not going to be
running massive deep learning on this
kind of hardware.
We’re around that level with the
footprint today. When we launched, our
prototype code was about 2.5GB – it
was huge. But we had to tell people not
to worry, everyone agreed on the
architecture: loosely coupled
microservices, polyglot. So we took
those principles, and made it optimised
for nodes, things that don’t have a person
in front of them that are also distributed all
over the place. Security, management...
it’s protocol soup down there, where as up
in the IT world there’s only tens of
protocols that matter.
In the community we switched from the
Java prototype code to Go. Obviously Go’s
a very popular language, it allows you to
maintain platform independence. I meanyou could make it tiny in C, but you’d
lose that independence and it won’t
scale as much for this ecosystem. But
it’s polyglot too: we have our reference
implementation in Go, but you can replace
anything in there with whatever language
you want. It’s bound together with the
APIs that are governed by the technical
steering committee and the Linux
Foundation. Driven to be a de facto
standard by new people piling in.
EdgeX started with about 50 founding
companies. We built that up over a
number of years, building consensus with
a lot of great folks. Our codebase went
down from 2.5GB down to 128MB in about
18 months, which is pretty good (can they
do the same thing with the Ubuntu ISO,
please? – Ed). The beauty of a
microservices framework is that individual
people can work on different functions
independently and then bring them back
together again.
We knew from Dell, when we got
this going three years ago, we knew it
would take about three years for the
big companies to get on board. I figured
they’d be trying to own everything
for about three years, for all the
aforementioned reasons. But now those
companies are realising, and not only just
for the basics, but also the holy grail, that
they need to collaborate on just enough
plumbing to interoperate. And not only
just to get going and start building things.
Do you think the PC market would have
scaled if it cost $1,000 to connect your
keyboard? What if every website required
a custom protocol?
No, you make your money on the
idioms: security, manageability,
scalability, connectivity, usability,
augmented reality – you do not make
your money on the plumbing. And this is
why open source – and I guess I’m
preaching to the choir here – helps you
stop undifferentiated heavy lifting.IT’S A LOSING BATTLE
“Generally, in consumer, if you build trust
with someone and you get value from
their services, then your privacy goes out
the window. Period.”
Nah, just kidding.
Jason’s a nice chap.4440Decmbr rb0c2193b29 December 2019 LXF257 43
Jason Shepherd INTERVIEW
function out of the OS, out of the
protocols, because there will never be one
protocol. You need a de facto standard
and de facto standards are created
through consensus – and a great way
to get consensus tangibly is with open
source code. You need to make it OS-
agnostic, hardware-agnostic, protocol-
agnostic, agnostic to Kubernetes, Mesos,
Docker... We don’t make choices on
infrastructure in EdgeX.LXF: I feel it’s hard for a lot of hobbyists
or app developers getting into IoT to see
why a middle layer is necessary. They
have a small device like a Raspberry Pi
that we love so dearly, and that can
juggle data locally fine – and if the
application needs some kind of
centralised data management, there’s
varying degrees of services and clouds
that are available commercially.
JS: I think for lots of the new IoT use cases
people are in what I call ‘Pi in the sky’
mode. I take something like a Raspberry Pi
and I connect it to a public cloud, and I
don’tknowyetthatI’mgoingtohaveaproblemwithpumpingdatamindlessly
into the cloud, or that I’m going to have to
pay egress charges to get my own data
back. So you want to decouple the edge
from the cloud quickly. The clouds – and
some of them are doing great things, I
don’t want to be too negative about them- but they’re trying to give people IoT
gateway drugs. Y’know: let me get you
hooked on my cloud... here, have a dev kit
that makes it all too easy to get locked in
to my APIs. EdgeX DevKits will give you
choice as a developer to work with other
cool projects like Akraino, or things like
Blockchain and Ledger.
LXF: So in a lot of ways it’s quite abstract
and imaginary, or up in the air, in the
sense that it doesn’t care about what it’s
running on? Traditional embedded
computing is so tied to a particular bit of
hardware, for reasons of smallness. I’ve
been hearing ‘cloud native’ a lot lately.
JS: Right. So EdgeX is a cloud-native
framework, pushed down or shrunken so
it can run on something like a Raspberry Pior BeagleBone or whatever. The thin
compute edge, I would call it. There will
still always be embedded computing, but
the thin compute edge is basically the last
point before you get into controllers and
other embedded stuff like sensors, very
constrained microcontrollers and PLCs in
the manufacturing line. It’s the last point
whereyou’restillsoftwaredefiningworkloadsthroughcontainers.It’sdriven
by memory – it takes about 256MB where
I can run a hypervisor and EdgeX, or
something like it. Maybe some security
and management plug-ins, maybe a basic
rules engine, but you’re not going to be
running massive deep learning on this
kind of hardware.
We’re around that level with the
footprint today. When we launched, our
prototype code was about 2.5GB – it
was huge. But we had to tell people not
to worry, everyone agreed on the
architecture: loosely coupled
microservices, polyglot. So we took
those principles, and made it optimised
for nodes, things that don’t have a person
in front of them that are also distributed all
over the place. Security, management...
it’s protocol soup down there, where as up
in the IT world there’s only tens of
protocols that matter.
In the community we switched from the
Java prototype code to Go. Obviously Go’s
a very popular language, it allows you to
maintain platform independence. I meanyou could make it tiny in C, but you’d
lose that independence and it won’t
scale as much for this ecosystem. But
it’s polyglot too: we have our reference
implementation in Go, but you can replace
anything in there with whatever language
you want. It’s bound together with the
APIs that are governed by the technical
steering committee and the Linux
Foundation. Driven to be a de facto
standard by new people piling in.
EdgeX started with about 50 founding
companies. We built that up over a
number of years, building consensus with
a lot of great folks. Our codebase went
down from 2.5GB down to 128MB in about
18 months, which is pretty good (can they
do the same thing with the Ubuntu ISO,
please? – Ed). The beauty of a
microservices framework is that individual
people can work on different functions
independently and then bring them back
together again.
We knew from Dell, when we got
this going three years ago, we knew it
would take about three years for the
big companies to get on board. I figured
they’d be trying to own everything
for about three years, for all the
aforementioned reasons. But now those
companies are realising, and not only just
for the basics, but also the holy grail, that
they need to collaborate on just enough
plumbing to interoperate. And not only
just to get going and start building things.
Do you think the PC market would have
scaled if it cost $1,000 to connect your
keyboard? What if every website required
a custom protocol?
No, you make your money on the
idioms: security, manageability,
scalability, connectivity, usability,
augmented reality – you do not make
your money on the plumbing. And this is
why open source – and I guess I’m
preaching to the choir here – helps you
stop undifferentiated heavy lifting.IT’S A LOSING BATTLE
“Generally, in consumer, if you build trust
with someone and you get value from
their services, then your privacy goes out
the window. Period.”
Nah, just kidding.
Jason’s a nice chap.