DEV Community: JorelFuji

REPO LAYOUT VS. RUNTIME ARCHITECTURE

JorelFuji — Wed, 15 Jul 2026 14:31:02 +0000

title: "Monorepo is not Monolith — and the difference decides your CVE response time"
published: false
description: "Repo layout and runtime topology are orthogonal axes. Here's what each one actually costs you in version control, updates, scaling, and scanning."
tags: architecture, devops, security, kubernetes
cover_image:

canonical_url:

Repo layout and deployment topology are orthogonal. Most orgs conflate them, split their runtime to solve a version-control problem, and end up with a distributed monolith that fails together, deploys together, and now also drops packets.

The decision that actually matters is where you enforce a boundary — compiler, or network — and you make that choice once per boundary, not once per company.

The two axes

Fig. 1 — The four real options. "Monorepo vs. microservices" is a category error.

Axis	Question it answers	Reversible?
Source layout (mono/poly-repo)	How do teams land code?	Yes — painful but mechanical
Deployment unit (monolith/services)	What ships and scales independently?	No — data migrations aren't `git revert`

Asymmetry of regret. Repo layout is a two-way door. Runtime topology is a one-way door the moment each service owns its data. Sequence accordingly: change the repo layout first, and only split the runtime once module boundaries have proven stable in a monolith.

Why is "polyrepo + monolith" so common if it's strictly worse?
Because it arrives by accretion, not decision. Someone extracts a shared auth library into its own repo for "reuse," and now a one-line change is two PRs, a release, and a version bump — with none of the deploy independence that would justify it. The tell: your internal libraries have semantic versions but only one consumer.

What actually runs

Fig. 2 — Same four capabilities. The difference is where the boundary is enforced.

A network call is a function call that acquired five new failure modes and lost its type checker. That's the entire trade:

You gain	You pay
Independent deploy	Timeouts, retries, backoff, idempotency keys
Independent scale	mTLS certs + rotation, SPIFFE identity
Independent failure	Distributed tracing, or you debug blind
Per-workload least privilege	NetworkPolicy per pair, contract versioning
Team autonomy	Eventual consistency where you had a transaction

The availability math nobody runs first

Services in a synchronous request path multiply, they don't average. For $n$ services each at availability $a$ :

A_{p a t h} = a^{n}

At a respectable $a = 0.999$ per service:

Services in path	Path availability	Annual downtime
1 (monolith)	99.90%	~8.8 h
5	99.50%	~43 h
20	98.02%	~174 h

The corollary. Microservices only improve availability if calls are asynchronous or optional. A synchronous fan-out of 20 services is strictly less available than the monolith it replaced. If reporting being down can 500 your checkout, you didn't isolate failure — you multiplied it.

Distributed monolith: the smell test

Do two services have to be released in a fixed order? → not independent
Do they share a database schema? → not independent
Does one service's deploy require the other's integration suite? → not independent
Does a single user story routinely touch 3+ repos? → boundaries follow the org chart, not the domain
Is there a "shared-models" library every service pins? → you have a monolith with extra latency and a build step

Any of these = the costs of both architectures, the benefits of neither. Merge them back.

Version control and updates

An engineering drawing has one revision block. A drawing set has a rev per sheet plus an index saying which revs go together. That index is the whole problem with polyrepo microservices.

Concern	Monolith	Microservices	Monorepo mitigates?
Unit of change	Caller + callee in one commit; the compiler catches the mismatch	Two commits, two repos; nothing catches it until prod — unless you run consumer-driven contract tests	✅ Atomic commit restores the invariant
Breaking a contract	Rename, fix call sites, merge	Expand → migrate → contract: 3 releases, maybe 3 teams	✅ Partially — still need runtime bake
"What was running at 03:14?"	`git tag`	Deploy manifest / cluster state. Git cannot tell you.	❌ Orthogonal — that's GitOps
Bisecting a regression	`git bisect`, works	Bisect across the deploy manifest, by hand	✅ Meaningfully
Update blast radius	Full-fleet restart for a one-line fix	One deployment — the real win	❌
Base-image bump	1 Dockerfile, 1 PR	N Dockerfiles, N repos, N reviews, N releases	✅ The killer argument
Dependency confusion risk	One lockfile, one registry config	N lockfiles, N registry configs, one misconfigured	✅

