>> Hey, good news. We're back with
another episode of Armchair Architects.
The Azure Enablement Series,
that's an ongoing conversation with Eric and Uli,
two of the smartest architects I know.
This episode we're going to talk about Edge computing, so join us.
[MUSIC]
>> Welcome back to Armchair Architects as
part of the Azure Enablement Show with Uli and Eric.
I want to talk about something that came up in the last episode,
which is Edge computing.
I have to admit as buzzworthy as it is,
I don't know how I would tell somebody
what Edge computing is and what it's not.
Can either you, Uli or
Eric help me talk about it to other people?
What do you say when someone says, "What's Edge?"
>> Eric, you always are great with these initial things,
and then I go in for [inaudible].
>> To me, the Edge it's a compute environment,
whether it's of different sizes that
exist on premises for the purpose
of helping customers and helping
solutions do things like aggregate,
filter, or inference on data that's coming from
devices that are connected to that premises environment.
In many instances, there's a spectrum of devices and we can go from
constrained Edge devices to data center-class Edge devices,
all with different levels of compute power and
complexity and different types of solutions
and places where you can host AI models, filtering models,
maybe even database components,
all in the purpose of doing things in
the on premises world before they
actually connect to the Cloud and send data to the Cloud.
>> Let me add one capability to this,
which is the reason why it's called Edge,
because what Eric described,
you could also do with an on
premise environment of whatever technology you choose.
The reason why it's called Edge,
it's because it's part of something.
Its part of something is called the Cloud,
meaning it's the Edge environment of the Cloud.
Meaning I take the operating model, the control plane,
the business model, the technology model,
security models, and all this stuff,
and export it from a centralized environment like Azure
in its region to a place where you want the solution.
It could be an on premise data center,
it could be inside a factory,
it could be inside an airplane,
it could be inside a Mac,
which is effectively a compute environment provided by
a telco provider like AT&T or
Deutsche Telekom or whoever it might be.
You effectively have, as Eric said,
a compute environment that is independent of an Azure region,
but conceptually, is linked
to that Azure region based upon operating models,
business models, technology security, etc.
An Edge is always part of
something and that something is the Cloud.
>> The child in me thinks,
I go to an Azure data center,
I pull some things out of a rack,
and I send them places.
To a certain extent,
I'm extending the Cloud by bringing
that computing device that would have
been centralized out closer,
and I'm doing that because there's a lot of chatter on the Edges.
If I can process that at the Edge,
then I don't have to take it over the longer distance or
whatever in terms of time or
back to the central thing to do the work,
because I've already done a bunch of the work, something else,
that's pre-curated for me and that gives me
a lot of flexibility. Am I getting it?
>> Conceptually speaking, you are right.
We don't do it that way because we
don't assume that people want to
run an Azure rack in their environment,
whatever that might be.
What we do is we effectively provide you with
a software framework that does potentially have an appliance,
a hardware piece like Azure Stack Edge
or Azure Stack Hub or capabilities like that,
but primarily, it's a software piece.
The latest incarnation of our Edge framework is called Azure Arc.
Azure Arc literally extends, for example,
the control plane of Azure to
capabilities that are outside of Azure,
like VMware VMs or Azure Stack VMs
or Kubernetes environments from Kubernetes in K-8.
Down the line, we're also planning to
support smaller Kubernetes environments like
K3S so that you can effectively take Edge environments,
not just with server-class hardware, but also,
with raspberry PI's or stuff like that, for more complex,
richer IoT scenarios,
where you need high availability of those
supporting capabilities for Edge processing and so forth.
David, you already pointed out there are two use cases that are
really paramount for why
Edge computing is important. Actually three.
One, safety, first thing.
If a physical device interacts with humans,
for example, you cannot afford to go to the Cloud.
It has to be local and decision-making has to be instantaneously
because anything that has to do with
human or other safety has to be local.
The other one is what often is cited as latency.
Again, they are a little bit on the fence because latency,
especially in the US, for example,
is to Cloud latency is superb.
There's very little latency,
but sometimes you do need to have round trip times that are
just not achievable if you go over a wide area network.
Then the last piece,
which you also mentioned and Eric,
I think we talked about a lot,
is if the data is so massive and it's
not relevant for AI development,
in general, people keep the data local and process it local.
Again, we talked already about the fusion
switching where you have to effectively immediately react,
otherwise, the batch might be kaput and stuff like that.
>> The other thing I wanted to bring up here, David.
Uli, you stole my example,
so I'm going to actually transition into another topic.
I wanted to bring up here is that I can
hear people from maybe process manufacturers,
discrete manufacturers yelling at us, well,
what about, like ISA 95 and Purdue Networks?
What about the difficulty around constrained devices?
The Edge is so nebulous.
I can think about it anywhere.
To which I can say, yes, we absolutely
need to think about those things when
we figure out what types of
workloads and solutions we need to run at the Edge.
We absolutely have to make sure that we can operate in
those constrained environments, insecure network infrastructure.
Sometimes David, many of
the assets that we want to harvest time series data
from lives inside of a level 0 of a secured network architecture.
They never even see the plant network,
let alone the production network,
let alone the Internet network.
We have to figure out clever ways of
doing things like deploying technologies like
Edge to bubble those things
up in a secure and constrained environment.
>> Let's step back here a little bit.
You threw a whole bunch of concepts
at our users here or our readers.
An ISA 95 network or
Purdue network is originally coming from the chemical industries.
Chemical industries, if you do the wrong thing,
could lead to blow ups because this is dangerous stuff.
Therefore, they have a hierarchy of networks from level 0,
which is the local control plane
that literally manages the mixers,
the cookers, and whatnot,
and could lead to literally explosions
and damage to humans or equipment and so forth.
Then you have levels up to five
is the original Purdue architecture,
which is now officially called ISA 95.
There is no way that level 5, which is let's say,
an ERP system running in a back end
goes immediately to level 0, controlling the device.
That's just not allowed.
Therefore you have to go and forward commands from level
5 to 4 to 3 to 2 to 1 to 0 kind of thing.
That requires a technology called nesting.
The IoT Edge team,
delivered a capability called the nested Edge.
That allows a Edge at level 0 to talk to an Edge at level 1,
talk to a Edge at level 2, etc.
We have built the necessary forwarding and queuing
architecture so that commands and data can
flow in either direction through gateways effectively that
protect the layer 0 from layer 2 and so forth.
That's really what's behind this ISA 95,
which is obviously a fairly big deal,
and it's very complex.
Therefore, solutions need to be found like
the IoT Edge does with its nested Edge support.
>> I have a follow-up question.
I'm assuming because you said it's an extension of the Cloud,
that part of that means that the Cloud provider,
promised to be the people in charge of managing,
updating, upgrading the thing that you have.
Whose job is it to determine how
thick that Edge is and what capacity I need at the Edge?
Is that something that architects pay attention to?
Because it's a device, don't I lose that?
I want a bigger device magic that comes with the Cloud.
How does capacity work and how does
management work in an Edge configuration?
>> In my experience, it's all about what you need to do.
As Uli mentioned, if there are human souls,
then you need to actually surface
alerts and things of that nature.
Then we need to figure out how to best
navigate that complex network infrastructure
and just bubble up those messages,
but then we need to figure out what
is the actual workload going to
be that facilitates that use case and what can it run on.
Because there are a series of what we call constrained devices.
These are whisper thin.
I only have, maybe two megs of ROM and
maybe 10 megs of RAM and these things need to
plug into a specific space on
the plant floor to some of those
data center ask type elements in which
we're trying to push consistency of compute capabilities to
the Edge so we can deploy
more complex Edge workloads with confidence.
I think it depends,
but those are the things it depends
on from an architecture perspective.
You should know, as an architect,
whether or not the Edge module that you're trying to push
down has the ability to run on a constrained device,
or if it should run on a more consistent,
more powerful compute piece of infrastructure at the plant.
>> Well, it looks like you have a last thing
to say to take us out.
>> No. I'm just pointing out that
Eric's description is completely correct.
There is no one size fits all,
but the architect is ideally the person that thinks through
sizing and it also thinks through availability, reliability.
Does the system have to be absolutely 100 percent up and running?
That means it's more complex,
which means you need more infrastructure
inside the factory or plant,
or if it's not,
then you might be able to get away with simpler infrastructure,
which also influences your sizing.
From my perspective,
Edge is like Cloud solutions are not one size fits all.
It depends on what it is,
what you're doing with it,
what are the criticality?
If the system fails, what could happen?
Again, we mentioned safety before.
Obviously, if it's a safety oriented process, it better be.
It is very mission critical and it
better be highly available and robust.
Those are some of the things that,
again, come to bear here,
even more so than in
Cloud solutions and often because it's the physical world.
As I mentioned before, there could be explosions costing
human lives and damage to equipment and so forth.
>> Cool. Now, I have to admit you've got
me thinking about what do you
have to think about when building one of these architectures?
But we don't have enough time to talk
about that and for me to mull over that.
I'm going to go do it off camera.
I want to thank you, Uli, I want to thank you, Eric,
for talking about this and getting my brain running on this topic.
I really appreciate everybody watching this.
I hope you'll join us again for another episode of
Armchair Architects on the Azure Enablement Show.
[MUSIC]