You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are seeking to understand Microsoft's decision to use AKS ACI in adSelection. Did Microsoft consider alternate approaches such as AKS CC, and if so what tradeoffs led to the choice of AKS ACI? During the WICG call on Jan 9, we were told by Slava & Isaac from Microsoft that the decision to use AKS-ACI was due to some security considerations. Can you shed more light on this? Thanks in advance.
The text was updated successfully, but these errors were encountered:
Were general availability readiness timelines a factor in the decision to use AKS ACI? Could you share more detail about any of the GA timelines, including about AKS ACI Virtual Nodes v2?
I have asked Learn questions about the timelines (AKS CC and AKS-ACI) that can serve as additional points of reference.
In the WICG call on 1/23, Kapil Vaswani and Ken Gordon verified that Virtual Node 2 is considered GA and is supported as a GA'd product.
AKS ACI was chosen over AKS CC largely due to maturity. We discussed the fact that AKS-ACI is unable to use kube-proxy to take advantage of AKS client-side load balancing and, although no clear next steps to investigate this were established, it seems to be a potential route to decrease the internal load balancing costs incurred by using ALB for BFE/SFE -> Bidding/Auction communication.
We are seeking to understand Microsoft's decision to use AKS ACI in adSelection. Did Microsoft consider alternate approaches such as AKS CC, and if so what tradeoffs led to the choice of AKS ACI? During the WICG call on Jan 9, we were told by Slava & Isaac from Microsoft that the decision to use AKS-ACI was due to some security considerations. Can you shed more light on this? Thanks in advance.
The text was updated successfully, but these errors were encountered: