honua
← Inside HonuaCOMPUTE & GEOPROCESSING

A spatial job deserves its own compute.

Separate the request, the job lifecycle, and the execution—so a two-hour analysis does not need the same capacity budget as a map query.

Honua · Engineering notes · Technical scope reviewed 2026-10-14

The script outgrows the laptop.

A useful spatial script eventually needs a life beyond the machine that runs it. Someone needs to submit it again, see its status, understand a failure, retrieve a result, and run it against a larger dataset.

Turning that script into operated work involves more than an HTTP endpoint. The system needs a job identity, durable coordination, an appropriate executor, and results the next person can inspect.

A recurring exposure analysis is an illustrative example: select assets, run supported operations, preserve parameters, and make outputs available. The exact process and backend must support the complete workflow; a diagram is not evidence that every Python script can be submitted unchanged.

Follow the work through the system.

Submit→Validate→Coordinate→Execute→Inspect results

The serving layer accepts and tracks work. Shared durable coordination keeps the job lifecycle separate from an individual serving process. A supported worker or batch backend performs the processing.

Honua exposes a canonical asynchronous job runtime behind interfaces including GPServer, OGC API Processes, gRPC, and MCP. Redis is required for the documented durable-job path. That is different from assuming that an ephemeral HTTP process can own the whole life of a long-running job.

Plans and process inputs should be validated before execution. Supported interfaces expose progress, status, cancellation, and results. A client should inspect the terminal outcome rather than interpret acceptance of a request as successful completion.

Give serving and processing separate capacity decisions.

A serving tier handles interactive traffic. Heavy processing gets compute sized for the process and dataset, with native dependencies alongside the worker that needs them. This keeps the serving image and lifecycle separate from heavyweight processing environments.

Deployment paths range from a containerized baseline to Kubernetes and cloud container services. Suitable processing can use supported Kubernetes Jobs or cloud batch backends. Backend support, credentials, dependencies, and process compatibility determine the actual placement choices.

Autoscaling is not inherently economical. Minimum capacity, database and coordination costs, startup delays, data transfer, and utilization still matter. The useful comparison is the complete workload at an acceptable latency and reliability level—not just a smaller serving container.

Failure is part of the contract.

Retries and cancellation need explicit meaning. A retried attempt should not silently duplicate consequential outputs; a cancelled or failed run should not be presented as a complete result. Durable state makes a failure inspectable, but does not make every operation automatically idempotent.

When evaluating a process, interrupt a worker or disconnect the client. Check what remains durable, whether work can be recovered or safely resubmitted, and how partial outputs are represented. Verify those behaviors for the chosen backend rather than infer them from a generic job-state diagram.

Python remains part of the workflow.

The Python SDK connects feature access, administration, geoprocessing, and the broader Python ecosystem. ArcPy-oriented migration tools can classify and convert supported patterns, with unsupported behavior left for review.

Package versions and migration coverage matter. Development-branch documentation is not a promise that every capability is present in an installed package. The right first integration is a narrow, repeatable process with known inputs and a result you can validate.

Evaluate the whole lifecycle.

Choose a representative process. Record the data, parameters, runtime version, resource limits, and execution backend. Measure queue time, execution time, output correctness, failure behavior, and total infrastructure cost.

Then run interactive queries at the same time. The architecture is useful when each workload can get its own capacity without turning the other into collateral damage.

The core promise is straightforward: a useful analysis becomes repeatable work—with a lifecycle and evidence someone else can understand.

Implementation references

These references describe the implementation and its current boundaries. Check release-pinned documentation before deployment.

KEEP EXPLORINGMake change routine—and reversible ↗