Welcome to another episode of 'This is My Architecture'.
Today I'm joined by Rahul from Salesforce.
Hi, Rahul. Hey, Adrian, how are you?
I'm good. Well, everybody knows who Salesforce is, you know,
you're one of the pioneers of software as a service companies.
Tell us a little bit about how customers are looking to connect
their cloud workloads to Salesforce and why.
Sure. So, Salesforce has a lot of customer data
and customers would like to connect from Salesforce to public cloud infrastructures
for their processing of data,
for example, machine learning, and similarly they would like to
back up some of the data from Salesforce to a public cloud, or vice versa.
And that's where they would like to create a connection between Salesforce and a public cloud.
So lots of use cases why you want to exchange data,
but there's a bit of work to set it all up, and you simplified this,
so, walk us through what you've built.
Sure. So what we have built is Private Connect, which creates a private, secure
and compliant connection between Salesforce and a public cloud.
So in order to achieve that, customers need to log in to Salesforce UI
and enter their PrivateLink details, which establishes the connection between
Salesforce and the customer VPC.
So let's start with customer going into Salesforce UI and entering the details.
This helps him with setting up a private connection and as part of the set up,
a connection set up request is sent to the control plane VPC API gateway.
This API gateway forwards the request to the Lambdas behind the API gateway.
The Lambda here helps in setting up of a PrivateLink connection
between the transit VPC and the
customer's PrivateLink service.
There is an SNS, as you see in the picture.
This SNS gets a notification of any of the PrivateLink state changes.
So, I see you've used an API-driven serverless pattern here, to be able to provision it, very scalable.
So once that PrivateLink connection is established to the customer VPC,
what happens next?
Once the connection is set up, the customer is ready to send traffic,
as part of the traffic being sent from Salesforce to AWS,
a VPN tunnel exists between Salesforce DC to Salesforce AWS VPC.
This is a site to site VPN with a Salesforce owned enterprise security encryption.
The customer data is sent via this encrypted tunnel
to the Transit Gateway.
From the Transit Gateway, the data is forwarded to the EKS,
which has a bunch of connection forwarders running as a container.
So why did you have to build connection forwarders?
Connection forwarders are used to identify the customer based upon the metadata
present per customer.
So based upon this metadata, the traffic is forwarded to the appropriate PrivateLink.
So this EKS service hosting connection forwarders, is a multi-tenant service.
Right, so you don't have to have multiple Transit Gateways for every single customer.
That's true. I understand.
So once the secure connection is established,
what happens when I don't need it anymore?
The customers can go back to their Salesforce UI and do the connection tear down process.
There, the connection set up which we did earlier,
this connection, gets torn down, as well as the customer metadata,
which has been stored in DynamoDB.
That also gets removed.
Great, so a lot of automation is going on
and you've got a really scalable solution here.
What benefits are your customers seeing by using PrivateLink?
With Private Connect customers get private connection between Salesforce and their cloud service
as well as secure connection, which is compliant as well with PCI,
HIPAA, and other industry-leading certificates.
The other biggest benefit is, the ease of set up.
There, customers need not know the networking details to set up an internet gateway,
route tables or NAT devices directly. They can go to their friendly UI
and set up connection between Salesforce and their cloud VPC.
Great, thanks for sharing your architecture with us today. Thank you.
And thank you for joining us on 'This is My Architecture'.