A company is migrating a legacy application that relies on multicast and broadcast traffic for service discovery and inter-service communication. The application needs to run in Azure without significant code changes. Which Azure network design consideration is crucial for this migration?
- AUtilizing Azure Load Balancer for traffic distribution
- BConfiguring Network Security Groups (NSGs) for traffic filtering
- CReplacing multicast/broadcast with explicit IP addressing or a service mesh
- DImplementing Azure Private Link for service communication
Show answer & explanationAnswer & explanation
Correct answer: C. Replacing multicast/broadcast with explicit IP addressing or a service mesh
Azure virtual networks do not natively support multicast or broadcast traffic. For legacy applications relying on these protocols, the most crucial design consideration is to adapt the application to use modern cloud-native communication patterns, such as explicit IP addressing, DNS-based service discovery, or a service mesh, or to encapsulate the legacy traffic if re-architecting is not an option. Without this, the application will not function correctly in Azure.
Why the other options are wrong
- A. Azure Load Balancer distributes traffic but doesn't address the underlying multicast/broadcast communication issue.
- B. NSGs filter traffic but do not enable unsupported multicast/broadcast protocols.
- D. Azure Private Link is for private access to PaaS services, not for replacing multicast/broadcast for inter-service communication.
Azure VNet Multicast/Broadcast
Azure Virtual Networks (VNets) do not natively support multicast or broadcast IP traffic, which is a common challenge when migrating legacy applications.
- Multicast/broadcast not supported in Azure VNets.
- Legacy apps relying on it need adaptation.
- Solutions include explicit IP, DNS, service mesh, or encapsulation.
- Crucial for network design when migrating such apps.
Memory trick: Azure VNets don't 'broadcast' or 'multicast' your old signals.