I know that the topic of microservices has been discussed over and over again, just wanted to add my two cents to the pile, based on my experience with this approach of designing web apps: A lot of people believe that the microservices architecture solve software problems that are of scaling and performance nature. But the most important problem that they solve, is an organizational one. Conway’s law is always in play. Read more...

As I was sitting at work, coming up with a way to solve some synchronization issue between our relational database and a search index, it got me thinking… Is it possible to have a database that can handle this stuff for me, the way, for example, Postgres handles the creation and maintenance of an index? Just one CREATE INDEX away from efficient and fast queries. What about a database that can serve every need: storing and reading data effectively, scaling smoothly as the workload increases, being able to run complex searches, do batch and stream processing for analytical purposes and work with every other access pattern we can imagine. Read more...

I was doing some research at work for tracing and observability for microservices, when I came across Pixielabs. This tool advertises that you can instantly troubleshoot applications without any instrumentation or special code inside the apps, which sounded ✨magical✨ to me. So naturally I wanted to know a little more about what enables this technology to work, and after scrolling through the site, under the “No Instrumentation” section was this acronym eBPF. Read more...

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...