Moving beyond docker-compose is always painful: three services on one machine, migrating from on-prem to the cloud, or production screaming 'down, fix it'. We design target architectures that won't require redoing the infrastructure in six months. Below is our experience and the tools we use. We design based on actual load, SLA, and team expertise—from a startup with a couple of microservices to an enterprise with hundreds of services and multi-cloud.
What problems does DevOps architecture design solve?
'Deploy Kubernetes' is not architecture. Kubernetes solves container orchestration but doesn't answer: how to isolate environments (namespace vs cluster), how to organize network interaction between services, how to manage secrets, how to deploy—GitOps via ArgoCD or push model via Helm in a pipeline.
A team of five people with three services and a team of fifty with two hundred microservices will get fundamentally different answers. The first likely doesn't need Kubernetes at all—ECS Fargate or Cloud Run will meet their needs with less operational overhead.
Why can't we just 'install Kubernetes'?
An orchestrator is only part of the puzzle. Without working out the network model, security policies, deployment strategy, and observability, the infrastructure will be fragile. We've seen projects where they 'just installed K8s', and within a month the team was drowning in manual operations and unstable deployments. Designing with Architectural Decision Records (ADRs) captures key choices and their rationale—this reduces technical debt and speeds up onboarding of new engineers.
How we design architecture: a real case
For a project with 30+ microservices, we chose GitOps via ArgoCD. We used ApplicationSet with a matrix generator—one declaration covers all services in all environments. A change in values.yaml triggers sync only for the affected service. RBAC in ArgoCD delineates who can sync to production. As a result, deployment time was reduced by 3 times, and human-error incidents by 70%.
GitOps vs Push deployment: what to choose?
| Criterion | GitOps (ArgoCD) | Push deployment (Jenkins) |
|---|---|---|
| Consistency | Declarative, cluster self-syncs | Imperative, depends on pipeline |
| Audit trail | Built-in, git history | Pipeline logs |
| Rollback | git revert -> automatic sync | Manual pipeline trigger |
| Complexity | Medium (requires GitOps culture) | Low (familiar approach) |
GitOps with ArgoCD outperforms push deployment by 3 times in recovery speed after a failure, as the cluster automatically returns to the desired state from git.
How to choose between managed Kubernetes and serverless?
The choice depends on scale and expertise. For 3-5 microservices, serverless (AWS Fargate, Google Cloud Run) offers lower operational overhead—no need to manage control plane, node groups, autoscaling. But for 30+ services, managed Kubernetes (EKS, GKE) is more cost-effective and flexible. We help calculate TCO considering both direct and hidden costs: licenses, personnel, downtime.
Comparison of observability approaches
| Criterion | Self-hosted LGTM | Datadog | Grafana Cloud |
|---|---|---|---|
| Cost for 10 services | ~$200/month | ~$800/month | ~$300/month |
| Maintenance complexity | High | Low | Medium |
| Customization flexibility | High | Medium | Medium |
| Lock-in | None | Yes | Moderate |
Self-hosted LGTM (Prometheus + Grafana + Loki + Tempo) with OpenTelemetry provides maximum flexibility and savings of up to 50% compared to Datadog as data volume grows. We'll help you choose the optimal option for your SLOs and budget.
Typical architectural mistakes and how to avoid them
Over-engineering from the start—Service Mesh for three services, multi-cluster without real need. Design for current load, with a buffer for 12-18 months.
Underestimating the network model—Single VPC without subnet separation. Designing VPC for future growth is easier than migrating later.
Ignoring cost optimization—Spot instances for stateless, Savings Plans for baseline, Karpenter for autoscaling. We incorporate this into the architecture, reducing costs by 20-30% compared to on-demand.
Work process and timelines
- Requirements gathering: load, SLA, team size and expertise, budget, regulatory requirements. (2-3 days)
- Draft architecture with stack selection: compute, network, CI/CD, secrets, observability, IaC. (3-5 days)
- Discussion of trade-offs with the team: cost vs flexibility, operational complexity vs control. (1-2 days)
- Final design with Architectural Decision Records (ADR). (2-4 days)
- Preparation of IaC skeleton and runbook for initial deployment. (3-7 days)
Estimated timelines: from 2 to 4 weeks depending on project complexity. Cost is calculated individually.
What is included in the work
- Architectural draft with diagrams and ADRs.
- IaC skeleton (Terraform, Pulumi)—immediately applicable.
- Runbook for initial deployment and troubleshooting.
- Recommendations on security, cost optimization, and observability.
- Training the team on GitOps, CI/CD, and new tools.
Get a consultation—we'll evaluate your project and propose a plan within 1-2 days. Contact us to discuss architecture without obligation. We also provide DevOps outsourcing services for ongoing infrastructure support.
Why choose us
We've been in DevOps for over 10 years, completed 50+ projects for companies of various sizes—from startups to enterprise. We guarantee that the architecture will be working and documented. Our engineers are certified (CKA, Terraform Associate). Contact us to evaluate your infrastructure. Order an architectural audit without obligation.
Based on Kubernetes documentation and Terraform best practices.







