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.
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:

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!