Most product scopes fail because teams call a platform decision “modernization” and smuggle months of infrastructure work into the first release. My position is blunt: the popular default stack—Kubernetes, microservices, Kafka, service mesh, and full GitOps—is the wrong choice for most product teams because it optimizes for scale they have not earned yet.
The default stack turns unknown product work into guaranteed platform work
The article Related Software Technologies for Modern IT Development is useful as an inventory, but it becomes dangerous as a delivery plan because a list hides sequencing risk. A product manager should treat modern software technologies as optional constraints until a user outcome proves that the constraint is real.
The common default now looks like this: Kubernetes 1.30 for orchestration, Helm 3 charts for packaging, Istio 1.22 for service mesh, Argo CD 2.11 for GitOps, Kafka 3.7 for events, Redis 7 for caching, PostgreSQL 16 for persistence, Terraform 1.8 for infrastructure, OpenTelemetry 1.33 for telemetry, and GitHub Actions for CI. Every item is defensible in isolation, but the combined scope is often indefensible because each tool adds operational behavior that someone must design, test, secure, document, and support.
For a first or second product release, I would not scope Kubernetes, Istio, and Kafka together because the team will spend planning cycles on cluster networking, schema ownership, consumer lag, mTLS policy, and deployment rollback before it has confirmed which workflows users actually repeat. That is not anti-engineering; it is pro-scope, because the first release should buy evidence rather than permanent topology.
Use concrete planning numbers early. AWS publishes an Amazon EKS control plane price of $0.10 per hour, roughly $73 per month before worker nodes, load balancers, NAT gateways, logs, and engineering time. That vendor-published figure is not large by itself, but it is misleadingly small because the real cost is the queue of platform decisions it authorizes.
A better product scope starts with a testable claim: “Can one workflow create, update, approve, and audit a business object reliably?” That scope can run on a modular monolith with PostgreSQL 16, a small Redis 7 cache if needed, OpenAPI 3.1 contracts, JSON Schema 2020-12 validation, and one deployment pipeline. It is less fashionable, but it is easier to estimate because there are fewer runtime failure modes.
A modular monolith is usually the honest estimate, not the timid one
Most teams say “microservices” when they mean “we want clean boundaries,” but clean boundaries can exist inside one deployable unit because module ownership, database constraints, and API contracts are design choices rather than network requirements. A modular monolith in .NET 8, Java 21 with Spring Boot 3.3, Node.js 22 with Fastify 4, or Django 5 can enforce separation while keeping debugging, testing, and release planning visible to a product manager.
The reference Essential Related Software Technologies for Modern IT belongs in discovery notes, not in a committed release scope, because “essential” should mean required by the first risky outcome. If the team cannot name the user-facing risk that Kubernetes or Kafka retires, the work is not essential; it is deferred architecture.
Here is the scoping difference. In a modular monolith, one feature ticket can include database migration, domain logic, API endpoint, authorization rule, and automated test in the same pull request. In a microservice default, the same feature often creates separate tickets for service contract, data ownership, event schema, deployment chart, observability dashboard, local development setup, and rollback behavior. The second plan looks mature, but it is harder to forecast because more tickets depend on coordination rather than implementation.
Give the team numbers that can be challenged. A practical release-scope assumption is 2 deployable services at most for a team without a dedicated platform engineer; that is a value to tune, not a law, because the right limit depends on operational experience. Set a service-level target such as p95 API latency under 300 ms for the first workflow; that tunable target is better than saying “high performance” because it gives engineering permission to stop optimizing. Track change failure rate and mean time to recovery, because DORA metrics expose whether the architecture is helping delivery or merely creating ceremonies.
A product manager does not need to reject advanced tools forever. The useful question is whether the tool shortens the path to validated behavior. PostgreSQL 16 with row-level locks, partial indexes, and transactional outbox tables can handle many early consistency needs because it keeps write logic local and observable. Redis 7 with maxmemory-policy allkeys-lru can absorb read pressure when repeated queries are the bottleneck. OpenAPI 3.1 can let frontend and backend work in parallel without inventing a service mesh. These choices are ordinary, but ordinary is easier to scope.
Kubernetes wins after deployment pressure exists, not before it
The explicit comparison is this: Amazon EKS with Kubernetes 1.30 and Istio 1.22 versus Docker Compose v2.27 plus a managed container runtime such as AWS App Runner or Google Cloud Run. EKS wins when the team has multiple independently scaling services, custom networking needs, workload identity requirements, and engineers who can own cluster upgrades. Its cost is platform backlog: node sizing, ingress, pod security, Helm release strategy, HPA configuration, secrets, logs, and incident response.
Docker Compose plus a managed runtime wins when the product is still proving workflow value, because it keeps local development and production topology understandable. Its cost is less control: fewer scheduling primitives, less freedom over sidecars, and possible limits around long-running jobs or private networking. For most product teams, that trade is acceptable because control that no one has time to use is not a benefit.
Be specific in scope documents. Kubernetes HorizontalPodAutoscaler with targetCPUUtilizationPercentage: 70 is a tunable operating value, not a product requirement. Helm –atomic –timeout 10m can make releases safer, but it also requires rollback testing because a failed migration may not be reversible. Argo CD syncPolicy.automated.prune and selfHeal can reduce drift, but they can also surprise teams that are still debugging manual hotfixes. Istio PeerAuthentication in STRICT mode improves service-to-service transport security, but it adds certificate and policy failure modes that support teams must recognize.
Here is a tiny check that scopes performance work better than a debate about platforms. It measures the p95 response time of a health endpoint over 20 requests, and the result is measured locally rather than guessed in a meeting.
#!/usr/bin/env bash
set -euo pipefail
URL="${1:-http://localhost:3000/health}"
tmp=$(mktemp)
for i in $(seq 1 20); do
curl -s -o /dev/null -w "%{time_total}\n" "$URL" >> "$tmp"
done
sort -n "$tmp" | awk 'NR==19 { printf "p95=%.0fms\n", $1*1000 }'
rm "$tmp"
If the endpoint is slow in this basic check, adding Kubernetes will not make the feature easier to ship because orchestration cannot repair inefficient queries, oversized payloads, or missing indexes. If the endpoint is fast and deployments are painful, then platform work may be justified because the bottleneck has moved from product code to release mechanics.
Kafka is the wrong default when the team only needs a queue
Kafka 3.7 is excellent when the product needs durable event replay, multiple independent consumers, ordered partitions, and long-lived streams, because its commit log model supports those requirements directly. It is a poor default for simple background work because topic design, partition keys, consumer groups, retention, schema evolution, and lag monitoring are product-scope multipliers.
Compare Kafka 3.7 with Schema Registry against RabbitMQ 3.13 or PostgreSQL 16 transactional outbox. Kafka wins when events are a product asset and future consumers need replay; its cost is operational literacy around min.insync.replicas=2, replication factor, retention policy, consumer lag, and schema compatibility. RabbitMQ wins when the system needs work queues, retries, and routing; its cost is broker management and careful dead-letter handling. PostgreSQL outbox wins when consistency between database writes and emitted messages matters most; its cost is polling, table cleanup, and lower throughput ceiling.
For release planning, treat 3 consumers per event as a threshold to revisit streaming; that planning heuristic is intentionally conservative because one producer and one consumer rarely justify a streaming platform. Treat 7 days of event retention as a configurable starting point only if replay is named in an acceptance criterion, because retention without a replay story is storage theatre. If the team cannot explain which user problem replay solves, defer Kafka and use a queue.
The same realism applies to observability. OpenTelemetry 1.33, Prometheus 2.52, Grafana 11, Loki 3, and Jaeger are powerful, but the first release does not need every dashboard a mature platform would have. It needs traces for the riskiest workflow, structured logs with correlation IDs, an error-rate alert, and a runbook someone has actually followed. A useful initial SLO might be 99.5% successful requests over 30 days; that service target is modest by design because stricter targets force architecture and support costs the product may not yet deserve.
Security should also be scoped without theatre. OAuth 2.1, OpenID Connect, TLS 1.3, OWASP ASVS 4.0.3, and dependency scanning with Dependabot or Renovate are often justified early because authentication, transport protection, and known-vulnerability management are hard to retrofit safely. A service mesh, by contrast, should wait unless there are multiple internal services with real east-west traffic, because mesh policy has little value when almost all calls are still inside one process.
The first scope meeting should remove technology, not add it
Start the next planning session by drawing three columns: user outcome, required runtime behavior, and cheapest reversible technology. Put Kubernetes, Kafka, Istio, and GitOps in the third column only after the second column proves they are needed. The first concrete action is to cap the initial architecture at one deployable application, one database, one queue, and one observability path unless a named risk forces an exception.
