4 posts tagged with "devops"

Parthenon Enterprise Edition has crossed an important infrastructure milestone: it now has a real Kubernetes deployment foundation.

This is not a marketing placeholder, and it is not a pile of disconnected YAML. The new work establishes a second, deliberately separate deployment lane beside the host-native VPS and bare-metal installer track. The native path remains focused on non-Docker Linux hosts. The Kubernetes path now has its own architecture, Helm chart, Terraform module, existing-cluster example, validation evidence, and todo trail toward cloud-provider orchestration on AWS, Azure, and GCP.

The point of this milestone is simple: Parthenon EE can support two very different enterprise realities without letting them blur into one fragile installer.

Eighteen Docker services. Three environment files. A reverse proxy with auto-TLS. Database admin GUI. Container management dashboard. Enterprise SSO. And if you want the full stack? One command:

python3 install.py --with-infrastructure

This is the story of how we built Acropolis — the infrastructure layer that turns Parthenon from a research application into a production platform — and what we learned when we decided to ship it inside the same repository.

Every platform has a weak link. For Parthenon, it was the R container.

PHP handled 200 concurrent API requests without breaking a sweat. Python served AI inference with async workers. PostgreSQL managed million-row queries across six schemas. Redis cached sessions at sub-millisecond latency. And then there was R — single-threaded, fragile, running bare Rscript as PID 1 with no supervision, no timeouts, and a health check that lied.

This is the story of how we tore it down and built Darkstar — a production-grade R analytics engine that runs OHDSI HADES analyses concurrently, recovers from crashes automatically, and executes 35% faster than the container it replaced.

The R runtime was the single most fragile component in the entire Parthenon stack. Every other service — PHP, Python AI, Solr, Redis, PostgreSQL — could handle concurrent requests gracefully. The R container could not. A single CohortMethod estimation on 1 million patients takes 5-30 minutes. During that time, the entire R process was locked — health checks timed out, status queries hung, and any other analysis request queued behind it with no feedback. This devlog covers the six-phase hardening effort that replaced the entire R runtime infrastructure in a single day.