Setting Up Container Orchestration for a Manufacturer's Cloud Systems

List every service that touches customer-facing quoting, order status, or ERP and MES data sync. For most shops this is a handful of services: a web app, an API layer, and a set of scheduled jobs that sync data with the ERP.

Don't count the machine controllers or shop-floor systems in this inventory. They're a separate world with separate constraints, and conflating them with your cloud container platform decision leads to overbuilding for a problem you don't actually have.

For a handful of services with steady, predictable traffic, mostly internal staff and a modest number of customers checking order status, ECS is almost always the right starting point. There's no meaningful autoscaling or multi-tenant isolation problem to solve here that justifies Kubernetes's added operational overhead.

Reserve Kubernetes for a manufacturer running a genuinely large customer portal serving many downstream customers with their own logins and dashboards, where the scale starts to resemble a SaaS product more than an internal tool.

This is usually the trickiest part of a manufacturer's cloud footprint: syncing order data, inventory, and job status between a cloud-hosted quoting or portal system and an on-premises ERP or MES. Whichever platform you choose, isolate this integration layer as its own service with its own retry and error-handling logic, since a failed sync silently dropping a customer's order update is the failure mode that actually costs you a relationship.

Test the integration layer's failure behavior deliberately: disconnect the ERP connection mid-sync and confirm the system retries correctly rather than losing or duplicating records.

A manufacturer's customer-facing traffic is nothing like a consumer SaaS product's; it's a known, relatively small set of business customers checking on orders, not thousands of anonymous visitors. Oversizing an ECS task fleet or a Kubernetes node pool for traffic that never materializes is a common, avoidable cost.

Across a subscription business at large, hosting spend typically runs around 5% of ARR at the median¹; a manufacturer's much smaller customer-facing footprint should cost proportionally less, and a bill that doesn't reflect that is worth investigating before adding anything new.

Manufacturing companies often don't have a large in-house software team, and the person who builds this system may not be the person maintaining it in two years. Write the runbook assuming the next person has never seen a container platform before: what triggers a deploy, where secrets live, and what to check first when the ERP sync stops working.

Kubernetes vs. AWS ECS vs. Nomad is worth a read if part of this system needs to run on hardware physically located at the plant rather than in the cloud.

Write the runbook so it tells the next person:

• What triggers a deploy, assuming the reader has never seen a container platform before.
• Where secrets live and who can rotate them.
• What to do when a service fails, including how the ERP integration layer retries and alerts.
• Which services are in scope, so the shop-floor machine controllers are never mistaken for part of the cloud platform.

Contract manufacturers frequently build the ERP integration and customer portal carefully, then bolt a quoting calculator onto the side as a smaller, less-tested piece of the same system. That's backwards from a business risk standpoint, since a wrong quote based on a bug in the calculator, not the ERP sync, is what actually costs margin on a job that's already been won and is now underpriced.

Give the quoting logic the same testing discipline as the rest of the system: version it deliberately, test it against known jobs with known correct pricing, and treat a quoting bug as seriously as an ERP sync failure, even though it's less likely to page anyone at 2 a.m.

Some manufacturers land on a hybrid where the customer-facing portal runs on ECS for simplicity, while a separate, more compute-intensive scheduling or optimization job, used to sequence work across machines, runs as a scheduled Kubernetes Job or a standalone EC2 process because it needs more control over resource allocation than a typical web service.

There's nothing wrong with splitting the decision this way. Forcing every workload onto a single platform for the sake of consistency sometimes costs more in awkward fit than it saves in operational simplicity.