This repository completes the desired infrastructure assignment using mqtt
to facilitate messages between a broadcast-app
and a receive-app
in the context of a minikube kubernetes environment.
This repository contains two convenience scripts (deploy.sh
and build-images.sh
) for building and deploying the MQTT application. It is recommended to use them for simplicity.
As with all shell scripts, feel free to inspect them before executing!
-
Ensure that you have minikube installed and running
minikube start
-
Make the convenience scripts located at the root of this project executable:
chmod +x deploy.sh
chmod +x build-images.sh
-
Build the images:
./build-images.sh
-
Deploy to minikube and port forward:
./deploy.sh
Alternatively simply run ./build-images.sh && ./deploy.sh
in one line
Open a browser and navigage to: http://localhost:5000
You should now be able to observe real time messages on the browser including a client-side calculated time difference between message receipts (you may need to refresh the browser).
To exit from the terminal where you are forwarding ports, simply hit Enter
The project makes use of MQTT to facilitate messages between a receive-app
and broadcast-app
through a Mosquitto broker (broker-app
). The intention with this setup was to represent a real-world scenario where there may be many instances of broadcast-app
(each representing a machine, for example).
Each application contains its own Dockerfile
as they are intended to be deployed via Kubernetes (minikube) as standalone services that can be scaled as needed.
broadcast-app
: A standalone python application that sends messages via mqtt
receive-app
: A standalone flask application that subscribes to messages via mqtt and displays them in a browser
broker-app
: Simple dockerized mosquitto image to facilitate messaging
kubernetes
: Kubernetes deployment and service configuration files
I ran right up to about 4 hours of total time on this project over the weekend but had a pretty fun time putting this together and learning more about working with kubernetes.
I believe the chosen technologies were good ones and make for a good representation of doing this in a real world context. I would not change too much on my approach save for the parts I didn't get together.
Overall, I enjoyed this assignment. It was a good balance of tightly scoped, entertainingly challenging, and relatively unconstrained in terms of how I could approach the problem.
Normally, I squash my commits when merging. I forgot to do that early on and kept the same pattern as I figured it would let you see the order I took if you were bored.
While this is complete from an initial requirements standard, there are a number of changes that we could make to improve things. I did not pursue these because (A) I'm nearly at the 4-hr limit and (B) the added complexity did not seem necessary given the original ask
- Security
This is a simple illustrative example. In the real world, we would want to configure certificates and SSL to ensure that data is encryped and that only intended recepients can subscribe to messages.
- Better webapp UI
The UI is obviously simplistic -- we don't have even have a CSS file! In the real world, we may want some niceties for filtering data or potentially even sending messages the other way.
- A production server
We are using Flask in a development manner. In the real world, we would probably want to use uvicorn or some other setup
- Persistent data
Right now, as soon as you refresh the browser we lose time deltas on messages since these are being calcuated on the client. We could move this to the server or store messages in a more persistent way
- Use of environment variables
Things like "BROKER_ADDRESS" are hardcoded in the scripts. In the real world, it would make sense to probably pull these kinds of things out into an environment file.
Sounds like a fun project. I'll be making use of the following technologies:
-
Python
(enjoyable, well-known language) -
Poetry
package manager (easy and clean) -
Ruff
code formatter (fast code formatting) -
MQTT
via Mosquito (machine-to-machine protocol to facilitate broadcasting and reception) -
Minikube
as that is requrested
The approach I will take will be to setup mqtt
as it is the gold standard for machine-to-machine communication and I'm guessing it or a similar service is in use at Machina.
I'll have a broker as one service, a broadcasting client as another, and potentially one more as a subscriber that feeds into a simple webapp.
There are some fun flourishes I could put in (like broadcasting hello world with a random color and displaiyng that) but we will save those for the end if there is time.
For this assignment, you're going to create the infrastructure for an application with a small set of services.
-
One service needs to broadcast
Hello world
at random intervals. Make the interval anywhere from 1 to 10 seconds, with each the time until the next broadcast each chosen randomly. -
Another service needs to receive the
Hello world
broadcasts. -
Then a user should be able to view the
Hello world
broadcasts, as they arrive, from a web browser.
- Use whatever languages and frameworks you want to create the services.
- We're aiming to just run this application on an engineer's local machine, not the cloud; design your solution for
minikube
- Your solution should have the minimum number of manual setup steps necessary.
- Use any adjacent infrastructure tools you think make for a more elegant solution.
- Fork this repository on GitHub. Develop a solution on your fork. Extra points for good git hygiene.
- Include specific instructions in your README about pre-requisites and setup steps. Another engineer should be able to go from zero to running your solution on their local machine.
- Either send us the link to your repository (if you make it public) or email us a zipped-up folder.