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.