✨Glotixz – Ultimate Stack

Ultimate Stack [Glotixz] is a Event Driven Microservices Ecommerce App deployed and running on Kubernetes with istio as the service-mesh and cloudnative serverless components by knative and deployed to Kubernetes via Gitops pipeline with ArgoCD and the kubernetes platform is built as Infrastructure as Code [IaC] with Terraform .
The complete Glotixz microservices apps are developed and deployed in CIVO Kubernetes platform.

✨✨✨Note 📚:

The deployments are optimized only for staging k8s cluster only and not yet for production cluster.

✨✨✨ Overview 🍁:

Ultimate Stack [Glotixz] is a Typescript/Javascript based fullstack ecommerce app which can be used to sell tickets for events by users registered in the app and payment is fullfilled by stripe.
The Backend services are a microservices built with Expressjs + Typescript which are event driven systems with the nats-streaming-server as the event-bus publishing/delivering events from and to the services respectively.
All the backend serivces along with their respective databases and frontend is deployed in kubernetes by Gitops via ArgoCD
The complete overview of the Architecture and workflow:

✨Tools used during development and pre & post deployment 🛠️ :

vscode – Code Editior of choice
okteto cli – cloudnative dev container management tool
kubectl – CLI to interact with Kubernetes Cluster
kubens & kubectx – awesome tools to help with switiching namespaces and cluster contexts respectively with ease
istioctl – CLI to install and interact with istio in the k8s cluster
kubeseal – CLI to create sealedsecrets by interacting with the k8s cluster
terraform – To provision k8s cluster and other resources with the preferred providers via IaC [Infrastructure as Code]
kn – CLI to create/interact with KNative deployments in the k8s cluster
argocd – CLI to interact with argocd resources in the kubernetes cluster
draw.io – to create the architecture overview diagram
Excalidraw – used to sketch out various simple architecture decision diagrams

✨✨ Cloud Native development ☸️:

This project is entirely built with cloud native development process on kubernetes with the use of the okteto cli.
Okteto cli make the development process ease with the use of the okteto.yaml manifest file as it does the abstraction of connection between the local IDE/Editor (vscode was my preferred editor).
Every service folder will have a okteto.yml manifest file. This file can be generated with followig command:

$>> okteto init

The okteto init command will scan the available deployments in your Kubernetes namespace, and ask you to pick one deployment where we want to do our development.

✨✨Note 📚:

Okteto CLI will work only if we have the kubernetes config file set in the ~/.kube folder or KUBECONFIG="/Foldername/config" as a environment variable.

the okteto.yml file will be like the following:

#this it the developemt-service name we can set which will reflect in the k8s environment dev container in the deployment.

name: mcs-auth-service 

# autocreate when set to true will create a new deployment if it's not present already.

autocreate: true 

# this is the container image used inside the development container.

image: quay.io/narendev/fishnode:1.0

# the first command which to be executed when the dev container is up.

command: fish

# This will set which folders & files to track and sync for the new changes happens in the dev container to the local files respectively. [The synchronization is completely taken care by the okteto cli (which is awesome !!!) ]

sync:
- .:/usr/src/app

# These are the ports forwarded from the container to the local system

forward:
- 9229:9229
- 3000:3000
persistentVolume: {}

# Annotations which needs to be applied on the container while deploying can be mentioned under this `annotations` section

annotations:
  sidecar.istio.io/inject: "false"

Now, we have the okteto.yml file, now run the okteto command to start/stop the dev container in the kubernetes:
To starting the dev container:

$>> okteto up

To stop the dev container:

$>> okteto down

✨✨Note 📚:

Okteto have a vscode extension which will help a lot by streamlinging the dev process by just few clicks.
https://marketplace.visualstudio.com/items?itemName=okteto.remote-kubernetes

✨✨ Infrastructure as Code with Terraform:

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.
The kubernetes clusters is created with the terrafrom.
It’s a good practice to have a dev, staging and production clusters to streamline the development , testing and production deployment process aligned respectively.
These different clusters can be created with ease by using terraform and utilizings it workspace feature to create many cluster with the same config in the provider of our choice.
https://www.terraform.io/docs/language/state/workspaces.html
Version of terraform used:

$>> terraform version
Terraform v0.15.0

The terraform IaC codes is in the ‘./Terraform’ folder.

✨✨ Frontend:

The Frontend for the Glotixz app is created by using the NextJS – a reactjs based Javascript framework.

✨✨ Details of the Backend MicroServices ⛓️:

The Backend services are written in Typescript with Expressjs web framework which runs on the NodeJS v14 runtime.
There are a total of 5 microservices which handles one core group functionality each respectively. The microservices are:

Auth-Service
Expiration-Service
Orders-Service
Payment-Service
Ticket-Service

All the services endpoints are covered with tests via Jest testing library.

✨ Auth-Service :

This microservice have endpoints for the user creation signup and authentication of users like signin,signout and currentuser. The authroization is done via creation of JWT tokens which are sent via Cookies Session-Cookies which is used by the other microservices to know about the user access and authorization privilages.The auth-service uses a MongoDB as its’ database which is also deployed in the cluster as a statesfulset resource.
The Auth-Service folder have the code for the Auth-Service microservice.

