DEV Community: Sameer Hakke

Stop Treating AWS Subnets Like Simple IP Buckets

Sameer Hakke — Tue, 03 Mar 2026 06:12:14 +0000

If you open up any standard cloud networking textbook, it will tell you that a subnet is simply a logical partition of your VPC's overall CIDR block.

Technically? Yes, that’s true.

But practically? If you view subnets just as buckets of IP addresses to dump your servers into, you are setting yourself up for a massive headache down the line. As an architect, you have to look at subnets entirely differently. They are not just address pools—they are your foundational boundary lines for security posture, traffic flow, and blast radius control.

Let’s break down how you should actually be thinking about your AWS VPC design.

The "Route Table" Mental Model
One of the biggest misconceptions I see when engineers first start building in AWS is the idea that "Public" and "Private" are just settings you toggle when you hit the "Create Subnet" button.

That is not how it works.

The distinction between a public and private subnet is 100% dictated by the Route Table attached to it. A subnet is entirely ignorant of its public/private status until you tell it how to route traffic.

Here is the 3-tier framework you should be using.

1. Public Subnets (The Front Door)
A subnet becomes "public" only when its associated route table has a direct route pointing to an Internet Gateway (IGW).

If a resource inside this subnet has a public IP address assigned to it, it can talk directly to the outside world, and the outside world can talk back. Because this is the wild west of the internet, you want to keep as little in here as possible.

What belongs here: Your Application Load Balancers (ALBs), NAT Gateways, and maybe Bastion hosts (though you should really be using AWS Systems Manager instead).

2. Private Subnets (The Engine Room)
A subnet is "private" when its route table strictly lacks a direct route to an IGW.

Even if you accidentally assign a public IP to an EC2 instance in this subnet, the internet cannot reach it. The routing simply does not exist. However, these resources usually still need to download patches or talk to external APIs. To allow this, you route their outbound-only traffic through a NAT Gateway (which sits in your public subnet).

What belongs here: Your core application servers, internal microservices, and background workers.

3. Isolated Subnets (The Vault)
This is a subnet with no route to an IGW and no route to a NAT Gateway.

This is the strictest network boundary you can create. Nothing gets in from the internet, and nothing gets out to the internet. If you are building scalable Data and AI platforms, this boundary is absolutely non-negotiable.

What belongs here: This is exactly where your backend databases, data warehouses, and core data processing platforms—like your Databricks clusters running on AWS—must reside.

The Dangerous Anti-Pattern: The Flat Network
The most common (and terrifying) mistake I see in cloud networking is the flat network design. This happens when a team places all their workloads into public subnets and relies exclusively on Security Groups (firewalls) to block unwanted external traffic.

Security Groups are incredibly important, but you have to understand a core architectural principle: Security Groups fail open under human error. If a tired engineer accidentally adds an inbound rule allowing 0.0.0.0/0 on port 3306 to troubleshoot a database issue and forgets to remove it, your data is now exposed to the internet.

Subnet routing, however, fails closed. If there is no physical route to the internet defined in the route table, it does not matter how badly you misconfigure your Security Groups. There is zero chance of external exposure. Period. The traffic simply has nowhere to go.

The Takeaway
Subnets define your blast radius. When you sit down to architect a new environment, don't just ask, "How many IPs do we need?" Instead, ask: "What is the sensitivity of the data here, and what is the strictest routing boundary we can enforce?"

Design around security boundaries first, and the IP math second.

How are you structuring your VPCs these days? Have you ever had a routing table save you from a Security Group misconfiguration?

Let's talk about it , connect with me on Linkedin:

Mapping the Chaos: Why the C4 Model is My Daily 'Google Maps' for Architecture

Sameer Hakke — Wed, 04 Feb 2026 20:05:29 +0000

If you saw my last post on the Fabric + Databricks power couple, you know I’m a big believer that Architecture > Tool Wars. But let’s be real: a great architecture is only as good as your ability to explain it without causing a headache.

For a long time, my diagrams looked like a plate of spicy Indiranagar street food—lots of random boxes and mystery arrows that made sense only to me (and maybe not even me by the next morning).

Then I started using the C4 Model daily. Total game-changer. Sanity restored.

The "Legendary" Origin (Bangalore Edition) 🇮🇳

The C4 model was created by Simon Brown. Officially, he’s a British engineer.

Unofficially? Local legends say he finalized the framework while stuck in a 4-hour Silk Board traffic jam.

The theory: if you can navigate Bengaluru using different levels of detail—from satellite traffic views down to the exact auto-rickshaw blocking your lane—you can do the same for software systems.

History may call this a myth. Bangalore residents know better.

What Exactly Is the C4 Model?

Think of C4 as Google Maps for your codebase.

It’s a hierarchical way to zoom into architecture so you don’t overload your audience with irrelevant detail.

🌍 Level 1: System Context

(The "Satellite View")

This is the view from space. Your system is a single black box, and you only care about how it interacts with:

Users
External systems

Who it’s for: Everyone

