Serverless or Kubernetes: the criteria Japanese teams should actually be looking at

The real question behind “what is serverless?”

Most people who search for a definition of serverless are not really after the definition. What they want to know is whether to move their systems toward serverless or commit to Kubernetes. This article is not a glossary entry; it is about an architecture decision.

The conclusion first: the two are not opposing options. The real decision is a placement problem — which workload belongs on which execution model — and in most systems both end up coexisting. The moment you frame it as a binary, the discussion turns into a matter of taste and the criteria disappear.

Serverless is not one technology

The main reason these debates go nowhere is that “serverless” refers to at least three different things.

• FaaS — AWS Lambda, Google Cloud Functions, Azure Functions. You deploy at function granularity and invocations are event-driven. Execution-time limits, package size constraints and a restricted runtime environment come with the territory.
• Managed container runtimes — Google Cloud Run, AWS App Runner, ECS Fargate, Azure Container Apps. You hand over a container image and delegate node and scaling management to the provider. Runtime freedom is the same as with any container.
• Serverless data stores — Aurora Serverless, DynamoDB on-demand and equivalents. You stop pre-provisioning capacity and pay against actual consumption.

These three differ in their constraints, their cost structure and their operational failure modes. “Serverless has an execution-time cap, so it won't work” is true of FaaS and false of managed containers. “Serverless means heavy lock-in” weakens considerably when your build artifact is a container image. Conflating the three means discarding viable options before the analysis even starts.

What Kubernetes actually gives you

Kubernetes is not “a way to run containers.” It is a substrate for building your own declarative platform. The value is having scheduling, service discovery, rolling updates and resource control behind one API. The price is permanent ownership of cluster upgrades, network policy, certificates, observability and access design.

So the Kubernetes decision is not about technical superiority. It reduces to an organisational question: is there a team that can carry that operational responsibility, continuously? Skip that question and you end up with a cluster that runs but that nobody wants to upgrade.

Criterion 1 — load profile

The shape of the load is the single most discriminating criterion. Workloads with periods that drop close to zero and occasional spikes — internal admin tools, event-triggered APIs, campaign-driven processing — fit an execution model that does not bill idle time. Workloads that hold a near-constant load around the clock can keep reserved capacity at high utilisation, which favours instances and node pools.

Look at the peak-to-trough ratio and how long peaks last, not at averages. Reasoning from average request counts misleads you on both billing and scaling behaviour.

Criterion 2 — cold starts and latency requirements

Cold starts should be assessed by where they surface, not by whether they exist. A delay on a synchronous path that blocks a user is a different problem from a delay hidden behind asynchronous processing. For batch jobs or queue consumers, first-invocation latency is usually irrelevant.

Even on a strict synchronous path the choice is not all-or-nothing: minimum instance counts, moving initialisation out of the request path, and lighter-startup runtimes all mitigate it. Start by defining who actually sees the delay.

Criterion 3 — execution time, networking, state

• Execution time — FaaS caps how long an invocation can run, which forces long batch jobs, video transcoding and large data transformations into a split design. Managed containers or job runners express these far more naturally.
• Network complexity — connections to databases inside a VPC, partners who require a fixed source IP, dedicated links to on-premise environments. Once these are in play, the serverless side needs VPC integration, connectors and NAT design, and the “less configuration” advantage thins out. In Japan, IP-restricted integrations with partner systems are still widespread, so this needs checking early.
• Stateful requirements — long-lived WebSocket connections, reliance on in-memory caches, processing that assumes local disk. These sit badly with serverless execution models, and the cost of externalising them has to be estimated up front.

Think in billing mechanics, not unit prices

The most common mistake in cost comparison is lining up price tables. Prices get revised and discounts depend on contract terms. What holds steady is the billing mechanism.

• Consumption-based (serverless) — you are billed on request count and on execution time multiplied by allocated resources. Cost tracks usage, and idle time costs close to nothing.
• Reserved (instances / node pools) — you are billed for the time something is running. Cost tracks the capacity you reserved, regardless of how much of it was used.

