>> Hey, good news.
We're here with our architects Uli and Eric to talk
about hybrid and multi-Cloud architectures. Join us.
[MUSIC]
>> Welcome to the Azure Enablement Show,
where we'll be discussing the challenges that
you and other tech service customers have encountered.
Together, we will be talking with experts to find out
how they think about these problems,
recommend the tools and best practices
and tips they've learned from
years of experience that you can use.
Today on the Azure Enablement Show we 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 for
another discussion about architecture stuff.
This time we're going to talk a little bit about
multi-Cloud and hybrid Cloud stuff.
I have to admit having been in this field for a long time,
I have heard hybrid Cloud be used for all sorts of things.
It looks like the word hybrid no longer
has a meaning to me because I've heard so many different meanings.
I think we need to level set here.
Can one of you folks,
please tell me what
you mean when you mean multi-Cloud and what you
mean when you say Hybrid Cloud and how they're
different so we can just level set there first.
>> Do you want to start kick us off?
I've got my own thoughts, but I want
to see what you have to say first.
>> Well, the way I think about this
is we're talking about multi-environment,
not multi-Cloud this or hybrid Cloud
that because at the end of the day we need to be able
to compute our solutions where the scenario requires it.
That could be in a car,
it could be in factory,
it could be in a data center that you own,
it could be in a Telco edge environment,
I'm sure you have heard about those these days.
It could be in the Cloud, it could be in the Microsoft Cloud,
it could be in the Amazon Cloud,
whatever it might be.
From my perspective, solutions these days need to do two things.
One, parts of it need to
be able to run where they meet what they are required.
It could be in the factory that you need to be there,
it could be in the car,
or it could be in the backend, let's say Cloud.
Then the second thing is you need to be able to take
advantage of the environment that you're in an ideal fashion.
If it's a constrained environment,
you need to run constraint but if you have a Cloud environment,
you should be able to run
backend in ideal fashion use all of the resources.
Unfortunately, I see too many software packages,
what I call hostable.
What that means from my perspective is
they just write the code to a common standard,
let's say, like Kubernetes or
the Cloud Native Compute Foundation environments.
Then effectively tell their consumers this can run anywhere.
That's true, but they don't take advantage of
anything either and so part of the question is,
how do you balance where you need to run quick,
which means anywhere or in
multiple environments and at the same time,
how do you understand what
the services are that you are presenting and make
sure that the services utilize
the environment as optimal as possible.
>> Like Cloud app design principles are key.
Just putting an on-premises workload
into a container environment and saying
it's now a Cloud app is not necessarily the best way to go.
It's oftentimes just a milestone to get to
that Cloud app design pattern.
But I think what's interesting is these terms,
hybrid Cloud and multi-Cloud,
when I say hybrid Cloud,
in recent history, we all knew what that meant.
That meant some data center that I
can actually walk into or badge into,
talks to and has an application that
spans a connection to the Cloud for something.
The thing that I'm asking myself nowadays and understanding
all of the scenarios that really went through
with partially connected devices,
things on the Edge.
That's hybrid Cloud and multi-Cloud all represent
an environment where the app is to two places.
Some component of it as either in one Cloud provider and and
other Cloud provider or one Cloud provider
and on-premises or all three of those things.
I think that the differentiation between
hybrid Cloud and multi-Cloud is actually
just blurring a little bit these days.
>> Piece I would add Eric,
both of us have described aesthetic worlds where you
make a decision once it runs into factory on the car,
or on on-premise datacenter and other parts
runs in a Cloud doesn't change.
Well, that's actually not true anymore.
We're starting to see desires where people say,
"Well, during the day I want my application,
the user interface, let's say run optimized in Telco Clouds
because they're closer to
my end-user and latency is low and so forth.
But during the night,
I went to retract all of those services
and provide a user interface for the Cloud,
for the night owls let's say, but they are far
fewer and a little bit of increase of latency doesn't hurt.
Don't just think about this as a static thing,
also you will be able to dynamically optimize.
I call that vertical scaling rather than horizontal scaling.
It's certainly a new pattern that, I think,
we will get more providence with
5G and other things becoming ubiquitous.
>> Where it becomes possible to actually
throw stuff between it and not
have people actually know the difference.
Because once upon a time,
multi-Cloud used to be Cloud plus one.
I want to make sure that if for some reason
my Cloud provider is not nice to me or they go down or whatever,
I can go somewhere else.
It sounds like you're discussing a pattern that is actually
more steady-state and not just like disaster recovery.
It's more like, Yeah, I'm intentionally doing it this way
because I can go there.
>> Can I address that? I think my Cloud providers not nice to
me is a great way to encapsulate
a very real concern that a lot of
our customers still have to this very day,
which is, I don't want to be beholden to one provider because if
they are not nice to me on one extreme
or they go down, what I'm I left with?
Or they retire a component or
a service that I depend on, what do I do then?
I can't tell my customers,
hang on while I rewrite a redeployed to another Cloud.
Those are very real concerns and I
think real discussions with Cloud providers is something
that's very important but doing it just because you don't
want to have all your eggs in one basket in my experience,
is not really the wisest decision.
Because then you have total cost of ownership and
integration challenges and the construction or the creation of
technical debt which might span
your effort just not to get hurt by one Cloud provider.
That in itself could be harmful.
>> But again, Eric, let's be generous
with our clients because if you're,
for example in a regulated industry,
you might have to be able to extract
yourself from what the regulator
calls a systemic dependency
and the Cloud look be in systemic dependencies.
For me, they are very valid reasons outside of risk management
that really require us to think through how we
can help our clients to, on the one side,
write software that's flexible in terms of it
can run in multiple environments but on
the other side also take advantage of
the innovation that each Cloud provider,
including Microsoft is providing because you
can't expect everything to be
available everywhere at the same time.
I think there's a balance to be heard and architecture,
our topic is the way to balance this.
From my perspective.
>> No go ahead.
>> About it. If I were designing a new application,
let's start with a fresh one,
what I will do is I would look at my architecture.
We talked about application patterns before and thinking through
how you separate certain pieces.
The core of the application,
most likely able to write it in a way that would allow me to
extract myself from a dependency.
But there are other things where I would
love to be able to utilize
the innovation that either AWS or Microsoft or Google provides.
I isolate that architecture
again using the bulkhead pattern we talked about
before to effectively enable me to innovate in this area,
utilize the latest and greatest but being able to consciously
site that I might have to rewrite that part
of the application for another Cloud environment.
For me it's not black and white,
it's much more gray.
I think a lot of architects would do well thinking through.
Where I'm I okay to
rewrite this because I'm getting benefits from going
proprietary in a specific environment
and where do I benefit from staying with,
for example, a Kubernetes basis or something like that.
>> I have one last question here.
When you go multi-Cloud or even hybrid Cloud,
There's this operational context,
where if something does
go wrong and I'm thinking about this in the customer perspective,
something does go wrong or if you have to pay attention to
privacy or you have a regulated situation or stuff like that.
It means that the people that are operating in the thing,
and I count myself in that group from my background,
will have to interact with
Cloud provider X and tomorrow they might
have 2X if they have two Clouds that they have to do with.
As architects, is there anything we can do to improve or make
that operational context not nearly
2X so it's not scaling linearly with Clouds.
>> The way I think about this David,
is there are three elements that you need to
think about when you're thinking about operations.
The first one is there is a static set up.
It's not static over a long period of time,
but for weeks or month it might be static,
we call those lending zones or control towers,
those things, where you effectively set up the infrastructure of
a Cloud provider A and Cloud provider B
in a way that protects your enterprise and so forth.
That I would always use proprietary capabilities for.
Because you want it optimal,
you want it scalable, you want it cost-efficient.
Then the second piece is you want to have
the daily tasks like getting the monitoring information,
getting the login information,
being able to look at what's
happening across my entire environments,
that's why I called it multi-environment,
in a single pane of glass,
those you want to be able to utilize
a single environment in
ideal case that brings all the data into it.
The third and final thing is when stuff really gets very bad.
I talked about the static set of,
of the infrastructure and the daily monitoring,
the daily logging management and those things.
When stuff doesn't work anymore,
then you will have to most likely revert to
Cloud-native tools or environment-native tools to use
the language I've been using all the time because you'll now need
to go deep into the troubleshooting stack.
They again, are common tools that allow you to
do certain things but in that case,
if you are using multiple environments,
I'd say multiple Clouds,
you will have to build
experience and people up that understand Cloud A, Cloud B,
Cloud C because ultimately it
goes into the bowels of the beast and
therefore it is going to be special
very focused on the environment if you are in.
Organize yourself around these three,
I think you can come to a very healthy balance.
>> I think balance,
especially when it comes to operation is key.
I've had customers that really underestimated the amount
of orchestration and preparation needed to manage multiple Clouds.
Everything from live site operations to
deployment of components to monitoring,
it takes on a new dimension of complexity across multiple Clouds.
Even just trying to figure out maybe whose fault it is,
who's down becomes a challenge.
>> As much as that's like a cliffhanger.
I think this is probably a really good place to stop.
Thank you very much. I hope you'll join me on
another one of these discussions because I know we've got
a whole bunch of things to talk about.
>> I'll be back.
>> Yeah.
>> Well, 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.
[MUSIC]