How to deploy frontends on kubernetes and how this can work with AWS Cloudfront?

Question

I have two frontends in which one is VueJS based and another is traditional server side rendered frontend. Both these frontends use cookies to identify users and user data is stored on MongoDB. I want to deploy 2 or more instances of one frontend (used by the public) and one instance of other frontend (used only by employees).

I also want to deploy public facing frontend static assets via AWS Cloudfront.

How do I deploy to Kube.netes above scenario? Do I deploy frontends to multiple Pods in Kube.netes?

Do I deploy Cloudfront to Pods on Kube.netes?

If I use AWS managed Kube.netes, EKS, does anything change in above scenario?

How do I deploy dynamic assets ( pulled from MongoDB database) on AWS Cloufront?

The Java Spring Boot APIs backend uses OAuth 2 to athenticate users (on VueJS frontend login form). VueJS frontend uses JWT access/refresh tokens whereas Spring Boot frontend uses a fixed API user on its backend to make API requests to API backend to get content to show to customers.

Answer 1

There seems to be some misunderstanding so let me clarify a couple of things first:

AWS Cloudfront is a Content Delivery Network (CDN) and has nothing to do with Kube.netes. AWS has lots of servers placed all over the world that simply replicate whatever static content it is that you want to share with your customers (eg logos, FAQs, etc.). By replicating it to pretty much every corner of the world, no matter where your customers are there will be one of those servers near them which results in faster loading times for them since they do not have to communicate to a server on the opposite side of the world.

Do I deploy Cloudfront to Pods on Kube.netes?

Therefore, one does not deploy Cloudfront on Kube.netes. All you have to do is tell Cloudfront about your origin server which basically is just a place your static assets are located at. Most of the time the simplest way to do so is to have these assets on an S3 bucket. Since there is a very good documentation on that part I will not copy every step of doing so in here. The "How to get started with Amazon CloudFront" site in particular guides you step by step through the setup and configuration of Cloudfront.

Now regarding Kube.netes:

Kube.netes is a container-orchestrator. This sounds more complicated than it is. In essence it means that it will manage containers for you ie restart failed ones, load balance between them and so on. containers are being defined as part of Pods. Although it is possible (and for certain architectural patterns necessary) to have multiple containers in one Pod, most of the time there will be a 1:1 ratio between Pods and containers. So every application will usually be deployed in its own Pod and consist of one container.

How do I deploy to Kube.netes above scenario? Do I deploy frontends to multiple Pods in Kube.netes?

That depends on your applications which you didn't give too much information on (aside from mentioning VueJS). In most cases VueJS is great for deployments on a CDN since it simply is static javascript. So unless there is a specific reason not to deploy them on a CDN there is no reason to deploy them onto Kube.netes.

However, if for whatever reason it has to be deployed on Kube.netes simply create a Deployment . A Deployment is a Kube.netes object that creates (ReplicaSets which then in turn create) Pods for you. When creating a Deployment (which is just a YAML file that you send to Kube.netes using kubectl apply -f <your-file> ) you tell it what the Pods would look like and Kube.netes will handle the rest for you. Once the Pods are created they are only accessible from within the Kube.netes cluster. To expose them to the outside world there are two options:

• Create a Service with type LoadBalancer
• Create an Ingress object (which then creates a LoadBalancer for you)

If I use AWS managed Kube.netes, EKS, does anything change in above scenario?

Using a managed Kube.netes (such as EKS) is by far the simplest approach since it can automatically create LoadBalancers with public IP addresses for you. If anything not using EKS will make things more complicated. Then you would have to manage your LoadBalancer and/or Ingress yourself (setting everything up yourself, maintaining it, ...).

Answer 2

What you are asking here is an architecture design question, and there are prerequisites to optimal cloud hosting. In a nutshell you need to be very strict about Separation of Web and API concerns .

SINGLE PAGE APPs

Web static content should be deployed via a Content Delivery Network (CDN), eg to 50 global locations. Using containers here is usually overkill and a system such as AWS Cloudfront will enable globally equal performance for web downloads without much technical effort.

COOKIE BACK ENDs

These require a runtime, so if you use a website technology, eg Spring Boot, you will be unable to use a CDN in the preferred way. AWS Cloudfront only hosts static content, not runtimes.

APIs

It is often preferred to deploy APIs and other back end components using Kube.netes, in order to keep code portable, and to host best of breed supporting components alongside the APIs.

TOKEN HANDLER PATTERN

APIs can perform cookie issuing for Single Page Apps, rather than needing a website back end. It is tricky, but see this article for an overview of how it works.

DYNAMIC ASSETS

In this model anything that needs securing is best managed via APIs rather than Cloudfront. Dynamic images etc could be pushed to Cloudfront at any time. It is also possible, if you have special reasons, to send API issued cookies to Cloudfront and use them in lambda edge functions.

EXAMPLES OF MINE

My Single Page App uses only the latest secure cookies in the browser, and is also deployed via Cloudfront - there is an online version you can run, and some blog posts that accompany it.

I also have an End-to-End SPA + API Kube.netes repo, and I will be deploying the API related parts of it to EKS later this year. On a development computer, web static content is provided via a container that runs the Express web server, though I will use Cloudfront as the web host when I deploy to EKS.

SUMMARY

Enabling optimal cloud hosting for web apps requires effort, partly because the current security best practice is for SPAs to use only the latest secure cookies in the browser.

You will have to use container hosting for websites, and you have the option to use it for SPAs, if that best fits your current architecture. With effort though, it is possible to use Cloudfront for SPAs secured by cookies.