When something goes wrong in your system, logs are crucial to finding out exactly what’s happened. Usually, this involves following the logs as a trail of breadcrumbs that lead to the root cause of the failure. If your application is generating a lot of logs, it can become strenuous to tie everything together that reveals the failing scenario. This can become especially challenging in a distributed system, where one HTTP request to your API can pass through dozens of different services, each outputting logs that have no context of the flow of the request. Read more...

Lately I’ve been obsessing with the performance of Bazel in our CI environment. We’ve been using this tool for quite some time now for our Golang monorepo and since the beginning of its creation it has grown quite a lot, so we’ve hit a couple of road blocks with our setup. We’re using Gitlab CI as our continuous integration environment and we host the runners on our own AWS instances. Read more...

Nowadays deploying software on the cloud using technologies like Docker and a container orchestration system (k8s, ECS, docker swarm, etc.), has become effortless, leveraging strategies like “rolling updates” and “canary releases” which are practically included and require no additional undertaking. While this ensures that we can release our software with zero-downtime to our customers, what happens when we introduce a change in the system that we cannot go back from? Read more...

There are many different types of testing which you can do in order to ensure that your software is working correctly. These tests can vary a lot in complexity and the time that it takes to complete them. Although the go testing package along with the go tool command provides us support in order to make automated tests for Go packages, it is not immediately clear on how we should separate different tests for different testing scenarios. Read more...

At InPlayer, we have a platform that is built using a microservice architectural style which basically structures an application as a collection of many different services. In this post I will talk about how we structure, build and deploy our Go applications. Every bit of Go code that we write, resides in a single Git repository - A monorepo. Since every library and service is in a single project, it allows us to make cross cutting changes without the need of some external package management tools. Read more...