Why We Consult, Not Implement: The Case for Pure Kubernetes Advisory

The Kubernetes consulting market has a structural problem. Most firms offer a bundled service: they'll assess your infrastructure, design the architecture, implement it, and then offer ongoing managed services to keep it running. On the surface, this sounds convenient. In practice, it creates a dependency that's expensive to maintain and nearly impossible to exit.

At k8s.sa, we made a deliberate choice to offer pure advisory services. We don't write your Terraform modules. We don't manage your clusters. We don't hold the keys to your production environment. Instead, we sit alongside your team, provide expert guidance, review their work, and ensure they're building something they can own and operate independently.

This isn't the easy path — for us or for our clients. But after years of seeing the alternative play out, we're convinced it's the right one.

The Problem with Bundled Implementation

When the same firm that advises you also implements the solution, the incentives are misaligned from day one. Consider the dynamics:

• Complexity is profitable. A consultancy that bills for implementation hours has no incentive to recommend the simplest solution. A three-cluster service mesh architecture generates more revenue than a single-cluster setup with well-configured NetworkPolicies — even if the latter is what you actually need.
• Dependency is the business model. If your team can't operate the infrastructure without the consultancy, that's recurring revenue. Knowledge transfer is a cost center for implementation firms, not a priority.
• Tool choices are biased. Firms that partner with specific vendors (cloud providers, service mesh companies, monitoring platforms) will recommend those tools regardless of whether they're the best fit for your use case.

We've seen this pattern repeatedly in client engagements. An organization hires a consultancy to "set up Kubernetes." Six months later, they have a complex, over-engineered platform that only the consultancy understands. The internal team feels alienated from their own infrastructure. The monthly managed services bill keeps growing. And switching providers means rebuilding from scratch because everything is built around the consultancy's proprietary tooling and conventions.

The Pure Advisory Model

Pure advisory flips this dynamic. Here's what it looks like in practice:

Your Team Grows Stronger

The most valuable outcome of a consulting engagement isn't the infrastructure — it's the capability your team builds. When your engineers write the Helm charts, configure the CI/CD pipelines, and troubleshoot the networking issues (with expert guidance), they develop deep understanding that no amount of documentation can replace.

The Difference in Practice

Consider a common scenario: your team needs to set up Ingress with TLS termination. In a managed implementation model, the consultancy writes the Ingress manifests, configures cert-manager, and hands you a working setup. Your team knows it works but doesn't understand why it's configured that way or how to troubleshoot it when something breaks.

In our advisory model, the conversation goes differently:

"Your Ingress controller needs to handle TLS termination. You have three options: Traefik, Nginx Ingress Controller, or the Gateway API with an implementation like Envoy Gateway. Given your traffic patterns and the fact that your team already has Envoy experience, I'd recommend Gateway API with Envoy Gateway. Here's why, and here are the trade-offs. Now, let's walk through the configuration together — you write it, I'll review it."

The result is the same working infrastructure, but your team understands the decision, the alternatives, and the configuration. When something breaks at 2 AM, they can fix it without calling us.

Pair Programming, Not Outsourcing

Our engagements often look like pair programming sessions. We join architecture discussions, review pull requests, sit in on incident retrospectives, and provide real-time guidance during complex operations. The goal is always the same: transfer knowledge as fast as possible so the engagement can end.

This means we actively work to make ourselves unnecessary. That might sound like bad business, but it's actually the opposite — clients who build strong internal teams become our best referral sources. They recommend us precisely because we didn't create a dependency.

Unbiased Recommendations

When we don't implement the solution, we have no financial incentive to recommend one tool over another. Our revenue is the same whether you choose EKS or GKE, Datadog or Grafana Cloud, ArgoCD or Flux.

This independence matters more than most organizations realize. The Kubernetes ecosystem is vast, and the "right" tool depends entirely on your context — team size, existing skills, compliance requirements, budget, and growth trajectory. A consultancy with a Datadog partnership will recommend Datadog. A consultancy with AWS certifications will recommend EKS. We recommend whatever actually fits.

