Blog: Classier Twitter threads

New PostgreSQL instance configuration

You’ve spent weeks, maybe a few months, developing a prototype locally with a local PostgreSQL in docker, not worrying about a thing. But now the moment has come, and you must push to prod. You start an RDS instance, execute the migrations to set up the schema, and launch the app. It’s all good so far!

However, the team has grown from a single lonely wolf, and now you have new colleagues and maybe a few junior devs. It turns out that if everybody uses the same username and password, it’s very hard to find out who left that 5-hour query running that caused the instance to crawl so badly that a full outage would probably be better. So you give everyone their own user, and for some time, everything works great! Except on one late Friday night during a routine deployment, the migrations have failed! What do you mean by “cannot drop X because other objects depend on it”???

Disclaimer: This article does not aim to extensively describe all the best practices, just to set you on the right path and save you from a few ruined Fridays.

Continue reading ...

Spring's @MockBean is an anti-pattern

I really like Spring Boot because it’s super-powerful, but like with any other power tool, you have to be careful not to lose a finger or even a whole arm.

One such tool is Spring’s @MockBean, which allows you to easily replace a service (bean) in Spring’s application context. This is really useful because having to think about all the places where a service is used and how to fully replace it in the context in order to mock it is a huge pain, and sometimes it can even be impossible.

But is it worth the price?

Continue reading ...

Analyzing AWS Costs with SQL

One of the things nobody loves about AWS is billing. Mainly because the more your application is cloud-native, the more unpredictable your bill will become. All that autoscaling and serverless saves you a lot of money, but if there is a massive spike in your app usage, there will also be a spike in your AWS bill. That’s usually a good thing because if you’ve done it right, the opposite is also true, and low traffic means lower costs.

Either way, the more you use AWS, the less useful the default monthly bill becomes. Maybe you have several environments (production, staging, dev, …), or perhaps you have multiple applications. The aggregated view simply becomes a problem, and you start to wonder how much each of those applications costs separately. Then you discover AWS cost allocation tags and cost explorer that can group by service or tags, which also lasts a while before you become unhappy again.

The problem is always the same - the data is not granular enough. Can we somehow get more granular data?

Continue reading ...

Twice as fast deployments from GitLab pipelines

All CI pipelines would finish in a few minutes in an ideal world, but sadly we don’t live in a perfect world. Sometimes your pipelines take 15 minutes or more, and reducing that time would be pretty hard. That alone can be rather unpleasant, but the real problem begins if you’re trying to ensure that you verify all your commits correctly. First, you have to wait for the CI to pass on a rebased merge request, then you merge the merge request, then you wait for the CI to pass on the merge commit in main, and only then a conditional job that runs only on main would deploy the application.

If you sum up all that waiting, you’ll realize that a pipeline that takes 15 minutes means a full CI cycle of a bugfix will take you at least 30 minutes to deploy - potentially 30 minutes of downtime on production.

In this article, I’ll show you one of the possible optimizations you can do to cut that time in half without losing any safety. A significant benefit of this approach is that you can implement it without re-architecting your workflow and CI from the ground up because it’s only an incremental improvement.

Continue reading ...

Better way to manage your Gitlab CI Pipeline ENVs

I often find myself copying AWS access keys from IAM Users to Gitlab’s ENV if I’m automating a deployment for a project or something else. Most of the time, it’s a set-and-forget process, but sometimes you have to go back and investigate, and sometimes you wonder - where did these come from? What are their actual permissions? Who else is using them? Where can I change their permissions? How can I completely delete this user?

Continue reading ...