The Hidden Force Slowing Your Deploys

Uncover the silent dependency trap that keeps your applications from reaching production effortlessly

Do you feel that testing your application is difficult?

For running your tests, you have:

1. A Docker Compose file

2. Which has the 2 different services that your application talks to

3. Plus the corresponding infrastructure that those 2 services require (database, etc)

4. Plus Kafka, because your service produces/consumes in Kafka.

And sometimes the Docker Compose fails; some service did not start because of some random problem, and you have to restart.

👉🏼 This has a problem: It slows you down for reaching production for every single change you implement.

In today’s email, you’ll learn one key step that will help you deliver your applications to production more quickly.

🎯 The Problem

Dependencies. That’s the underlying problem.

In this context:

A dependency is any other service, application, or system that your application interacts too.

👉🏼 Testing your application is costly because your service has too many dependencies.

I’ll share with you 6 problems caused by having multiple dependencies.

1. Coupling and coordinating changes: If your service depends on many others, any change to an API/contract can force coordinated changes across multiple teams or your deployment. The result: blocked deployments, delays, and coordination meetings.

2. Unpredictable latency and performance. Chained calls to external services increase latency and variability (p99 spikes). This impacts user experience and SLOs.

3. Testing complexity: This was my main point at the beginning of the email. Unit tests are more representative; integration tests become more expensive and slower. This makes it difficult to ensure quality in CI.

4. Operations and observability become more difficult. You need metrics/traces/alerts for each dependency. Identifying the root cause of a problem becomes more complicated.

5. Versioning and compatibility: If you depend on APIs without stable contracts or without semver, managing versions becomes a pain (breaking changes, coordinated migrations).

6. Loss of team autonomy. Small teams lose the ability to iterate quickly if they must coordinate with many external stakeholders.

So, the fewer dependencies your application has, the faster it can be deployed in Production.

🧞‍♂️ The Solution

Reduce dependencies to one, or the most as you can. That’s my recommendation.

I know it sounds tough, but in my experience, it’s the essential step if you want your application to reach production as quickly as possible.

But, Marcos, the business logic of my application needs all those dependencies, how can I reduce my dependencies then?

Decoupling. Decoupling your application from your dependencies. Take advantage of refactoring time to do this.

I wrote a dedicated email explaining how to decouple a monolith here, but I can give a couple of concrete hints now.

1. Implement asynchronous communication with your dependencies.

Example:

• Instead of calling 2 REST APIs and communicating with Kafka.

• Use only Kafka (or another one) for communicating with those 2 APIs.

Coming back to the problem of testing your application, now you don’t need to spin up 2 different services (with the linked infra) plus Kafka; You just need Kafka for your tests.

2. Consume one single dependency and extract logic to new applications/services.

Example:

• Your application reads from AWS S3, applies some business logic, and produces to Kafka.

• Create a new Platform Service, configurable, that is in charge of only reading from AWS S3 and producing into Kafka.

• Then, update your application to read from Kafka (where the other service puts the data), apply the business logic, and produce to Kafka.

With just those two strategies, you’ll turn a ‘hard-to-ship’ application into an independent one that can be deployed to production multiple times a day.

✨ Takeaway

I want you to retain this from today’s email:

👉🏼 Reduce the number of dependencies in your applications. As much as you can.

That’s THE takeaway today. Only that.

If you need more strategies for achieving this, reply to this email, comment if you are in Substack, or ping me in Bluesky or Mastodon. Happy to help!

---

We are more than ✨1080 Optimist Engineers✨!! 🚀

Thanks for your support and feedback, really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