✨ Expiration-Service:

This microservice endpoints are used internally by other microservices and not exposed to the users. This microservice keeps track of the expiraiton time and sends a event to the event-bus when the expiration time for a order is reached. This microservies use a redisDB as its’ database which is also deployed in the cluster as a statefulset resource.
The Expiration-Service folder have the code for the Expiration-Service microservice.

✨ Orders-Service:

This microservice have endpoints for the order creation, listing , deleting and showing a particular order. The Orders-Service will expect to receive the Authentication Cookie to validate if the user is authenticated to access the protected routes along with the request. The orders-service uses a MongoDB as its’ database which is also deployed in the cluster as a statesfulset resource.
The Orders-Service folder have the code for the Orders-Service microservice.

✨ Payment-Service:

This microservice have endpoints for fullfilling a Orders’ payment with Stripe. The Payment-Service will expect to receive the Authentication Cookie to validate if the user is authenticated to access the protected routes along with the request. The payment-service uses a MongoDB as its’ database which is also deployed in the cluster as a statesfulset resource.
The Payment-Service folder have the code for the Payment-Service microservice.

✨ Ticket-Service:

This microservice have endpoints for the creation,listing, updating and showing tickets. The Ticket-Service will expect to receive the Authentication Cookie to validate if the user is authenticated to access the protected routes along with the request. The Ticket-service uses a MongoDB as its’ database which is also deployed in the cluster as a statesfulset resource.
The Ticket-Service folder have the code for the Ticket-Service microservice.

✨✨ Swagger OpenAPI spec:

The Backend services endpoints are documented with Swagger OpenAPI spec Version 3.0.3 and hosted with swagger express UI in the service itself.
Links to the Backend services Swagger Docs:

✨✨ Note 📚:

The following VS Code extension OpenAPI (swagger) Editor was very useful while writting the swagger specs.
https://marketplace.visualstudio.com/items?itemName=42Crunch.vscode-openapi

✨✨ Common Modules Published to NPM 📁⬇️⬆️:

Most commonly used methods, middlewars and object model types are abstracted and created into a javascript library which is in the ./Library/common folder.
This common module is published into the npm as standalone package which can be downloaded by our microservices.

#  with npm
$>> npm i @wowowow/common

# with yarn
$>> yarn add @wowowow/common

here is the package url: https://www.npmjs.com/package/@wowowow/common

✨✨ EventBus ◀️↔️▶️:

Nats-Streaming-Server is the event-bus of choice for the Glotixz fullstack event driven microservices app.

NodeJS NATS-Streaming-Server client is used in the each of the microservices to publish and listen to the events respectively.

$>> npm i node-nats-streaming

#   or  

$>> yarn add node-nats-streaming

✨✨ Note 📚:

while using NATS-Streaming-Server with istio servicemesh, the names of the exposed ports in the kubernetes service for the Nats-streaming-server deployment must follow the istios’ port naming convention as mentioned in the Istio docs.
During deployment this have caused a issues which led the backend services not working as intented as the istio-side cars blocked the incoming/outing requests from the eventbus.
nats-io/nats-operator#88

✨✨ ServiceMesh ✳️:

Istio is the service mesh chosen for this event-driven microservices.
For now, the PeerAuthentication is set in mtls PERMISSIVE mode. [which can be upgraded to STRICT mode if required.]
Installation yamls for istio is in the “./kubernetes/staging/cluster-setup/istio-install/install-manifest-istio.yaml” file.
The above yaml is generated via the istioctl CLI:

$>> istioctl manifest generate --set profile=demo > install-manifest-istio.yaml

✨✨ Note :

The istio version installed in the cluster is:
$>>istioctl version

client version: 1.9.0 control plane version: 1.9.0

Here is the routes overview seen in the Kiali dashboard graph ,which also show the traffic coming into the cluster.

✨✨Note 📚:

Kiali is one of the observability add-ons which is compatible with istio, the following metrics of routes and it’s traffic is collected via the sidecar injected into the pods of the deployment.

✨ Reasons for choosing istio:

Istio comes with a traffic management solution and have routing ingress gateway called “Istio IngressGateway” which is powered by Envoy , it is a powerful L7 Proxy which acts as the ingress controller
Routing for Services can be created by utilizing VirtualService and Gateway API object exposed by Istio.
Istio have automatic side-car injection to all the pods in the deployments and statefulsets in a namespace, if that namespace has a Labeled istio-injection=enabled.
Istio have powerful mutual TLS support which can upgrade all the traffic from http to https and istio will take care of the issuing and maintaining the tls certificate with ease.
Istio’s authentication and authorization policies can be used to restrict and enable communication between containers in the pod as per our intented wish. With AuthorizationPolicy set on a workload, we can lock down which containers can make network requests and which can’t.
Istio is one of the supported mesh used by KNative.

✨✨ Note 📚:

To disable sidecar injection in one or many pods on the deployments in the namespace, we can add…