Hi, welcome to 'This is My Architecture'.
Today I'm with Damien from Nexthink.
-Hi, Damien. -Hi, Ross.
So what can you tell us about Nexthink.
So, Nexthink is a global leader in digital employee experience.
We provide IT teams with a certain number of capabilities like real-time analytics, automation,
and employee feedback across endpoints.
All right, and what part of Nexthink are we going to be looking at today?
So today, we are going to look at Nexthink Experience, so that's our cloud project.
And here, as you can see, we have multiple pieces and multiple region.
So here, I have region A, with some components, region B, and region C.
And we have a specificity, our solution is based on the Multitran platform.
And for each customer, we associate the region.
This means that, for example,
some customer or customer will be deployed in region A, could be deployed in region B, and in region C.
So of course, the challenge for us is to route the requests, the HTTP requests,
as soon as possible to the right EKS cluster where the HTTP endpoint is deployed.
So, to minimize the impact in terms of latency,
we use Route 53 and the latency-based routing
to retrieve the DNS towards the IP addresses of our API Gateway.
So, let's say for example, this user will request the IP address, will call directly the API Gateway.
And then we need to figure out where do we need to deploy or to route this request.
So, the API Gateway will access a Lambda function,
will go directly to DynamoDB to make the association between the tenant UID and the region it belongs to.
Okay, I see with DynamoDB here, it doesn't seem related to any particular region. Why is that?
Well, that's a good question.
Actually, we are using global table in DynamoDB.
So this concretely means that it's available for all regions.
Okay. And what comes next?
Yeah, then as soon as we have the association between the tenant UID and the region,
we can route the request to the right EKS cluster.
So, in this case, the Lambda could be either in the same region, or we need to go across region.
And in this case, we are reusing or we are using the Transit Gateway.
Okay.
Then the Transit Gateway, if for example, we say this customer is deployed in the EKS cluster in region C,
we will use the intra-peering communication between the two Transit Gateway,
and the call will be routed in the EKS cluster here.
Okay, so theoretically, that customer could be in region B.
So from this, we can say the customer is only associated with a single region.
-Yeah. -That obviously makes sense.
Can you give me an example of a customer that would have their lowest latency
would be to region A, but they happen to be in region C?
Yeah, that's a good question, actually.
We have a lot of customers we have deployed across the world,
and some of them have offices in Asia, in Europe, or in the US.
And during the design phase, we say, "Okay, it will, I mean, everything will be deployed
in region C in terms of data storage and EKS endpoints".
But, of course, if I'm not in the same region, because I belong to another offices,
then in this case, I need to go through this process to be able to join the right region.
So, that's more or less related to the size of our customer.
All right, fantastic.
Damien, all right, thank you for coming today and sharing this architecture with us.
It's been very interesting.
Thanks a lot, Ross.
And thank you for watching 'This is My Architecture'.