We are reading on the news almost every other month now, of companies getting pwned left and right. Phishing attacks are increasingly more common, usually targeting employees with access to repositories containing static credentials and secrets, which the attackers can then leverage to gain access to the cloud accounts, and from there it is game over, since pretty much all of the data that companies store and process, is stored in the cloud.

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. When you think about how the software that you build should look like, you need to think how your organizational structure should look like. They always go hand in hand.
• If you are a single team, then a design involving multiple moving pieces does not make a lot of sense from that perspective. Who should take ownership over each component? How can the services be truly independent from one another? It is inevitable to entangle them just because it’s more convenient that way and end up with something that resembles a microservice architecture, but in reality it is more of a “distributed monolith”. Starting with a microservices architecture is the wrong play that a lot of people seem to make. The structure of the software always ends up looking like the structure of the organization. It is inevitable.
• Never start with a microservice architecture if you have a single team.
• As the organization scales though, and more people are added to the team, then it is the right time to raise the question for the current design of the architecture.
• As the team grows, it will become more and more difficult to manage it. Breaking this big team apart into multiple, smaller, independent teams is a natural step going forward. Then the question that we should ask is: how can those teams take full ownership over the parts of the product that they are responsible for? How can we make the teams take control over their own “destinies”?
• For a team to be truly independent, it needs full decision making power in every layer of the stack: from the UI/UX, the APIs that the backend is going to expose, all the way down to the infrastructure that willl power the whole thing. Doing this as a single monolithic application is certainly feasible, but then the teams will need to be synchronized in their development process, especially in the deployment phase. They will step on each other’s toes constantly. Thus, a need will arise to create an architecture that will mirror the organizational one. Microservices solve this exact problem - scaling the teams.
• The services need to be composable, and play well with each other, just as you would create composable modules in a monolith. Breaking it apart and simply sticking a web server in front of it won’t save you.
• For features that span multiple domains, a clear ownership of the data, as well as clear and consistent APIs are a must, otherwise you risk complicating the relationship between the services that are involved. Defining these boundaries is the responsibility of the teams that will develop this feature. The communication between the services should reflect the communication of the teams.

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.

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.

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.

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.

As a first setup, we we’re using the docker executor and we had an image that had all the necessary tools to run our tasks, including Bazel of course. As our repository grew larger, our build times we’re starting to become greater and greater and I’ve searched high and low on the internet for a solution but to no avail.

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?

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. This blog post will cover several great patterns to separate tests using the tools at our disposal.

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. Basically it is impossible for the code to be out of sync and each change that we make can be considered as a single unit.