The break-even point is therefore utilisation. If you can keep reserved capacity busy, reserved wins on unit cost; if utilisation is low or unpredictable, consumption-based wins.

Two costs are routinely left out of the comparison. On the Kubernetes side, the indirect ones: control plane, monitoring and logging stack, and above all the human time that keeps the cluster alive. On the serverless side, data transfer and inter-service integration, which accumulate as the architecture fragments. Comparisons that ignore both almost always reach the wrong conclusion.

The method is simple: run your own measured traffic through both billing models. Published pricing plus your own metrics is a far more trustworthy basis than someone else's case study.

What is specific to the Japanese market

Everything above holds anywhere. Japan adds a set of conditions that genuinely change the decision. These are not cultural generalities — only the factors that show up in the design or in the contract.

• Data residency and compliance — in finance, healthcare and the public sector, where data is stored and whether you can explain the architecture to an auditor are hard requirements. Availability of a domestic region, and conformance with the FISC security guidelines or with government procurement requirements (notably ISMAP registration for cloud services) narrow the option set from the outset. Managed services reduce operational load, but check first whether the provider will disclose what an audit will ask for.
• The SIer division of labour — many Japanese organisations outsource infrastructure build and operations to systems integrators. When that is the case, “you no longer operate the infrastructure” is a change to the contract structure, not just to the architecture. If the existing maintenance contract is priced per person-month, the technical optimum and the contractual optimum diverge. Leaving that unresolved while the technical review proceeds means stalling at implementation.
• SRE and platform engineering supply — choosing Kubernetes means committing to hire and retain the people who will run it. The domestic SRE market is tight, and an architecture that depends on one individual is a business risk. If hiring is not realistic, pushing operational responsibility to the provider is the sounder design.
• The ringi decision process — Japanese capital and architecture decisions typically go through ringi, a circulated written approval. That means the decision is documented and will be re-examined later. What passes is not “this is new” but “we judged it against these criteria.” Framing the rationale in terms of load profile, latency requirements and operating capacity speeds up approval and makes the future review straightforward. Whether predictable reserved cost or usage-linked variable cost is easier to defend internally is, in practice, a real factor too.
• Migrating off on-premise — a large share of production systems still run on-premise. Jumping straight to serverless as the first migration target usually means a large rewrite. Containerising first, landing on a managed container platform, then shifting the parts that fit toward FaaS and serverless data stores, spreads the risk far better.

A decision framework

Putting it together, work through it in this order.

1. Decompose the workloads. Do not try to fit the whole system into one answer. Separate synchronous APIs, asynchronous jobs, scheduled batches and long-running processes.
2. Check the disqualifiers first: data residency, regulatory requirements, network constraints, execution-time caps. Eliminate what you cannot choose.
3. Measure the load profile: peak-to-trough ratio, peak duration, whether there are near-zero periods.
4. Define latency requirements for synchronous paths only. Be explicit about whether a cold start is visible to a user.
5. Assess your operating capacity honestly. Do you have the people to run Kubernetes now, and can you keep them?
6. Run your measured figures through both billing models. Include the indirect costs.
7. Document the rationale — including what would have to change for the decision to be revisited.

The first two steps cut the option set down to what is realistic, which is what makes the rest of the discussion concrete. That is why the order matters.

Where this usually lands

For most teams the realistic outcome is not consolidation on one side. Variable-traffic and greenfield services go on a managed container platform; event-driven processing and scheduled jobs go to FaaS; core systems under sustained high load, and cases where many services need standardising on one platform, go on Kubernetes. That placement keeps operational load within what the team can carry while keeping cost explainable.

What to avoid is starting from generalities — “serverless is cheaper,” “Kubernetes is the industry standard.” Both are only conditionally true. The decision always starts from the shape of your workloads and the operating capacity of your team.