>> Hey, friends.
On a recent episode of Azure Friday,
we took a look at Azure Lighthouse,
which provides a single control plane
to view and manage Azure at scale.
But some organizations have requirements that are more complex,
such as those in regulated industries like finance.
So, how do you enable Developers
to onboard applications in Azure with
self-service capabilities while still
exercising control over an expanding cloud landscape?
Geoff is here to show me how Fidelity,
one of the largest financial asset managers in the world,
is adopting Azure at scale with thousands of developers as
part of their multi-cloud strategy - today on Azure Friday.
[MUSIC]
>> Hey, friends.
I'm Scott Hanselman,
and it's Azure Friday.
I'm here with Geoff Langfield from Fidelity.
I think you may be our first customer.
We've had vendors on,
but you're building real stuff with Azure.
So thank you for being here.
>> Thank you very much for having me.
>> You work in the Cloud Enablement or the Azure Enablement group,
and you're supporting a huge amount of technologists.
How many people are
thinking about the Cloud at Fidelity right now?
>> We have approximately 14,000
technologists across the entire organization.
>> Wow, that is a lot of pressure.
So then there's a Cloud Enablement group
that is setting them up for success.
What does that mean to enable them?
>> The charter of the team is really to help accelerate.
But again, because we work in a regulated industry,
we go to do things in a secure and a compliant manner.
So our team's focus is ensuring we have
governance standards with our deployments
and we're doing things in a secure manner,
and that we look to abstract away some of
the complexities of enabling
services in Cloud resources to align with those standards.
>> When I was working in finance many years ago before the Cloud,
that balance that we are in
a regulated industry, we're doing work,
whether it be with the Fed,
or with we're moving money around,
we cannot move fast and break things.
But there was so much cool stuff
happening in technology and that tension
between trying to set Developers up for success,
use new cool technologies,
but also do it in a safe and secure way has been a real challenge.
It sounds like you're trying to be
able to do both of those things simultaneously?
>> Yes, so we do have an environment where we allow
our Developers to explore a little bit more freely,
that's not connected to our On-Premise network where they
can go explore new services and play around with them.
But when they're ready to start doing
application development and connect back to our environment,
that's where we want to be a little bit more secure and
go through reviews of services and things like that.
>> Okay, that makes a lot of sense and that
allows them the best of both worlds.
Then I assume that you also provide
a prescription for things like security, reviews,
and all those kinds of things so
that when it's time to go into production,
there is a path for people.
>> Yes, so with the example with a service,
we have a detailed security assessment of that service.
We take a look at the service from a data perspective,
so protection and encryption.
We look at it from identity and access management controls,
network isolation, logging, and monitoring to name a few things.
>> So then to support all of these Developers,
your enterprise Cloud computing group built
an automation framework to allow
those folks and business partners to onboard applications.
You've really automated a lot of things,
not a lot of manual work happening here.
>> A hundred percent correct.
So the framework, we call it Azure Automation framework,
very creative, AAF for short.
It's an event-driven architecture
and it's built entirely on Cloud-native services.
Some of those services are Azure Function,
Web Apps, Logic Apps,
Event Grid, to name a few.
>> Wow, okay. So then all of this sets people up for
success so that they might onboard more quickly.
Can you show me a demo of what that might be like?
>> Yeah. So let me log on to the user portal.
So I'm in the AAF user portal right
now and I'm going to put in a product line number.
This won't mean anything to people watching this,
but it's a way that we organize
the applications within our environment.
So I'm going to go to the subscription where I
want to enable a service.
So in this demo, we'll enable Azure Functions.
I'll go to the resource group.
The resource group is where we're
assigning our back roles for services.
As you can see on the screen,
we have services that have already been enabled,
so some of these services,
a user may have come to the portal and requested access.
Some services, we give by default.
We call them birthright services.
Then you see below,
these are available services where a Developer
or a user on an environment would come and request access.
Again, mentioned earlier, we have that detailed security review.
After that review has been completed,
we'd make the service available within
our AAF environment, and now, a user can come and request access.
Abstracting away that complexity
also does a couple of things for us.
It ensures that we can implement,
at least, privilege model as it relates to configuring the service.
It also ensures that we deploy
services in a consistent compliant manner.
So I'll go next to the "Request" button.
See I'll be asked a couple of questions.
I'm just going to take the defaults and I'll hit "Request".
Now, you can see that the services and the requested service state.
Now, from a Developer's perspective or a user's perspective,
this is where their responsibilities end.
They come into the portal, they hit "Request",
and now, they're just going to wait for the service to be enabled.
But so what I'm going to do now is I'm going to
show the workflow of what's happening behind the scenes right now.
Again, a user would come into the AAF portal,
they'd find the environment where they want to enable the service.
Again, the AAF framework, it's event-driven,
so we have a combination of
Microsoft native events as well as custom events.
In this particular example,
where a custom event was generated
and that event is associated to a service enablement runbook.
What's happening within the runbook right
now is it's assigning the RBAC role for functions,
it's enabling the resource provider,
and it's also doing
a check from a network configuration perspective,
because we're using the VNet Integration option
of Azure Functions.
There's some network configurations that have to happen.
So in this particular example,
it'll check to see if there's already a subnet for the service.
If not, it'll go check the VNet to see if there is
addressable address space within the VNet to create a subnet.
If both of those checks come back and are no,
then it's going to call in a Logic App endpoint.
What this first Logic App in step 1 is doing,
it's really just collecting metadata about the request.
Now, because sometimes making
network changes can cause a service interruption,
all of these stuff on
the left-hand side of the screen up to step 1,
these are tasks that are going to happen throughout
the business day at any point in time, 24 by 7.
But the tasks that are going to happen on
the right side of the workflow,
those are things that are going to happen
during a predefined change window.
So what ends up happening?
So let's fast forward.
Say, it's 7:15 tonight,
the logic app in step 2,
that's going to kick off and that's more or
less just a queue manager for us.
The real work starts with the logic app in step
3 called VNet Resizing and what this logic app is doing,
it's going to double-check again.
Let's make sure we don't have
a subnet dedicated for our functions already.
Let's check the site again,
and the reason that we're
double-checking thing is that
these components are callable by other processes.
So we don't just use it for service at a moment,
we can use it for other network onboarding activities
or application onboarding activities.
Now, again, after it checks the subnet and it checks the VNet for
addressable address face of both of those checks come back no,
will actually call an Azure Function.
What this Azure Function is going to do is make a call to
an internal service that will go ahead and get a CIDR block.
Now, we're ready for step 4,
and this is where the breaking change is going to happen.
In order to expand a VNet,
you actually have to break peering.
In our particular environment,
when we break peering,
we're going to break peering with
the express route that's going to cause
a network interruption back to our On-Prem environment.
So we want to do that again during a predefined change window.
We'll go ahead and break peering,
we'll grab that site or block from step 3a,
we'll expand the VNet,
we'll reappear and now, we're ready
to create the networking for Azure Functions.
We'll go ahead to step 5,
we'll create a subnet,
we'll assign an NSG rule set
that's specific to this service, and then finally,
we'll assign a RBAC role to allow users
once they have deployed
Azure Function apps to integrate with the VNet.
If I come back to the user portal
in an environment where I did this last night,
you'll see now Azure functions shows up as an enabled service.
Again, just to conclude the framework again.
So what the framework is allowing us to do is,
again, it's allowing us to deploy
resources in a secure and compliant manner,
again security and compliance is very important to us.
It makes sure that our deployments from Cloud resources
to services are done in alignment with our governance standards.
As you can see from an end-user or a Developer's perspective,
enabling Azure Functions was as easy as clicking a button.
Now, if the Developer had to do that on their own,
there's a lot more configurations that
they'd have to do from a networking perspective,
and for some Developers it might be out of their comfort range.
Again, they just come to a user portal,
hit "Requests," sit back and
just wait for the service to be enabled.
>> Are those requests something that a human has to okay?
That a person has to say,
I think that this is a good idea,
or is this entirely automated at this point?
>> It's entirely automated.
>> Interesting, and then how
complicated was it to decide how things should be?
This is best practices for Fidelity's Cloud enablement,
but other companies might be
different with the way you describe how you do your networking.
I assume that enterprise architects all
got together and thought about how we
want these things to exist
within the larger space inside of Fidelity.
>> Yes, so from a networking perspective,
network isolation and private networking is very important to us.
We would like to keep things on
our own internal private network as much as
possible from a security perspective around the service.
Again, review the service for
the two things I mentioned early, network data.
Now, from an RBAC model perspective,
what we wanted to do is simplify how we use services.
So we have essentially a one-to-one model.
A service has an RBAC role,
it's the same role that's used across the environments.
So from a central perspective,
we understand the permissions people are
using when they use services and we also understand
how that service is being used, at least, from
a configuration perspective across the whole environment.
>> RBAC, of course, for folks that may be new to
Azure Role-based Access Control,
the idea of least privilege.
Everyone should be able to do what they need to do, but no more.
If anyone gets into trouble
and gets more access or bad actor gets involved,
you want that bad actor to only be able to do what
that role is allowed to do, which is really smart.
You've codified all of that,
you've formalized it so that the Developer
thinks less about infrastructure and
thinks more about the business problem at hand.
>> Absolutely, 100 percent right.
>> That's fantastic. How much do you think that
other companies should do this
themselves versus this should be
something that's built into Azure?
Because Azure does have things like Lighthouse
and other ways to formalize this.
Why did you feel that you needed to do it not
entirely yourself but this level of customization?
>> I think from,
let's say, a Lighthouse perspective,
that it wasn't going to meet the enterprise scale that we needed.
But also, we have very specific governance requirements and
policies and standards that
I'm sure aren't necessarily unique to Fidelity.
But financial services, they have
certain things and regulations they have to follow.
So we needed something that was flexible and
extensible so we could align with what we wanted to do.
>> What's cool about it is that
it appears that if you look at things
like Runbooks and Software Defined Networking,
you used Azure to work with Azure to manipulate Azure.
You created a lot of software,
but you, basically, had a bunch of
lego pieces you had to play with,
link together and make the Cloud, your Cloud,
the Fidelity Cloud that follows
the security guidance and
prescriptions that you're regulated environment
requires which is pretty fantastic.
>> Yeah, 100 percent Azure services
were used in this framework and solution.
>> Cool. Well, I hope that people can
learn more about this somewhere because this is internal stuff.
Like I said at the beginning of the show,
you are our first customer to come on Azure Friday.
Do you think that you'll be talking more about this publicly?
Is this going to be something that I could read
a white paper on perhaps in the future?
>> Possibilities are open for that in the future
and our organization in general is
looking at more open source being more involved in the community.
So I think that's absolutely a viable option in the future.
>> Fantastic, I really appreciate that.
I'm learning all about how to enable at-scale
adoption of Azure Services for
really large development communities like those at Fidelity.
Thank you so much, Geoff Langfield
for chatting with me today on Azure Friday.
>> Thank you very much, Scott.
>> Hey, thanks for watching this episode of Azure Friday.
Now, I need you to like it,
comment on it, tell your friends, retweet it.
Watch more Azure Friday.
[MUSIC]