In the over-evolving tech world, we often see organizations (from C-Level down to architects and engineers) rush to adopt the latest technology trends without conducting proper design or truly understanding the business requirements.
The result of failing to do a proper design is a waste of resources (from human time to compute), over-complicated architectures, or under-utilized resources.
In this blog post, I will dig into common architecture decisions and provide recommendations to avoid the pitfalls.
Let’s dig into some examples.
Moving everything to the public cloud
Example
An enterprise mandates a full lift-and-shift of all workloads to a hyper-scaler to “become cloud-native,” including legacy ERP systems, mainframes, and latency-sensitive trading applications.
What was misunderstood
- Some workloads had hard latency, data residency, or licensing constraints.
- The applications were tightly coupled, stateful, and designed for vertical scaling.
- Cost models were not analyzed beyond infrastructure savings.
Issues that emerged
- Higher total cost of ownership due to egress fees, oversized instances, and always-on resources.
- Performance degradation for low-latency systems.
- Operational complexity increased without gaining elasticity or resilience benefits.
- Missed opportunity to modernize selectively (hybrid or refactor where justified).
Using Kubernetes for every architecture
Example
A team deploys all applications - including small internal tools, batch jobs, and simple APIs - onto a shared Kubernetes platform.
What was misunderstood
- Kubernetes is an orchestration platform, not a free abstraction layer.
- Many workloads did not need container orchestration, autoscaling, or self-healing.
- The organization lacked operational maturity for cluster management and security.
Issues that emerged
- Increased cognitive load for developers (YAML, Helm, networking, ingress, RBAC).
- The platform team became a bottleneck for simple changes.
- Security misconfigurations (over-permissive service accounts, exposed services).
- Slower delivery compared to simpler deployment models (VMs or managed PaaS).
Using Serverless for every solution
Example
An architect mandates that all new services must be implemented using Functions-as-a-Service.
What was misunderstood
- Serverless excels at event-driven, stateless, bursty workloads - not long-running or chatty processes.
- Cold starts, execution limits, and state management trade-offs were ignored.
- Observability and debugging differ significantly from traditional services.
Issues that emerged
- Latency spikes impacting user-facing APIs.
- Complex orchestration logic is spread across functions, reducing maintainability.
- Higher costs for sustained workloads compared to containers or VMs.
- Difficult troubleshooting due to fragmented logs and distributed execution paths.
Using GenAI to solve every problem
Example
A company integrates GenAI into customer support, code reviews, security analysis, and decision-making workflows without clearly defined use cases.
What was misunderstood
- GenAI produces probabilistic outputs, not deterministic answers.
- Data quality, context boundaries, and hallucination risks were underestimated.
- Regulatory, privacy, and intellectual property implications were not assessed.
Issues that emerged
- Incorrect or misleading responses are presented as authoritative.
- Leakage of sensitive data through prompts or training feedback loops.
- Increased operational risk when AI outputs were trusted without validation.
- High costs with unclear ROI due to overuse in low-value scenarios.
Practical recommendations
- Start with business drivers, not technology - Define success metrics first: cost model, performance requirements, regulatory constraints, delivery speed, and operational ownership. Technology should follow these inputs - not precede them.
- Explicitly document constraints and non-goals - Latency, data residency, licensing, team skills, and operational maturity must be captured early. Many architectural failures stem from ignored or implicit constraints.
-
Apply technologies where their strengths are essential:
- Public cloud: prioritize elasticity, managed services, and global reach - not lift-and-shift.
- Kubernetes: use it where orchestration, portability, and scale justify its complexity.
- Serverless: limit the use of Serverless to event-driven and bursty workloads.
- GenAI: apply where probabilistic output is acceptable and verifiable.
Favor simplicity as a default - If a simpler architecture meets requirements, it is usually the correct choice. Complexity should be earned, not assumed.
Continuously validate assumptions - Revisit architectural decisions as workloads evolve. What was once justified can become technical debt when context changes.
Reward outcome-driven architecture - Measure architects and teams on business impact, reliability, and cost efficiency - not on adoption of trendy platforms.
Summary
The recurring failure pattern in modern architectures is not poor technology choice, but premature commitment to a tool before understanding the problem. Cloud platforms, Kubernetes, Serverless, and GenAI are powerful when applied deliberately - and damaging when treated as universal defaults. When architects start with the solution, they optimize for platform elegance instead of business outcomes.
About the author
Eyal Estrin is a seasoned cloud and information security architect, AWS Community Builder, and author of Cloud Security Handbook and Security for Cloud Native Applications. With over 25 years of experience in the IT industry, he brings deep expertise to his work.
Connect with Eyal on social media: https://linktr.ee/eyalestrin.
The opinions expressed here are his own and do not reflect those of his employer.
Top comments (0)