Home / server / Questions / 1001535
Accepted
serverstackqns
Asked: 2020-02-04 02:53:43 +0800 CST

Architecting for microservices application

  • 772

I am not sure whether this is a right forum to ask question with respect to the infrastructure architecture. But posting the question hoping so:

One of my customer has a web application which is developed in the latest technology of micro services. Kubernetes is the underlying layer. And on top they are using CDN, API hosting etc. Now, from the perspective of public cloud, (azure or AWS), how can I architect the infra here? I have couple of questions with respect to the services that they use. For simplicity, I will talk from Azure POV. It's decided to use the following components from Azure:

Azure CDN, Azure application gateway, Azure FrontDoor.

I am confused on the call flow with these services. From the client (like web browser), when there's a request for the application, ideally the static contents need to be responded back by Azure CDN and the other dynamic contents by checking the container or server. So,this is what I assume on the call flow:

Browser -> Azure Front Door -> Application Gateway -> API Management Microservice -> Other Microservices -> Azure CDN -> Browser

Is this correct? If not, can you guide me to understand a better architecture. Any help would really be appreciated.

infrastructure architecture docker kubernetes azure

1 Answers

  1. Best Answer

    Ok, first up you've got a few different services doing the same thing there so you want to evaluate whether you need them all.

    • Azure CDN and Front Door both offer the same local point of presence and caching, so you really only need one or the other
    • Azure Front Door and App Gateway both provide Layer 7 load balancing and Web Application Firewall, so you may not need both. App GW does have some extra capabilities like vNet attachment and K8s Ingress so there may be an argument for both

    Whether you choose Front Door or CDN then they want to be at the front of your stack. Ideally you want traffic to hit the FD/CDN, get a cached response and that be the end of the request.

    If you can't serve from Cache then now you need to get your traffic into Kubernetes, so your front of stack resource (CDN or Front Door) is now going to forward on to however you expose your Kubernetes cluster to the outside world. This could be App Gateway if you decide you need it, an external load balancer, or Azure API Manager if your using that to expose API's.

    Front Door is a global service that is not vNet attached. Your Kubernetes cluster is vNet attached so you need a way to expose your Kubernetes resources to Front Door. This can be done with App GW, but it adds extra expense, you can also just setup your Kubernetes ingress with an Azure Load Balancer with a public IP and then have front door talk to that.

    If you get rid of App GW then you will need another ingress controller running in your cluster such as NGinx, Traefik etc. Alternatively you could keep App GW, but then I would using CDN rather than Front Door.

    Front Door and CDN use the same endpoints and so offer the same caching.

    • 2