True FinOps Starts in the Code: Why Buying Reserved Instances Isn't Architecture

Paulo Dalmas — Fri, 26 Jun 2026 10:17:55 +0000

If you've ever sat in a technical leadership or architectural role at a cloud-native company, you've likely witnessed the classic clash between Engineering and the Finance department. On one side, developers fighting to refactor bottlenecks. On the other, a well-intentioned "FinOps" team trying to slash the AWS bill armed with nothing but Excel spreadsheets.

The outcome of this story is usually predictable (and frustrating): real code optimization projects get shelved because the finance team chose to sign a 3-year contract for Reserved Instances (RIs) or Savings Plans to "solve the cost issue."

The Illusion of Financial Discounts

Let's be pragmatic: financial optimizations and RIs are excellent management instruments. The problem arises when we use long-term contracts as a band-aid for inefficient architectures.

Buying reserved capacity on AWS to run a service suffering from chronic memory leaks, or that executes thousands of N+1 database queries, is literally subsidizing waste at a discount. You aren't solving your system's scale problem; you're merely ensuring the company pays slightly less for continuous waste over the next three years.

Cost-Aware Architecture

As a Senior Architect, I argue that true FinOps isn't just done in the AWS billing portal; it's done in the IDE, in domain design, and in infrastructure choices.

Cloud costs are no longer a mere consequence of the system; they have become a non-functional requirement, just as critical as latency, security, or high availability. In a Cost-Aware Architecture, the financial impact of every microservice or asynchronous worker is designed and validated from Day 1.

This is exactly why, strategically, I advocate for the introduction of languages like Rust in critical processing domains. The low memory footprint and absurdly efficient CPU usage of Rust code drastically change the baseline of the required infrastructure.

The Right Value Stream

Architectural efficiency must always precede financial negotiation. Only after eliminating the computational bottleneck — whether by redesigning inter-service communication or injecting a high-performance language into the data plane — does it make sense to bring in the finance team to sign Reserved Instance contracts based on the newly optimized metrics. The ROI of optimizing the code first is incomparable.

In short, reducing the cloud bill isn't a war between Engineering and Finance. It's a partnership where Engineering tackles computational waste, and Finance tackles commercial waste. If your company is only doing the latter, you are leaving a lot of money on the table.

The Illusion of Microservices: Why the Modular Monolith is Once Again the Gold Standard in Architecture

Paulo Dalmas — Thu, 25 Jun 2026 18:15:35 +0000

Throughout my career, transitioning between CTO roles and, more recently, focusing purely on distributed systems architecture and high-performance engineering, I've seen many architectural patterns rise and fall. But few have caused as much silent damage to company bottom lines as the premature adoption of microservices.

Over the last decade, the industry bought into the idea that, in order to scale, you needed to split your system into dozens (or hundreds) of independent services. The practical result I find in most companies? The creation of the dreaded "Distributed Monolith."

The Anatomy of Waste: Networks vs. Memory

The hard truth we need to face with maturity is that microservices primarily solve problems of organizational scale (Conway's Law), not necessarily performance. If your engineering team isn't the size of Netflix or Uber, prematurely fragmenting your codebase is shooting yourself in the foot.

Technically, what happens when we break down a monolith without the proper domain boundaries? We trade extremely fast and cheap local function calls (resolved in the processor's L1/L2 Cache) for slow and expensive network calls (TCP/IP).

We start spending an absurd amount of computational time on constant JSON serialization and deserialization, and the AWS bill explodes with internal traffic costs (egress/ingress) between Availability Zones (AZs). You haven't scaled your application; you've merely added network latency and infrastructure complexity.

The Return of the Modular Monolith

True seniority in software engineering isn't about mastering the most complex architecture of the moment, but having the wisdom to know when not to use it. That's why the Modular Monolith has consolidated itself as the initial gold standard for new projects and restructurings.

In a well-designed Modular Monolith (and languages with strong type systems and strict scope control, like Rust, shine absurdly well here), you maintain the logical separation of domains. Modules are independent, business rules are isolated, but the deployment is singular. Communication between modules goes back to being in-memory. Performance skyrockets. AWS costs plummet. The team's cognitive overload disappears.

It's exactly the difficulty of debugging this invisible latency between poorly divided services that motivated me to adopt the 'Build in Public' approach to create a DevTools Chrome extension. I'm developing a tool focused on giving engineers real visibility into payloads and client-side bottlenecks, saving hours of troubleshooting in complex architectures
.

Pragmatism as a Metric

Software engineering is a continuous exercise in managing trade-offs. If your current architecture is consuming financial resources that should go towards the product (or into the employees' pockets) just to maintain "vanity complexity", it's time to rethink. Having the courage to lead a rollback to a well-structured monolith isn't a step backward; it's the pinnacle of technical pragmatism.

DEV Community: Paulo Dalmas

True FinOps Starts in the Code: Why Buying Reserved Instances Isn't Architecture

The Illusion of Microservices: Why the Modular Monolith is Once Again the Gold Standard in Architecture