Reflections

Reflections

MSc students reflections (to check in the future): https://github.com/search?q=repo%3Aitu-devops%2Flecture_notes%20MSc%20students&type=code

Programming language

choice: GO considered: Java, C#

GO

• Lower memory consumption compared to ruby, Java etc.
• Scales well, which is important for us considering the userbase will increase over time.
• Easy to learn.
• Compiles to a single binary which makes it easy to deploy (compared to).
• Comes with an opinionated formatter (gofmt) ensuring code style consistency. This reduces discussions about styling (which does not bring value to the product).
• It is a language with high developer interest meaning that it will hopefully be ease future recruitment when the application sky-rockets in popularity.

GORM

Based on research sharing reasons why to choose GORM instead of GORP. Reasons:

Applications like Twitter, Facebook, etc.. all use Relational databases, and most of the MySQL - GORM suited better for that GORP is not receiving any support as I saw. The community there is not so active. GORM is being updated. I think we will go with a relational database if we need to switch so probably MySQL. for this, we don't need to make any major changes in the DB structure.

Postgress

A relational database was chosen also to be compatible with GORM. Popular usage and therefore lots of documentation and how to use it. It is suitable for rigorous enterprise applications which is beneficial for our scaling of the system.

Software Artifacts

choice: docker considered: VMs, linux Packages, LXC, go packages

• lower overhead compared to VMs
• supported on most linux distributions regardless of package managers
• containers isolate the environment from the host system
• support for using different language compared to language specific artifacts
• support micro-services in our case allow us to run api and app with docker compose
• community support

CI/CD Pipelines Tool

choice: GitHub Actions considered: Jenkins, GitLab CI/CD, Bamboo

GitHub Actions

• already integrated into code repository of our choice (Github)
• minimal setup, compared to tools such as Jenkins
• runs on cloud without need of provisioning
• modern and easy to use UI
• team members already familiar with the functionalities

Artifact registry

choice: Github Container Registry due to considered: DockerHub considered: GitHub Packages

• largest docker registry

Github Container Registry When using DockerHub we were only able to use an individual DockerHub account unless we were willing to pay for an organization. We chose Github Container Registry since it allowed us to publish container images directly in the the GitHub organization. It also did not require us to use PATs since we could use the GITHUB_TOKEN from the aciton itself.

Infrastructure automation platforms

choice: terraform previously used: vagrant

Terraform

• there is currently larger community behind terraform than vagrant
• less unexpected behavior we experienced compared to using vagrant