Hi, and welcome to 'This is My Architecture'
I'm Andy and I'm here with Troy from Western Union.
Hi, Troy. Hi, thanks for inviting me today.
Absolutely. Can you tell me about Western Union?
So Western Union is a global leader in cross-border and cross-currency payments.
We're in about 200 countries today and about 500,000 locations worldwide.
Excellent.
I see an architecture on the board here,
but before we dive into this,
can you tell me the use-case you're trying to solve for?
So, really, Western Union being globally, and that includes our footprint within AWS,
so we're in multiple regions today with multiple different accounts
broken up into products and business units.
We really needed a way to deploy consistent architecture and patterns
across different locations, regions, accounts from a central location.
Excellent. Can you walk me through how you actually do that then?
So we start with our deployment engineer,
and what they do when we conceptualize a new account
or business unit or some need for a new account
is what they'll do is in the hub account, they'll deploy a cloud formation.
And the cloud formation is really doing four things.
It's really creating a Service Catalog portfolio for that specific business unit account.
It's associating products
that are going to be deployed later in that spoke account
underneath that portfolio.
It's creating a pipeline that's going to be used
for product updates in the later stage,
but it's also calling a Lambda, is the custom resource,
which is doing a lot of the magic behind the scenes.
So tell me about this Lambda.
What is it actually doing?
So when the portfolio and the products associated with that portfolio are deployed,
the Lambda will pick that up as a custom resource.
And what the Lambda does is it associates
with parameters the remote spoke account,
so what it does is it will actually create a share
with that Service Catalog portfolio that was created in the hub account.
So it will create a share there
and it will basically mirror that portfolio.
So what it does is it creates what is called as an imported portfolio.
Now, once you're in the imported portfolio,
the Lambda will also do a share,
so on the other side, you have to accept that share.
What it also does is it creates a local copy of that portfolio
inside of that remote spoke account.
The other thing Lambda does is it deploys...
a launch constraint specific to that remote spoke account
that allows you to deploy products...
from that hub account that will show up in the spoke account.
So it could be an EC2.
It could be a full tech stack.
Whatever we build from an architecture
and approve from an architecture perspective.
Excellent. So let's say I'm an application developer.
How do I fit into this workflow?
So after this underlying infrastructure build,
and you have the local share and all the capabilities are there,
really, from an app dev perspective,
and what they do is, basically from a GitOps perspective,
now that they can go into CodeCommit
which is the source for the CodePipeline,
update an existing product, maybe make a new version to the product,
maybe make some tweaks and changes,
maybe they want to move it from dev to QA, UAT, and prod, things like that.
They'll go in, update that template,
so when that CodeCommit change gets made, that basically triggers the pipeline.
Once the pipeline triggers, we do an S3 backup of that version
in case we need to backup.
We also do some Syntax validation.
We also do some security checking to make sure
they're not over-permissive IAM roles
or zeros in security groups, things like that.
After we move it to the deploy phase
in CodePipeline,
that will actually use the action as a target to target Service Catalog
to now go send that product after it met all the checks
back to Service Catalog,
and because the Service Catalog is now already shared into the remote account,
those products will show up as deployable in that remote spoke account.
And then we can only allow those certain developers
or deployment engineers, whoever it may be,
to just access that specific portfolio and those specific products for deployment.
Can you give me an idea of the number of products or versions of them?
So, for specific self-service products,
we're around maybe 700 or 800 for certain products.
For different tech stacks, which may cost you as an entire application,
we have less, and it maybe just moves through the different environments.
So it all depends on what we're trying to build,
what we're trying to deploy, and who we're trying to allow to deploy it.
Thanks for working us through it, Troy.
It's great to see how you're using Service Catalog
to deploy products from your hub account
into your spoke account,
and, additionally, understanding how products can be configured
and provisioned for the way that you need them for Western Union.
Thanks for joining us.
Thanks for having me. Absolutely.
And thank you for watching 'This is My Architecture.'