The VMworld Hackathon I failed to attend… And how our team won – Part 2
After finding a great team to be part of at the VMworld Europe Hackathon and defining our goals, it was time to come up with a plan on what we wanted to do.
As a recap, the main goals of our team were:
- Implement Conway’s Game of Life as Kubernetes Pods
- Use VMware VKE
- Use Clarity to visualize the pod status
- Monitor the platform using Wavefront
- Have fun learning, working and meeting great people
We had a great set of goals that we wanted to achieve and so we started to work out a plan to get there. The hackathon in itself is pretty short, you get 4 hours to do all your work, present and demonstrate. That’s not a lot of time.
That’s why we decided to work iteratively and asked ourselves the question “What’s the minimal viable outcome that we want?”. It’s a great question that gets asked a lot when working on projects that are time constrained. What is the goal of the project? What is the minimal requirement if we run out of time? It’s a sad reality that sometimes this happens, but we all experienced it.
We decided that just coming up with a plan is a little too boring, we want to bring a story around this, a story of life and the evolution of it.
This is a story in 3 parts:
- Part 1 – The team and the goal
- Part 2 – The story, the plan and the problem
- Part 3 – The implementation, the result and the future
The story
We imagined the VMware Kubernetes Engine (VKE) environment that we had, to be a world run by at least one god. A god that wanted to experiment with life within strict boundaries of Conway’s Game of Life rules.
As a god, it realized that playing with life is a complicated achievement, especially if the goal is to make life sustainable and let it run its own course without god being involved. It ultimately wanted to make sure that it could leave it alone and not worry about it.
To achieve this, it needed to experiment, and so it decided that it would always need to kick off life itself. It could do so by randomly give some cells life, or it could provide it with a specific pattern, to see if it would make a big difference.
While it now had a way to kick off the eco-system with life, it would need some iterations before it could trust life to run its own course.
In the first iteration, it decided to take full control of the eco-system, it decides to kill a cell, or to create a new cell, according to the rules.
In the second iteration, it gives more power to life itself, it builds in more logic in life and the cells, so they actually die of starvation or overpopulation. This is building in the rules of Conway’s Game of Life directly into the cells. It decides to still remain in control of creating new life, that is too dangerous to give to mere cells.
In the third and final iteration, it has found a stable solution for life, it decides to give control over reproduction and allows cells to create new cells. The God is now only responsible for kicking off the eco-system and watching it, death and life is now the responsibility of the cells.
The plan
By defining the story, we translated in different phases of implementation. Especially important for the back-end, as a lot of work would have to go into that. We defined the following phases:
Phase 1: Have a single central script that would manage all pods, decide to destroy, create them or leave them be with each step. It would be the only thing talking to the K8s API and would control everything.
Phase 1.5: Make this script into an actual K8s Pod, so it would not need to run externally
Phase 2: Make each pod aware of its living neighbours and make it decide itself if it needs to die or stay alive.
Phase 3: Make each pod fully aware of its environment, and not only decide itself if it needs to die or stay alive, but also decide if it needed to procreate with another pod to create a new adjacent pod in the grid.
We all agreed that if we could get Phase 1 done, we’d be happy. If we could get Phase 1.5 done, it would be great.
The problem
By now, our team was ready! Each of us started doing research on how to achieve the goal, how to develop the integrations, define interactions between components.
Time was getting closer to the actual Hackathon, and the night before, we were all excited to work on it and have fun.
At least until I got a call from work, telling me I absolutely needed to be in a meeting of several hours, right in the middle of the Hackathon itself. No way around it…
This left the team in a bit of shock. While I was certainly not the only one who could develop the backend, I seemed to be the one with the most experience with Kubernetes. If I wasn’t able to be present, it would be a lot harder for the team to get to the goal that we set out.
It was time for a curve-ball, a change in plan and strategy…