DORA's actual finding: deployment frequency correlates with loosely coupled architecture and independent testability — not with the number of repos or containers. A well-modularized monolith on trunk-based development beats a badly-split microservice estate on every DORA metric. The architecture is a means; the coupling is the thing.

Scalability

Fig. 3 — Granularity of scaling is the real dividing line, not code size.

The only scaling argument that survives contact is divergent resource profiles. If your resizer is CPU-bound and spiky while auth is memory-flat and steady, you're sizing every replica for the resizer and paying for idle auth 24/7. That's a real bill.

If every module has the same profile, splitting buys you a network hop and a Grafana dashboard.

Concern	Monolith	Microservices
Horizontal scale	Add replicas behind an LB. Stateless monoliths go much further than folklore suggests.	Per-service HPA/KEDA. Efficient only when profiles diverge.
Vertical waste	Pod sized for the hungriest module	Right-size per service
Failure isolation	Reporting's leak OOM-kills auth. Shared fate.	Reporting dies alone — iff callers have timeouts and breakers
The database	Usually the actual bottleneck	Splitting app code does not split the DB. Real split means outbox and sagas where you had `BEGIN TRANSACTION`.
Team scale	Merge contention past ~20–30 engineers — solvable with a merge queue	Conway's law made explicit: independent cadence per team

If your monolith is slow because of an unindexed query, microservices will give you the same unindexed query plus a service mesh.

Supply chain and scanning

Fig. 4 — Microservices shrink each blast radius and multiply the number of blast radii.

This is where the two architectures invert, and where most security programs get it backwards.

Concern	Monolith	Microservices
SAST	One scan, whole call graph. Taint analysis works end to end.	Per-service scans. The scanner cannot follow taint across a network hop — cross-service injection is structurally invisible. Under-priced regression.
SCA	One lockfile, one fix. But one bad transitive dep taints everything.	N lockfiles. Smaller each; drift guaranteed; inventory mandatory.
Findings noise	Big image → many findings, most in code paths never executed. Kill this with VEX, not with an architecture change.	Slim images, genuinely fewer findings. Real benefit.
Fleet CVE response	Hours. Bump, rebuild, roll.	Days to weeks — unless monorepo or golden-base auto-rebuild. Ask your worst team, not your best one.
Runtime attack surface	One identity, one NetworkPolicy. Compromise = full app + full DB creds.	Per-workload SPIFFE identity, per-pair NetworkPolicy, minimal filesystem. The genuine security win.
Policy enforcement	One gate	Enforce centrally at admission, never per-repo. Per-repo policy rots to the level of the least-staffed team.
Provenance / SLSA	One attestation, one control mapping	N attestations. SLSA L3 needs a hardened build platform — N times, or one shared platform.

The pattern that actually works, regardless of which side you land on:

golden base image (hardened UBI/distroless)
  └─> bump triggers rebuild of ALL dependents
        └─> SBOM + in-toto provenance attestation
              └─> cosign sign
                    └─> admission control verifies signature (Kyverno/Gatekeeper)
                          └─> Dependency-Track fleet inventory

The synthesis. Monolith: fast, complete remediation + wide blast radius. Microservices: narrow blast radius + slow, incomplete remediation. Monorepo + microservices + golden base is the only combination that buys both. If you're splitting the runtime and staying polyrepo, you're choosing the slow remediation on purpose — write that down in the ADR.

The gate

Split a service out only if you can say yes to at least one trigger and yes to all the mitigations.