Real-World Example: Monitoring Stack

A recent client asked us to recommend a monitoring stack. A vendor-aligned consultancy would have recommended their partner's commercial platform. Here's what we actually recommended:

• Metrics: Self-hosted Prometheus with Thanos for long-term storage — because the client had a 3-person platform team with strong Prometheus experience and a tight budget. Datadog would have cost 4x more with no meaningful benefit for their scale.
• Logging: Grafana Loki instead of Elasticsearch — because their log volume was moderate, and Loki's operational simplicity was a better fit for a small team than managing an Elasticsearch cluster.
• Alerting: Alertmanager with PagerDuty integration — because they already had PagerDuty and didn't need another tool in the chain.

A different client with 50 engineers and a larger budget? We recommended Datadog — because at their scale, the operational overhead of self-hosted monitoring wasn't worth the cost savings. Same consultancy, different recommendation, because the context was different.

Avoiding Vendor Lock-In

Vendor lock-in in Kubernetes comes in many forms, and it's not always obvious:

• Cloud-specific services: Using AWS ALB Ingress Controller, GKE Autopilot features, or Azure-specific storage classes ties your manifests to a single cloud provider.
• Proprietary abstractions: Some consultancies build custom Helm charts or Terraform modules that wrap standard Kubernetes resources in proprietary abstractions. When the engagement ends, you're stuck maintaining code you didn't write and don't fully understand.
• Commercial add-ons: Service meshes, policy engines, and security platforms that require ongoing licenses create long-term cost commitments that are hard to reverse.

Our advisory approach explicitly addresses this. We recommend cloud-agnostic solutions where possible, use standard Kubernetes APIs over provider-specific extensions, and ensure that every piece of infrastructure your team builds uses well-documented, community-supported tools.

When Advisory Isn't the Right Fit

We believe in intellectual honesty, so let's be clear: pure advisory isn't right for every organization.

• No internal engineering team: If you don't have engineers who will own the infrastructure, advisory doesn't work. You need someone to receive the knowledge transfer. In this case, a managed service provider is the right choice — but choose one with clear SLAs and exit terms.
• Extreme time pressure: If you need a production Kubernetes cluster in two weeks for a regulatory deadline, you don't have time for the advisory model. Get it built, then engage advisory to review and improve it.
• Highly specialized domains: Some areas (GPU scheduling for ML workloads, high-frequency trading infrastructure) require such deep specialization that having an expert implement it directly is more efficient than guiding a team through it.

We turn down engagements that aren't a good fit for our model. It's better for the client and better for our reputation.

What a Typical Engagement Looks Like

Our engagements typically follow this pattern:

1. Discovery (1–2 weeks): We assess your current state, interview your team, review your architecture, and identify gaps. The output is a prioritized roadmap.
2. Active advisory (4–12 weeks): We work alongside your team — reviewing PRs, joining architecture sessions, providing guidance on implementation decisions, and conducting knowledge-sharing sessions.
3. Validation (1–2 weeks): We conduct a final review of the implemented architecture, run security and performance audits, and document any remaining recommendations.
4. Handoff: We deliver a comprehensive report and ensure your team is confident operating independently. We're available for ad-hoc questions for 30 days after the engagement ends.

The total engagement is typically 6–16 weeks. Compare that to managed implementation contracts that often run 12–24 months with no clear end date.

The Bottom Line

Kubernetes is complex, but it's not magic. Your team can learn to operate it effectively with the right guidance. The question isn't whether you need expert help — you probably do. The question is whether that help should come in the form of someone doing the work for you, or someone teaching you to do it yourself.

We believe the answer is clear. The organizations that thrive with Kubernetes are the ones that own their infrastructure, understand their architecture, and can respond to incidents without calling a vendor. Pure advisory is how you get there.