Microservices change the hosting question
A monolith asks "where do I run one thing well?" Microservices ask "how do I run twenty things, talk between them, observe them all, and not go bankrupt or insane?" The right platform for microservices is the one that minimizes per-service overhead: deploy, networking, secrets, logs, and metrics should scale to N services without N times the toil.
The three architectural approaches
| Approach | Examples | Strength | Weakness |
|---|---|---|---|
| Self-managed Kubernetes | EKS, GKE, AKS | Maximum control, portability | Steep ops; you own upgrades, networking, RBAC |
| Managed PaaS | Render, Railway, PandaStack | Low overhead per service | Less low-level control |
| Serverless / FaaS | Lambda, Cloud Run, edge functions | Scale-to-zero, pay-per-use | Cold starts, statefulness is awkward |
Most real microservice estates end up mixing these: long-running services on a PaaS or Kubernetes, spiky/event-driven work on serverless.
The hidden costs of microservices
Inter-service networking
Every service that talks to another needs service discovery, retries, timeouts, and ideally mTLS. On raw Kubernetes you'll reach for a service mesh (Istio, Linkerd) which adds power and complexity. On a PaaS you typically get internal networking and DNS handled for you.
Observability fan-out
With twenty services, a single user request might cross five of them. Without centralized logs and distributed tracing, debugging becomes archaeology. Budget for log aggregation and a metrics backend from day one, not after the first outage.
Build and deploy multiplication
Twenty services means twenty pipelines, twenty sets of secrets, twenty rollbacks. Anything that makes a single deploy cheaper pays off twenty-fold.
Kubernetes: powerful, but you own it
Kubernetes is the right answer when you need fine-grained control: custom controllers, complex networking policies, multi-cloud portability, or a dedicated platform team. The trade-off is that you now run a distributed system to run your distributed system. Upgrades, node pools, autoscaling tuning, RBAC, and ingress are all yours.
If you go this route, lean on managed control planes (GKE, EKS) so you're not also running etcd.
Managed PaaS: the pragmatic default
For most teams running 5-50 services, a managed PaaS hits the sweet spot. You get per-service deploys, internal networking, secrets, and observability without operating the cluster.
PandaStack runs every app on multi-region GKE with Kong ingress and Cloudflare DNS, but you never touch the cluster. Each service is just a Git repo: connect it, PandaStack auto-detects the framework or uses your Dockerfile, builds with rootless BuildKit in an ephemeral Job pod, pushes to Google Artifact Registry, and Helm-deploys it. Services that need a database get a managed one (PostgreSQL, MySQL, MongoDB, or Redis) with DATABASE_URL injected automatically.
For the spiky services in your estate, free-tier apps run with KEDA scale-to-zero on spot nodes inside a gVisor sandbox, so idle services don't burn money. The trade-off is a cold start on the first request after idle, which is exactly the kind of service you'd want scale-to-zero for anyway (internal tools, low-traffic webhooks).
# Each microservice = one repo connection.
# Service A (Node API), Service B (Python worker), Service C (Go gateway)
# all auto-detected and deployed the same way.Serverless: great for the edges
Event-driven and bursty workloads (image processing, webhook handlers, scheduled jobs) are a natural fit for functions. PandaStack includes edge functions and cronjobs alongside long-running containers, so you don't need a separate provider for the serverless parts of your architecture. Cloud Run and Lambda remain strong, mature options if you're already deep in GCP or AWS.
Observability across the estate
This is where microservices live or die. You want:
- Centralized logs searchable across services. PandaStack ships live build and app logs backed by self-hosted Elasticsearch.
- Metrics without bolting on an SDK. PandaStack captures server-side metrics and analytics into ClickHouse, so you don't have to instrument every service by hand.
- Distributed tracing for cross-service requests. On Kubernetes you'd add OpenTelemetry + a backend like Jaeger or Tempo; this is worth doing regardless of platform.
A sizing table
| Service type | Suggested compute | Why |
|---|---|---|
| Stateless API | c1/c2 compute-optimized | CPU-bound request handling |
| In-memory cache / aggregation | m1/m2 memory-optimized | Memory-bound |
| Low-traffic internal tool | Free tier + scale-to-zero | Idle most of the day |
| Background worker | Sized to job concurrency | Match to queue depth |
PandaStack compute ranges from Free (0.25 CPU / 512MB) to C2-2XCompute (8 CPU / 16GB, ~$0.300/hr), so you can right-size per service rather than paying for one big box.
Honest trade-offs
A PaaS abstracts the cluster, which is the point, but it also means you can't, say, install an arbitrary CRD or run a custom CNI plugin. If your microservices need that level of control, raw Kubernetes is the honest answer. PandaStack is also a newer platform, so if you need a battle-tested service mesh with years of community tooling, that ecosystem is more mature on self-managed Kubernetes today.
Recommendation
- 5-50 services, small/no platform team: Managed PaaS. Predictable, low overhead, observability included.
- Heavy custom networking or multi-cloud: Self-managed Kubernetes with a mesh.
- Bursty/event-driven slices: Serverless functions and cron, ideally on the same platform as your long-running services to keep ops unified.
The winning move for most teams is consolidation: long-running services, functions, cron, and managed databases on one platform so you debug one system, not five.
Want to deploy a few services and a database without standing up a cluster? PandaStack's free tier gives you five web services, a database, edge functions, and cronjobs to try the model. Start at https://dashboard.pandastack.io.
References
- Kubernetes documentation: https://kubernetes.io/docs/home/
- Google Cloud Run: https://cloud.google.com/run/docs
- Istio service mesh: https://istio.io/latest/docs/
- OpenTelemetry: https://opentelemetry.io/docs/
- KEDA (Kubernetes Event-Driven Autoscaling): https://keda.sh/docs/