One dependable data path from the plant floor to the cloud
Edge-to-cloud infrastructure connects equipment and sensors in physical locations — plants, warehouses, field sites — to cloud systems, with computing at the edge where latency, bandwidth, or reliability demand it. It removes the two classic failure modes: data that dies on the network when the WAN link drops, and cloud dashboards that quietly show stale numbers.
Willowark builds these pipelines on the assumption that every link fails eventually. Edge nodes buffer with store-and-forward, protocols are chosen for constrained networks — usually MQTT with appropriate QoS — and cloud ingestion is idempotent, so a reconnecting site can replay hours of backlog without duplicating a single reading.
Cloud & InfrastructureHow the work gets done
The same way every time: scope, build, hand over.
A typical build pairs industrial protocol handling at the edge — OPC UA, Modbus, Ethernet/IP — with an edge runtime for local processing: filtering, downsampling, and running logic that cannot wait on a round trip. Gateways run hardened Linux with disk-backed queues sized to survive realistic outages. On the cloud side, an MQTT broker or IoT platform feeds time-series storage, and fleet management handles the part people underestimate — updating and monitoring dozens or hundreds of remote boxes without driving to them.
In production, the measure is data integrity across failure: pull the network cable on a gateway for an hour, plug it back in, and the historian should show a complete record with no gaps and no duplicates. Beyond that, success means remote sites that update themselves, certificate rotation that happens on schedule, and one clear view showing which locations are healthy right now.
Scoping begins at the site, not the cloud. We survey what equipment exists, which protocols it speaks, how the plant network is segmented, and what the WAN link actually looks like — bandwidth, cost per byte, and how often it fails. That determines the edge hardware and the buffering requirement. The trade-offs are practical: MQTT with QoS 1 costs bandwidth for acknowledgments but guarantees delivery, sampling at the edge reduces cost but discards detail you may later want, and a full IoT platform simplifies fleet management while adding vendor dependency. We prototype with one gateway on one line before designing for the fleet.
What goes wrong in edge deployments is usually mundane: a clock that drifts and corrupts timestamps, an SD card that wears out under constant writes, a certificate that expires on a gateway nobody can reach, an update that bricks a device with no rollback partition. We design against each one — NTP with sane fallbacks, industrial-grade storage sized for the write load, automated certificate renewal well before expiry, and A/B update slots so a failed update reverts on its own. Handover includes provisioning documentation so your team can commission a new site, the fleet dashboard, and a maintenance schedule for the physical hardware.
Scope it in writing
What we agree before work starts
- Edge gateway architecture with store-and-forward buffering
- Protocol integration (OPC UA, Modbus, MQTT) from equipment to cloud
Build with checkpoints
Working results, not slide decks
- Idempotent cloud ingestion with time-series storage
- Fleet management for remote updates and certificate rotation
Hand over something you own
Documentation, source, and training
- Failure-mode test results: network loss, power loss, backlog replay
- Site commissioning guide and provisioning scripts for bringing a new location online
Sound familiar?
Where edge-to-cloud infrastructure earns its keep.
Five plants reporting to one dashboard over links that drop weekly
A remote pump station that needs local shutdown logic and cloud reporting
Sensor data billed by the megabyte over a cellular connection
A gateway fleet that requires a site visit every time it needs an update
Ask about Edge-to-Cloud Infrastructure
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
AI operating software for training operations
Components:
- Schedulers (training ops): The people running the training operation.
- Operating software (AI assistance): The operating software, with AI assistance built in.
- Cloud services (distributed): Distributed cloud services behind the application.
- Training game (learning): The training game the software connects to.
Connections:
- Schedulers to Operating software
- Operating software to Cloud services
- Operating software to Training game
A global automotive manufacturer's training operation · Automotive
AI operating software for training operations
AI operating software for the manufacturer's training schedulers — removing manual scheduling labor and logistics tracking, saving hundreds of hours per year — plus a training video game built to help trainers perform better. Used across the manufacturer's training organization.
Read the case study →Common questions
Asked before every edge-to-cloud infrastructure project.
What happens to the data when the internet connection drops?
It queues at the edge. Gateways write to disk-backed local storage and replay to the cloud when connectivity returns, in order, with deduplication on the receiving side. We size buffers for your realistic worst-case outage — usually days, not minutes.
How much processing should happen at the edge versus the cloud?
Edge handles what cannot tolerate a round trip or a dead link: safety-adjacent logic, high-frequency filtering, local alarms. Cloud handles what benefits from the full picture: cross-site analytics, model training, long-term storage. The split follows latency and failure requirements, not fashion.
Can this work with our existing PLCs and equipment?
Almost always. Modern PLCs speak OPC UA or Ethernet/IP directly; older equipment usually exposes Modbus, a serial port, or at minimum analog signals a hardened I/O module can read. Getting data off brownfield equipment is normal work, not an exception.
What hardware do you use for edge gateways?
It depends on the environment and the workload. For plant floors we typically use industrial-rated gateways or fanless PCs with wide temperature tolerance, DIN-rail mounting, and appropriate ingress protection; for lighter duty, smaller single-board computers can be adequate. We favor hardware with a mainstream Linux distribution, hardware watchdogs, and reliable storage over anything that ties you to a single vendor's software stack, and we test candidates on site before committing to a fleet.
How is the edge-to-cloud connection secured?
Each gateway gets its own identity — a device certificate issued by your own or the cloud provider's certificate authority — and all traffic runs over TLS. Gateways connect outbound only, so no inbound ports are opened on the plant network, and the plant side is segmented so a compromised gateway cannot reach the controllers directly. Credentials are rotated automatically, and revoking a single device's access is a routine operation rather than an emergency.
Where this sits
Edge-to-Cloud Infrastructure, inside a cloud & infrastructure system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Plant systems reach the cloud over an encrypted tunnel; services run in containers over managed data stores, and monitoring alerts a person before a customer notices.
Components:
- Plant network: OT network, segmented from IT.
- Tunnel (VPN / private link): Encrypted, allow-listed, no inbound ports on the plant side.
- Services (containers): Deployed from CI, rolled back in one command.
- Data stores (DB, objects): Managed database and object storage with backups tested, not assumed.
- Monitoring (logs, metrics): Health, latency, error rate, cost.
- On-call: Someone is paged before a customer emails.
Connections:
- Plant network to Tunnel over VPN
- Tunnel to Services over MQTT
- Services to Data stores over SQL
- Services to Monitoring over events
- Monitoring to On-call over push
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.