(Yes, including the CEO who doesn’t know a JSON from a Jalebi)

Goal:

Define boundaries.

Who uses us? What do we depend on?

📦 Level 2: Containers

(The "Koramangala View")

Now we zoom in. The box opens.

We see:

Web apps
Databases
APIs
Microservices

In my world, this is where Microsoft Fabric and Databricks show up as distinct containers.

Goal:

Map the tech stack and how data flows between services.

🧩 Level 3: Components

(The "Street View")

We’re inside a specific container now.

This is where real logic lives:

PaymentController
IngestionService
ValidationEngine

Who it’s for: Developers and Tech Leads

Goal:

Explain how the guts of a service are structured.

💻 Level 4: Code

(The "Auto-Rickshaw View")

Maximum zoom.

Class diagrams. Code relationships. Implementation details.

Pro tip:

I rarely draw this. If you need a diagram here, your code might already be in trouble.

Why I’m Hooked (The Pros)

Audience-Right Detail

No Spark cluster configs for VPs. No hand-wavy fluff for engineers.
Faster Onboarding

New joiners understand the system in minutes, not days.
Communication > Ego

Forces clarity. Less box-dragging, more thinking about real system boundaries.

Final Thought

Architecture isn’t about picking the coolest tools.

It’s about making sure everyone is looking at the same map. 🤝
So—are you still drawing Random Boxes and Arrows,

or are you ready to zoom with C4?

Drop your thoughts in the comments. Let’s compare traffic routes. 🚦

Beyond the Rivalry: Why the Future of Data Architecture is Fabric AND Databricks

Sameer Hakke — Mon, 02 Feb 2026 18:38:18 +0000

In the world of data engineering, we love a good "versus" match. Spark vs. Flink, Snowflake vs. BigQuery, and now, the heavyweight title fight: Microsoft Fabric vs. Databricks.

If you follow the industry chatter, you’d think these two platforms were destined to fight for the same single spot in your tech stack. For a long time, I fell into that same trap. I thought choosing one meant abandoning the other.

But as I started mapping out real-world enterprise architectures—the kind that have to handle messy ingestion, massive scale, and production AI all at once—the "rivalry" started to feel forced.

Here is why I’ve stopped asking which one is better and started asking how they can work together.

1. The "Front Door" vs. The "Engine Room"

One of the biggest challenges in data engineering isn't the code; it’s the barrier to entry.

Microsoft Fabric shines as the "Front Door" of the data estate. With its SaaS-led approach and UI-friendly Data Factory pipelines, it excels at:

Rapid Ingestion: Getting data from disparate sources into a centralized location without a week of boilerplate code.
The Power of OneLake: Providing a unified, accessible storage layer (the "OneDrive for data") that business users and analysts can actually understand.
Democratization: It allows teams to move fast, lowering the technical overhead for initial data landing and raw (Bronze) layer management.

2. Where the Heavy Lifting Happens

Once the data is through the door, you need a high-performance engine to refine it. This is where Databricks remains the gold standard.

When your architecture moves into the "Silver" and "Gold" layers of the Medallion Architecture, you need granular control. Databricks provides:

Complex ETL/ELT: Handling massive Spark workloads with performance optimizations that are still hard to beat.
Engineering Rigor: Deep integration with developer workflows, version control, and sophisticated job orchestration.
Cost Efficiency at Scale: For truly massive datasets, the ability to fine-tune clusters and compute is a necessity, not a luxury.

3. The Intelligence Layer: AI and ML

The conversation changes entirely when you move from "descriptive analytics" to "predictive AI."

Databricks has spent years building a mature ecosystem for Lakehouse AI. From Unity Catalog for governance to MLflow for model tracking and Mosaic AI for generative workloads, it is built for production-grade machine learning.

By using Fabric to feed the "Bronze" data into a Databricks environment, you allow your Data Scientists to work in a high-fidelity workspace without worrying about the complexities of the initial data ingestion.

The Hybrid Blueprint: A Shared Success

Responsibility	Preferred Tool	Why?
Data Ingestion	Microsoft Fabric	UI-friendly, fast connectors, low overhead.
Unified Storage	OneLake	Centralized, accessible, "SaaS" simplicity.
Heavy Transformation	Databricks	Spark optimization, Medallion depth, scalability.
AI / Machine Learning	Databricks	Mature ML lifecycle, model serving, feature stores.
Business Intelligence	Power BI (via Fabric)	Native integration, Direct Lake performance.

Final Thoughts: Outcomes over Labels

The "Fabric vs. Databricks" debate is a distraction. In the real world, stakeholders don't care which logo is on the bill; they care about how fast they can get insights and how reliable the AI is.

Fabric accelerates your Time to Value.
Databricks delivers your Core Intelligence.

When you stop treating your data stack like a sports rivalry and start treating it like a relay race, you stop fighting the tools and start solving the business problems.

What does your architecture look like? Are you leaning into one ecosystem, or are you finding the "sweet spot" in the middle? Let's discuss in the comments below!`