>> Good news. We're in the middle of a discussion
about hybrid and multi-cloud architectures.
This time, we're actually going to ask the question,
is it even possible?
Join me with Eric and Uli for another armchair architects.
[MUSIC]
>> Welcome to the Azure Enablement Show,
where we'll be discussing the challenges that you,
and our other tech-savvy customers have encountered.
Together, we'll be talking with experts to find
out how they think about these problems,
recommended tools, and best practices,
and tips they've learned from
years of experience that you can use.
Today on the Azure Enablement Show,
we'll do something we've never done before.
We're going to take our script, and we're going to
simply rip it up
because we want to talk today about architecture,
and architecture is discussion.
We're back with Uli and Eric.
I thought we were done talking about hybrid and multi-Cloud stuff.
Then after we were done talking,
we started to get into a whole other area.
I thought, no, let's get this on tape.
Let's actually talk about this because
the question that we didn't take up last time is,
is it even doable?
Can you actually do a multi-Cloud or a hybrid situation?
How do you go about implementing it?
Let's start with that question. Can you do it at all?
Let's start with that question.
That might be a yes or no question.
Do you want to vote on this Uli and Eric?
Can you do this at all?
>> My vote is, you can do it,
but it does require effort and diligence.
>> Eric, is this doable for you?
>> I think it's doable. In fact,
there are offerings from us,
and other Clouds to make this possible,
like the Azure Security Center,
on boarding multiple Cloud resources into a single pin.
What gives me a headache around this is authentication and
authorization when you've got two separate identity stores,
and you're trying to build an app that crosses
these Clouds. That's challenging.
>> I know you have the arc stuff.
Let's get into the challenges and the implementation details here.
You just said authentication and authorization is a big headache.
What else is a big headache in this scenario?
>> Let's start with the basics, David,
because authentication is something
that is obviously very important,
and we can certainly talk about it.
But let's start with the basics.
How do you build the software?
Now you are a software architect,
you're deciding you need to run in multiple environments
because you don't know if you
stay in one Cloud and move into another,
or you might have to take parts of your application,
and you run it inside a Telco Cloud because of latency concerns.
Let's take that scenario. How do you do it?
Well, the good news is that the industry has come
together in a form called the Cloud
Native Compute Foundation, the CNCF.
The CNCF has standardized with the work of Google,
Amazon, SAP, Microsoft, IBM.
I don't know how many people have been working,
a number of things.
Most people will know containers.
Most people would call them Docker containers,
but they're officially called OCI containers.
That is a standard that
the Linux Foundation and CNCF are both driving.
The second thing that the CNCF
has standardized is a thing called Kubernetes.
Kubernetes as an orchestration environment
as what I would call it next-generation infrastructure,
that effectively allows you to say,
how do I manage multiple servers to bring them together?
How do a high availability and so forth.
Kubernetes does that.
Then there are things like service mesh,
which is a network architecture of
how you run within your cluster,
how you isolate certain network cables and so forth.
The CNCF has a number of
initiatives that are at various stages of maturity,
but the great news is that you
can get Kubernetes environments everywhere you go.
They are all CNCF compatible.
Some are less compatible than others,
but at the end of the day,
there is a basis you can stand on,
which I personally believe is a very important piece.
We at Microsoft call it Cloud-native.
We support Cloud-native capabilities in Azure,
in our hybrid offerings,
and of course, we manage those as well.
That's building block one.
How do you get to a CNCF model?
Again, supported by the vendor of your choice.
>> Let me ask a question about that.
You just said Cloud-native but not Clouds native.
Last I looked, I
don't remember the federated stuff went anywhere with Kubernetes,
like there was going to be Kubernetes once upon a time.
Can't you get like Kubernetes sprawl,
congratulations I've got a bunch of Kubernetes running all
over the place and it's just the next level up of sprawl,
or is that what you're number 2 is?
>> Again for me, that's an operational for concern.
I'm still in the how do I built this software.
>> Sure.
>> It's a very important thing,
and we should have another additional fiscal where we talk about,
how do you manage all the stuff?
>> Okay.
>> There's a concept called GitOps,
I'll just give this teaser that allows you to manage a number of
Kubernetes environments because we have clients that
have hundreds or thousands of these things,
and certainly meets a management strategy
that is scalable as well.
I'm still building software though.
>> Let's get back a building, I'm sorry about that.
>> CNCF is the first base.
But CNCF is mostly infrastructure focused.
As an app developer,
I can now package my application and using DevOps tools,
get it into a common environment, great.
But how do I build it?
Now I'm running, let's say on Cloud A
that uses secrets management in this way,
and in Cloud B,
I use sequenced management in another way,
and all of a sudden I have to write two pieces of code.
I don't want to do that. You have two choices.
You can go with open source models like
HashiCorp Vault to stick with the sequence example,
or you can use an abstraction capability that we call Dapr,
D-A-P-R, the Distributed Application Programming Runtime.
If you're interested, you can go to dapr.io,
and read all about it.
But the idea is that you write your application to the Dapr API,
and the Dapr API has services like secrets management,
or state management, or stuff like that.
We and the community effectively built
connectors to the implementation
of sequence management in Cloud A,
Cloud B, and so forth.
We've seen great success with Dapr,
with a variate number of customers.
It's an open source initiative and we're looking at bringing
that into CNCF as well,
so that it becomes part of
this whole package of Cloud-native technologies.
Because you do need to solve a number of common problems,
and today everybody does it themselves figuring it out and Dapr is
one building block that effectively enables you to
do Cloud multiple environments in a very native way.
You'll write to the API and there was a provider underneath.
>> Can I ask a question about that one?
I don't know if you have more than two.
This idea of, write once, run everywhere.
I've heard that somewhere before.
I'm not sure if I can remember where.
I'm just wondering, have we learned anything from
that exercise around dapr in
trying to build stuff for multi-Clouds that we're like,
we were naive when we thought we could do that before,
but now we have a better idea?
How does that go up one level from
what we used to call from that place?
>> Dapr is I think a very clever design in the sense of, A,
it's modular, so it's not a set of monolithic capabilities.
If you say, I only need sequence management,
then you only get sequence management,
which I think is really important.
The other piece that the Dapr team has done and
the Dapr community has done, is effectively,
how do I live in multiple environments while
Kubernetes is the environment of choice,
it's not the only environment?
My friend Eric is in the IoT business,
and we do have an IoT runtime.
Getting Dapr to run on
non-Kubernetes environments is equally important.
Once run everywhere,
is broader than "just rely on Kubernetes."
Kubernetes is a great choice,
don't get we wrong here,
but it's not the only choice because again,
IoT scenarios, and other things might still be out there.
We have learned a lot by making it modular,
and making it adaptable to multiple environments.
>> The other thing I think about Dapr that's great,
and again not to plug this one framework,
but it does a lot for you.
It's very convenient.
Everything from service invocation,
to state management,
to binding, to microservices,
to the secret secure, even messaging.
There's a lot of productivity to be had
in building this application as part of
a multi-Cloud deployment that it abstracts away from
all the difficulty and all of the plumbing
associated with managing secrets and things like that.
As much as it is a functionality architectural abstraction,
it's actually a productivity enhancement
that allows you to quickly build, deploy,
and spend time writing code that's actually
a value to you rather than plumbing or non-functional code.
>> The last element, and again,
this is something that will come from multiple vendors over time,
is that capabilities for example,
that used to be bound to a specific Cloud,
let's say functions,
are now becoming portable.
For example, Microsoft, we are taking a lot of
our application development capabilities like Azure Functions,
Azure Event Grid, and those kind of things,
and making them available on top of Kubernetes.
You can effectively write your application in Azure,
use the capabilities and then conceptually speaking,
right-click on the application in the Azure portal,
and say, I would like to package this up.
You get a package of the application
including the dependency like the Azure Functions run-time,
and then you can take this package and for example,
go to GKE on Google,
on GCP, and run the application on that.
We have a number of services we call the Cloud consistent,
Azure application services like Functions,
Logic Apps, Event Grid and those kind of things,
but we also have our database services,
SQL server or Postgres.
We do our Azure machine learning capabilities on Kubernetes.
We're trying to make sure that our clients can build
applications using the basis of CNCF,
augmented with community initiatives like Dapr,
and then the last building block is
capabilities that are built for Azure,
made available on other environments
so that we can support this in-car scenario,
the infactory scenario, but also the scenario of actually,
I need to run this in GCP for regulatory reasons and so forth.
For me, those three come
together in order to really make the solution possible.
Again, you still need to be diligent.
You still have to think through what
are the dependencies I'm willing to take,
what are the abstractions I want to use and so forth.
>> There's also a key component here
though about observability security,
transitioning to the operational side of things,
which I don't think we'll have time to touch on in this session,
but we should talk about observability,
security, livesite operations, deployment.
All the operational components to figure out,
who's down, and whose fault is it,
and then how do I fix it,
and how do I make it more reliable?
We should also talk about observability anti-patterns,
which I've seen.
>> Well that's a good teaser, I'm
happy to stop there and to come to
those things because I was about
the try and take this full circle and say, cool,
I understand very now clearly really
what the vision is for how we build it,
but what I now don't understand is,
does Dapr do all the right things about
reliability o is that not the Dapr's problem?
Because we had talked about that in an earlier thing,
so the next question I think is,
now we've got to build,
let's talk about the running in the steady-state situation,
which gets us directly into the observability stuff.
Why don't we pick that up in a separate conversation?
>> Perfect Looking forward to do it, David.
>> We're deep in the middle of this conversation.
I really hope you'll join us on the next episode,
where we pick up right where we left off.
Join us again on the Azure Enablement Show.