>> Hey, did you see
our last episode about mission-critical applications?
Today we're going to take it further.
We're going to talk about what happens
with mission-critical applications
when you don't run everything in your organization. Join us.
[MUSIC]
>> Hey, so welcome back to the Azure Enablement Show.
Last time we were talking to Martin and
Sebastian about mission-critical and we're
starting to get deep into stuff and we're talking
about reference architectures and I was
realizing as a customer that
the reference architect that we looked
at didn't quite match my environment.
We decided we continue with
that conversation so let me switch back to customer loads.
We can talk about this more with Martin and Sebastian.
I'm back as a customer.
Let's talk to Martin and Sebastian.
Hey, folks, it's really great to see you again,
and I really appreciate you getting me started
in the land of mission-critical last time,
where we left off as we went over the basics of mission-critical,
you're able to tell me about
design principles and reference architectures and we started to
get into how do I get started in one of the ways you suggest I get
started was looking at the basic reference architecture.
We did. But the problem is
that reference architecture doesn't exactly
match my environment in a couple of
ways that I would love to know how to deal with.
The first thing that was tricky for me
was I have to in my environment,
not just work in the Cloud,
but I have to connect to some on-prem resources.
I've this database that cannot go into the Cloud.
It has to run on-prem,
I can't let that data out.
Somehow there has to be some connectivity
between my mission-critical app living in
the Cloud and my on-prem stuff
that was thing number one and number two,
that was also tricky to me is I don't actually
control all the things in my environment.
I have to live in the space that gets carved out
for my group is we build this stuff out so I'm wondering,
is there reference architecture that takes
both of these things into account that we can look at?
>> Yeah, sure. You lucky for you there is because
the scenario just mentioned is what we
call typically the landing zone scenario.
There's Azure landing zones which
more and more organizations adopt to and this is exactly
the case like you have a central organization like
what you might call it a Platform team who caters for sentencing.
They for example provide identity,
they provide networking and we
can talk about your on-prem database in a second.
But they also provide you your Azure subscription for example
or the number of and that's what we call landing zone.
Maybe let's start by looking at
the architecture that we looked at last time.
>> This looks familiar.
>> Exactly. This looks familiar,
so we still have our global resources,
we still have our stamp resources and there
are couple of differences which we can talk about in a second.
But to start with let's actually scroll down here.
Because that's the part that it's new now that
you didn't see in baseline architecture last time.
>> Okay, what am I looking at?
>> A couple of things we look at.
The big thing in the middle is what's called the connectivity
subscriptions and that's something that you don't control.
That's controlled by your platform pin.
That's where they might have like a VPN connection or like
a ExpressRoute connecting tool on-prem.
They might have DNS servers in there that might have firewalls and
all that goodness is in there and then at the very bottom,
you see the on-premises systems.
Obviously that's on the forefront here,
but it's just important for you to know
through that connectivity subscriptions are You
get like connectivity to for example your on-prem database.
>> That makes sense and it's good to see this stuff.
What's the stuff on the side and what's it doing there?
If you want to scroll up just a little bit more,
because I know those we went past that and I
hadn't seen before the boxes that
say Bastian and Jump Boxes have
either when self-hosted build agents, what's going on with that?
>> This is a little different from what we saw
before in the online reference implementation and
these are specific management resources which you now will
need when you're connected to your subs connectivity,
subscription to your on-premises resources,
to your lending zone and that usually
comes with a very specific restriction on access.
One of the other aspects we covered in
the connected reference implementation is that everything is
closed down networking wise so there's only one entry point to
the whole infrastructure from the Internet and
that's through Front Door, for the end-users.
But then no one else.
Not even administrators, are able to access the environment,
such as the AKS cluster directly,
because it's closed down using private links and
for doing deployments and for management tasks,
you need special resources on the same network, on the same VNet.
Azure Bastion is used to gain access to basically create
a temporary Jumpbox for
your infrastructure so that you can now
access your AKS cluster.
But then also built agents need to be
self-hosted in this scenario because they need
to live and sit in the same network as the cluster they're
deploying to, so that's why these new resources appeared here.
Because they're for management
and specifically for management of these
enclosed to resources or nonpublic resources.
>> The self-hosted build agents makes sense to me because I get
the idea that they have to also be able to drop
stuff on to stuff there.
But what I'm a little fuzzy about is in the last one,
much of what they were building
onto we also decided was ephemeral.
It could just go away and we can put new ones there.
Does that mean that there's some change
to ephemerality if that's a word,
how ephemeral things are?
>> Yes.
We still try to make as many things as ephemeral as possible in,
when we're talking about the stamps.
But the one thing that's usually can't be ephemeral anymore is the VNet,
so one of the things when you talk about
Azure landing zones and goes connectivity subscriptions,
It's typical that your platform team will provide you with
a pre-provisioned VNets and there might be peering in place,
that will be custom routing rules in
place or user-defined routing for
your workload to be able to access for
example what's called the
hub and the conductivity subscription,
but also the On-Prem
resources and those VNets you just can't
destroy every time because your platform team might not like
to recreate your peerings all the time for you.
There's a small distinction in there in how we deploy things.
In this case, we now need to deploy into
existing VNets and by the time we destroy stamps,
we need to clear the VNet and for example delete the subnets,
but don't delete the entire VNet.
This is exactly one of the things
what are called the corrected reference and [unintelligible].
>> I have one last question to ask you.
I'm looking at this diagram that has more things on it than
the previous diagram and I'm also noticing that I
control less things on this one.
What does that mean from sort of a reliability perspective,
if I'm not in control of various things,
like how do I cope with that?
>> This is a very good realization because
suddenly you're not alone in this world and you
depend on some other resources which are provided and managed by
someone else and if your application is mission-critical,
you really need to ensure that all
of these dependencies are considered
mission-critical as well and are designed to
be mission-critical with all the redundancies in place,
with high focus on reliability,
automation, and all of that so it is very
important to align across the organization
that everything on which
this workload depends is also mission-critical.
>> Cool so the last question I have is, last time you told me if I
wanted to get into this thing that I could go look at
a GitHub repo to see how this would get implemented.
Same deal for this reference architecture
and is that what you recommend I do to get started?
Where would I get started in
addition to the standard documentation?
>> Yes, indeed. First of all,
we still recommend if you haven't looked at
the baseline architecture that we talked about last time yet.
Go there first, just because it's much easier
to wrap your head around things and get started.
Because you don't have to go through
the hoops and for example deploying
your self hosted build agent and as we
just saw like the architecture, so it looks the same.
Once you've done that,
then you can head over to
the GitHub repo fully-connected reference implementation.
You'll still find the full Getting Started guide,
the full deployment automation
including this setup multiple agents and
management infrastructure there as
well and you can get you started on this one.
>> Cool. Well,
thank you very much for your time. I really appreciate it.
Let me switch back to host mode.
Back as host. I just want to thank you Sebastian.
I just want to thank you Martin and I want to
thank everybody for watching this.
I hope you will check
out the other episodes in the Azure Enablement show.
I hope you'll take a look at the resources we have
down below in this video and I want to thank
you all for joining us here on the Azure Enablement Show.
[MUSIC]