Hackathon team Kubernetes CRD - featured

Last year we had our first Fullstaq Hackathon and it was a smashing success! 9 people joined and gave up their free weekend to join the fun and hack at some tech with their fellow nerds.

January the 25th we had our second Fullstaq Hackathon, or Fullstaqathon if you will.

Where last year we mostly focussed on having a fun event with some set goals, this time we took a more structured approach. And boy did we achieve some awesome things!

The Preparation

When starting to organize this Hackathon we decided to set some goals. We chose these goals as a starting point for all the following hackathon organization:

  • Have fun with your colleagues and get to know one another!
  • Go home at the end having learned something new!

After the goals were set we went for the personal approach and reached out to all people at Fullstaq one by one with two questions. ‘Would you like to join the Fullstaqathon?’ and ‘What skill would you like to learn more about?’

Everybody who had not planned anything yet in that weekend immediately said yes and the rest started to see if their plans could be adjusted so they would be able to join.

To the second question, we got a lot of different answers, but they were still mostly groupable in a few sections. With the list of answers, we created three teams and gave them each their assignments. Assigning people to the team that could provide what they wanted to learn.

  • The Serverless team
  • The Microservices team
  • The Kubernetes CRD team

Last but not least the majority of people answered they wanted to learn more about Golang. This meant that all assignments had the subgoal of using Golang to build them.

It was great to hear everyone wholeheartedly say ‘yes’ to the first question. After all, we were asking them to give up a free weekend to hang out with fellow nerds.

Notice how the defined Goals did not state to deliver working software. Instead, it was a proposal to see what our engineers would think of when designing a system in a new type of technology. And of course, getting their feet wet with the new technology.

The Kickoff

15 people joined at 10 in the morning! We welcomed everyone with breakfast and a quick kickoff going over the team goals again.

Team Serverless

Hackathon team serverless: two engineers, sharing a desk, are drawn into their computer

The Serverless team first started with the assignment to build a webshop in serverless. This proved to be a daunting task and instead, they pivoted to building a chatbot.

Using OpenFaas on a provided Kubernetes cluster they started to dig into the Golang language and the shift from dynamically typed languages such as Python to the type strict language of Golang.

Fact Learned: As there is no serverless open standard yet, each product has its unique approach. Causing you to have to think about your platform before you can write functions.

Fact Learned: Thinking of an application in a ‘serverless’ way requires a shift from thinking about processes to thinking about daisy-chaining functions. Like you would within an application.

The team was able to produce a chatbot that, when asked, got a post from a popular website and showed it in Slack. Kudos to the team for being able to build it!

Team Microservices

Hackathon team microservices: office room with a bunch of engineers collaborating

The Microservices team started talking about a few different services required in a webshop. After some architecting of ideas, they decided to split up into two groups. One started writing a Product API and the other worked on the Order API.

The team intentionally did not add the authentication/authorization layer because that would cost too much time to properly build.

Each of the groups first started defining their data models and after discussing them with their peers in the other group decided on the final version and started writing code!

They ran into some issues setting up MariaDB in a docker-compose file with the application, and eventually switched to Postgres. This immediately solved the issue they were having and showed how easy it is to switch to a different SQL server when using properly written code!

Fact Learned: Thinking about your data interactions before writing SQL is a great way to be able to pivot to other SQL engines in the future.

Structuring the Golang code to be able to be quickly changed without impacting the overall service led to more insights on how to split up responsibilities in your code. Golang has a specific way of dealing with packages and grouping of code, it was very cool to think and learn about how to utilize Golang Package Structure to make engineer lives easier!

Fact Learned: Define your code structure before you start writing the code, this forces you to think before you act.

There was a short discussion about whether the team would start using a framework or start using libraries. They found out that the default library in Golang is so powerful, they did not need any framework boilerplate to achieve their goals.

Fact Learned: The Golang standard library contains many strong packages, preventing the immediate need of any outside dependencies when starting.

Team Kubernetes CRD

As a use-case, the team set out to build a Kubernetes CRD that could create Gitlab repositories when defined inside the cluster. Managing state in an application by utilizing all the power of the Kubernetes internals proved successful when the team was able to create repositories!Each team had at least one person more experienced with the question the team was asked so that it wouldn’t be a complete drop in the deep end of the pool. The CRD team had Pieter Lange as an experienced Engineer. Pieter started out explaining how the Kubernetes internals work and which bits exist. This so that it would be clearer where the need for Kubernetes CRD’s could come from.

Fact Learned: As a beginner in the world of CRD’s, using kubebuilder is a lot more approachable than the Operator framework.

Fact Learned: You can automate almost all your work by building cool CRD’s!


After a late night and early morning, we stopped halfway through Sunday. Once again it was an amazing event, providing a lot of in-depth technical discussion and a great atmosphere for people to enjoy their passion!

We are extremely proud of the great group of people that have decided to join us here at Fullstaq since we started expanding last year. These are the people that have shown faith in us and together we have grown stronger.

When your colleagues willingly give up their free time to do what they usually do at their jobs, during a weekend, with their fellow nerds, you know you have a great group.

Since the success of this Hackathon, we have decided to host two Hackathons every year! I am already looking forward to the next one!

Fabian is a Cloud-Native Architect and Open Source Enthusiast. As one of the founders of Fullstaq, he is the technical heart and conscience of the company, helping customers and engineers with guidance and being a nice sparring partner.

To encompass Fabian's roles, we like to call him the TechFluencer. There is often a negative association with influencing or preaching some gospel and forcing opinions on others; instead, Fabian works closely with people to find out what those people and companies really want and need and makes sure the right resources from Fullstaq are made available to achieve those goals. Also, writing in the third person is something Fabian finds odd to do...

Please talk nerdy to Fabian; it is what he likes best!
June 13, 2023 | BLOG | 11 MINUTES

Setting up Fleet - Continuous Delivery with Rancher

Available in Rancher Manager is the option ‘Continuous Delivery’ and that’s the preferred deployment method by SUSE/Rancher. Although companies frequently …

April 13, 2023 | BLOG | 4 MINUTES

Project Coldplay: home elevator project

I love creating cloud-native applications, this not only translates into my field of work but also my projects at home. Projects in which I can simplify …

January 26, 2023 | | 8 MINUTES

Kubernetes Autoscaling: Horizontal and Vertical explained

We can all think of a situation where an application became unresponsive due to insufficient resources for the load you’re currently receiving. A solution …