Microservice Mike
“Every arrow deserves a container and a pager.”
Does one pipeline get its own container and a tiny flag?
Elevator answer
No. One pipeline is one business itinerary, not one shipping box. Several may share a runtime; one may cross runtimes where ownership, scale, or failure isolation earns the network.
3 coffee-machine misconceptions
Kubernetes Kai
“If it fits in one pod, it is a monolith.”
Enterprise Edna
“One Maven module, one deployable, one destiny.”
The real explanation
An order flow may validate, price, and reserve stock in one runtime, then hand fulfillment to another team. That does not require a pod for Validate, a pod for Price, and a tiny service mesh for the mapper between them. A pipeline describes the itinerary; a container is a decision about packaging, scaling, security, and who carries the pager.
PlaceOrder, CancelOrder, and GetOrderStatus can share one Orders deployment when the same team releases and scales them. PDF rendering may deserve separate placement if it consumes huge memory; Fulfillment may deserve it because another team owns the pager. Independent networking is a cost to justify, not a participation trophy for every flow.
TPF makes the logical runtime layout explicit so that placement is a design decision rather than an accidental result of package structure. It does not declare that every step, connector, or pipeline must become an independently deployed service. A generated adapter can be in-process. A connector can remain an edge of the same runtime. A checkpoint handoff may be a real cross-pipeline ownership boundary, but even that does not automatically mandate a new container.
The useful questions are practical: what must scale together, fail together, release together, and be observed together? What data and security boundary exists? What is the cost of a network call compared with the benefit of independent deployment? TPF helps keep the flow semantics available while the team answers those questions.
The trade-off is that the framework does not give a one-line deployment answer. Teams must resist both temptations: use one giant deployable because it is familiar, or create a service per pipeline because the model makes it possible.
Trade-offs
TPF gains explicit separation of flow and packaging. It gives up automatic topology decisions. Teams must choose deployment boundaries from operations and ownership, not from the number of arrows.
When TPF is not a good fit
If the goal is to mechanically split a monolith into services, TPF is not a decomposition robot. Start with real ownership and operational boundaries.