Triggers — at least one:

Materially different resource profile (CPU vs memory, spiky vs flat)
Materially different failure domain (this must survive when that dies)
Materially different compliance boundary (this touches PII and that doesn't)
A team that needs independent cadence and owns the whole domain
Different scaling ceiling or language/runtime, with a real justification

Mitigations — all of them:

Callers have timeouts, jittered retries, circuit breakers
The service owns its data; no shared schema
Contract tests in CI on both sides
Distributed tracing before the first split, not after
Golden base image with rebuild-on-bump
Centralized admission policy and signed images

Not on the list, and never a valid trigger: "the codebase is big." Big is what modules are for.

Verdict

Start monorepo + modular monolith. Enforce module boundaries in CI (import linting, architecture tests) so the seams are real before they're physical. Split one service at a time, strangler-fig style, only against the gate above. Stay monorepo through the split — it's the cheapest insurance you'll ever buy against base-image drift.

Axis	Winner	Confidence
Version control	Monorepo	High — few real counterarguments below ~1000 engineers
Updates	Monolith	High
Availability	Monolith, unless calls are async	High
Scalability	Microservices, iff profiles diverge	Conditional
Supply chain	Monorepo + microservices + golden base	High

Which axis does your org get wrong? I'd guess the one nobody wrote an ADR for.

Enforcing Zero-Trust Egress in Kubernetes with NetworkPolicies

JorelFuji — Tue, 23 Jun 2026 17:09:03 +0000

Most teams invest heavily in locking down inbound traffic — ingress rules, service meshes, mutual TLS — while leaving outbound traffic largely uncontrolled. That oversight creates a significant attack surface: a compromised container can silently reach out to an adversary-controlled server, exfiltrate sensitive data, or retrieve a second-stage payload without triggering a single alert, because nothing was monitoring traffic in the outbound direction.

Zero-trust networking applies the principle of least privilege in both directions. The default answer to "can this pod initiate this connection?" is no — for both ingress and egress. This guide walks through implementing that model for egress using native Kubernetes NetworkPolicy objects: deny all outbound traffic by default, then explicitly allow only what each workload legitimately requires. No service mesh, no additional tooling — just declarative YAML you can apply to any compliant cluster today.

Prerequisite: CNI Enforcement

Before applying any NetworkPolicy manifest, verify that your CNI plugin actually enforces policy. This is the single most common source of confusion when getting started.

NetworkPolicy is a Kubernetes API abstraction, not an implementation. The API server will accept any well-formed policy object, but the policy has no effect unless the underlying CNI plugin is configured to enforce it. The default CNI on a standard kind cluster or many stock configurations does not enforce NetworkPolicy.

Use a policy-enforcing CNI — Calico and Cilium are the most widely deployed options. For a disposable test cluster:

minikube start --cni=calico

Confirm the CNI is operational before proceeding:

kubectl get pods -n kube-system | grep calico

If you apply the policies in this guide and observe no change in connectivity, a non-enforcing CNI is almost always the root cause.

Step 1: Create a Namespace and Test Workload

kubectl create namespace app
kubectl -n app run web --image=nginx --labels="app=web"

Use netshoot as an ephemeral debug pod to validate connectivity from within the namespace:

kubectl -n app run netshoot --rm -it --image=nicolaka/netshoot -- /bin/bash

From inside that shell, confirm the cluster is currently operating with no egress restrictions:

curl -m 5 https://example.com   # succeeds
nslookup kubernetes.default     # succeeds

At this point, any pod can reach any destination. The following steps will close that off systematically.

Step 2: Default-Deny All Egress

Apply a NetworkPolicy that selects all pods in the namespace (via an empty podSelector) and specifies Egress in policyTypes with no allow rules. This results in a deny-all for outbound traffic:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Egress

Apply the manifest and re-run the test pod:

kubectl apply -f default-deny-egress.yaml
kubectl -n app run netshoot --rm -it --image=nicolaka/netshoot -- /bin/bash

curl -m 5 https://example.com   # times out
nslookup kubernetes.default     # fails

Note that DNS resolution has also broken. This is expected and is addressed in the next step.

Step 3: Restore DNS Resolution

The moment you enforce a default-deny egress policy, pods lose the ability to reach kube-dns, which causes all hostname resolution to fail — including for destinations you intend to allow. You must explicitly permit egress to the cluster DNS service.

kube-dns pods are identifiable by the label k8s-app: kube-dns. The following policy opens egress from all pods in the namespace to that target on UDP and TCP port 53:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

NetworkPolicy rules are additive — this policy adds a permitted path on top of the existing default-deny. After applying it, DNS resolution is restored, but arbitrary outbound connections remain blocked. That is the intended state: name resolution functions, but no traffic flows unless explicitly allowed.

Step 4: Grant Per-Workload Egress Permissions

With the baseline in place, you can now issue narrow, workload-specific allow rules. Suppose a checkout service requires outbound connectivity to an external payments API over HTTPS, and nothing else. Scope the rule to that workload's label selector and the relevant destination CIDR:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-payments
  namespace: app
spec:
  podSelector:
    matchLabels:
      app: checkout
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 203.0.113.0/24
      ports:
        - protocol: TCP
          port: 443

With this policy in place, only pods labeled app: checkout can initiate outbound connections, and only to that CIDR on port 443. All other pods and all other destinations remain denied. You have moved from an implicit open-by-default posture to an explicit allow-list — the foundational principle of zero-trust egress.

Production Considerations

Several operational realities become apparent once this pattern moves beyond a lab environment:

Hostname-based matching is not supported in vanilla Kubernetes. NetworkPolicy operates exclusively on IPs and CIDRs, not FQDNs. If a dependency resolves to a rotating IP pool — as most SaaS APIs do — an ipBlock rule becomes fragile and operationally expensive. Cilium's FQDN-based policy (a CRD, not a core NetworkPolicy) addresses this directly: specify toFQDNs: api.stripe.com and Cilium tracks the resolved IPs automatically.
Pods not selected by any policy are unrestricted. Default-deny applies only to pods that a policy's podSelector actually matches. Regularly audit for workloads that have no applicable policy and would therefore bypass all egress controls.
Policies are namespace-scoped. A default-deny-egress policy in the app namespace has no effect on pods in payments or any other namespace. Apply the baseline deny policy to every namespace — ideally via a templated manifest managed in your GitOps repository, so no new namespace can be provisioned without it.
Denied traffic is not logged by default. Native NetworkPolicy silently drops blocked connections without emitting any log or event. Debugging failed connectivity relies on inference from timeouts, which is slow and error-prone in production. Calico and Cilium both provide flow-level visibility — enable it before rolling this pattern to any environment where you need operational observability.
Apply allow rules before deny rules. In production environments, apply all workload-specific allow rules first and validate that legitimate traffic continues to flow, then apply the default-deny policy last. Reversing that order will cause an immediate outage while you reconstruct your dependency graph under pressure.

Summary

Egress control is the half of zero-trust networking that is easiest to defer and most costly to neglect. With three focused manifests — a namespace-wide default-deny, a DNS allow rule, and per-workload egress permissions — you transform outbound traffic from an unmonitored open channel into an auditable, explicit allow-list using nothing beyond standard Kubernetes primitives and a CNI that enforces them.

The recommended rollout path: start in a non-production namespace, enable flow logging from day one, validate all required paths, then promote the pattern namespace by namespace with your GitOps tooling driving consistency.

The author is a Platform and DevSecOps engineer (CKA, CISSP) who publishes production-grounded guides on Kubernetes security, CI/CD pipelines, and cloud compliance. If your organization is looking for technical content that practitioners trust, feel free to reach out.