Recently I had interesting discussion with one of the architect about the future of our infrastructure. He kind of opened my eyes when we started discussion around
Datamesh Architecture
Nobody wants to worry about network anymore, wait for Network team to build the connectivity. Developers want to deploy their app and make API call to backend, other systems if needed. All is exposed or should be via API calls and for them it doesn’t matter if transport is public, private, vpn… When it comes to security they leave their trust in application or end to end encryption which means TLS/HTTPS (authentication and RBAC as important brick in the security wall defending our APP).
Luckily for me (as network architect) most of the companies are not there yet – it seems it will be the future but will take some time (years IMHO) to get there.
The result of that trend is … Developers build their environments on their own – fully isolated and at some point they wake up with simple request … eehhh we need to connect to some OLD system which is there in our legacy DATACENTER.
It can be even better. They deploy their resources thinking that they will never have to connect privately to other networks ending up with “overlapping” CIDRs. It is one of the biggest challenge to network team. There is a contradiction there – they want to keep treating them isolated but easily connected to other resources.
Private Link Service for rescue
This is very well known and well described service which allows 1 directional flows to get into our resources. Requester simply deploy Private Endpoint in their VNET and make all traffic sent towards it. It is on us to publish our resources properly.
What do we have here:
- Aviatrix Backbone – Transit with Firenet which provides connectivity to onPrem (can be ExR / VPN )
- x3 spokes – one dedicated to Private Link Services and 2 which host services Requestors want to connect to. They can be connected through Native type of attachment or using Spoke GW attachment
- [optional] Private DNS zone and respective virtual network links. It is not needed but might be convenient to have a common naming for PE. Private Endpoints are being deployed in 2ndary dedicated CIDR range typically not used by others so Private DNS zone can resolve names to the same IPs in all VNETs. If that is not possible requestor needs to handle DNS on his own.
Things to remember:
- LIMITATION 1 – If we want to publish service on ports (range) other than 80/443 we need to use Standard Load Balancer with backend pool being specified as NIC (IP address is not supported). That means the backend needs to be deployed in the same VNET where PLS are which is not our intention. To overcome that we have x2 NVAs which do DNAT and have loopback interfaces for each one of the Service. Standard Load Balancer doesn’t do SNAT so to make sure traffic goes back to specific NVA it has to perform SNAT as well. This NVA can be Aviatrix GW as well – it is NAT (both SNAT and DNAT) capable.
- LIMITATION 2 – Azure allows up to 8 PLS per Standard LB. If we need more just simply add new LB
- LIMITATION 3 – PLS allows up to 8 IPs which then are used for source NAT by PLS. That limits number of simultaneous connections to more or less 8x 64k
- We can use Application GW with Private link which does not have the above limitation of NIC as backend. It also performs SNAT.