Hosting frontend app on Cloud - Part I

Have you ever wondered what’s the best way of hosting your frontend applications on cloud in a way that is both scalable, highly available, and yet easy to maintain? If yes, continue reading this story to explore the possible options the cloud ecosystem has to offer.

Scenario

You have a react frontend app that needs to be hosted as a highly available and configurable service. This app interacts with some backend micro-service(s).

In this story, we are going to leverage the power of Kubernetes to deploy this app in a cloud-agnostic fashion.

Here’s the recipe

Step 1: Containerisation

The first step is to build an image for your application. Here you need to define a Dockerfile that packages all the dependencies along with your code and bakes an immutable artifact a.k.a. image.

Here you can either use a node-express server that serves the javascript bundle on a port or use Nginx as a reverse proxy. I am using the latter in this example.

Containerise using Nginx server

Dockerfile

Now, build the docker image and push it to the registry

docker build -t images.my-company.example/sample-react-app:v1 .
docker push images.my-company.example/sample-react-app:v1

Step 2: Container Orchestration

Now that an image has been baked, we need to deploy the same on Kubernetes. Let's start by defining the following k8s resources -

• Deployment - This ensures the frontend-pod is always running

K8s Deployment

• Service - Pods are mortal and so the IP addresses of frontend-app are not static. We need a mechanism to keep track of the frontend pods and so we define a service for this purpose

K8s Service

This makes the frontend accessible from within the cluster. Verify using a curl pod

kubectl run curl --image=radial/busyboxplus:curl -i --tty
[ root@curl-131556218-9fnch:/ ]$ nslookup sample-react-app

• Ingress - The application is visible within the cluster only. In order to expose the app to the outside world, we need to define some ingress configurations. For the sake of brevity, I am omitting futher details, feel free to look at Kubernetes ingress and supported controllers instead.

We are using Istio service mesh and ingress controller for our cluster. Here is the snippet to configure virtual service-

Istio Virtual Service

Step 3: AWS infrastructure

To expose the service (frontend app deployed in k8s) to serve traffic, following AWS resources are required to be created-

1. Route 53- Create an Alias type record to route user traffic on http://foo.example.com/ to AWS application load balancer
2. ALB then forwards traffic to the istio-ingressgateway Nodeport service on the target group of EKS nodes
3. Ingress gateway then routes the traffic to frontend-service based on the rules defined by virtual service
4. frontend-service then forwards the request to one of the pods

Advantages of this approach

• Deploying on kubernetes ensures we are cloud agnostic and not locked-in to any vendor
• This supports build once deploy anywhere principle, wherein a single immutable artifact is promoted to multiple environments, as the backend configurations can be passed as environment variables instead of creating a separate build for each environment

However, there are a few limitations to this too. I recommend reading Part II (will be published soon) to understand them better.