The extremely short story of how I converted a k8s application to Avassa

Converting an application from Kubernetes to Avassa might sound like it has the potential of being a time-consuming maneuver. So when one of our customers asked if it would be possible to port a demo application from Kubernetes to use it in Avassa’s platform, I thought it was a great opportunity to find out.

Keep Reading: Avassa as an alternative to Kubernetes at the edge

The application that will be converted is a demo application that allow users to vote on either cats or dogs. The application’s user interface looks like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-vote-back
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-back
  template:
    metadata:
      labels:
        app: azure-vote-back
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": linux
      containers:
      - name: azure-vote-back
        image: mcr.microsoft.com/oss/bitnami/redis:6.0.8
        env:
        - name: ALLOW_EMPTY_PASSWORD
          value: "yes"
        ports:
        - containerPort: 6379
          name: redis
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-back
spec:
  ports:
  - port: 6379
  selector:
    app: azure-vote-back
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-vote-front
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-front
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  minReadySeconds: 5 
  template:
    metadata:
      labels:
        app: azure-vote-front
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": linux
      containers:
      - name: azure-vote-front
        image: mcr.microsoft.com/azuredocs/azure-vote-front:v1
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
          limits:
            cpu: 500m
        env:
        - name: REDIS
          value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front

This is arguable a very simple application, and it was a matter of minutes to write an application specification for this application.

An application specification describes an application and its constituent parts, e.g. images, configuration, etc in an Avassa system.

name: azure-vote-all-in-one-redis
services:
  - name: azure-vote-back
    containers:
      - name: redis
        image: mcr.microsoft.com/oss/bitnami/redis:6.0.8
        env:
          ALLOW_EMPTY_PASSWORD: yes
    mode: replicated
    replicas: 1
  - name: azure-vote-front
    containers:
      - name: front
        image: mcr.microsoft.com/azuredocs/azure-vote-front:v1
        env:
          REDIS: azure-vote-back
    network:
      ingress-ip-per-instance:
        protocols:
          - name: tcp
            port-ranges: "80"
    mode: replicated
    replicas: 1

A few things to highlight here. By naming the Redis service azure-vote-back it is automatically registered in our DNS, hence the frontend code will be able to resolve azure-vote-back when running.

I decided to not allow any traffic from the outside to the Redis service (azure-vote-back), therefore I only declared ingress networking for the azure-vote-front, where I whitelisted port 80.

And that’s really all I did. After deploying, I was presented with the fully functioning voting application once again. Surprise to no one, I’m a dog person.

Try iT yourself

Sign up for a free trial

Deploy your first container application across a distributed edge cloud. Request your free trial now to explore our solution!

Sign up for free trial