-
Own Kubernetes/OpenShift integration end‑to‑end
- Ensure Quarkus can continue to be deployed easily on future OpenShift versions
- Maintain and evolve the developer experience for local Kubernetes development with Quarkus
-
Keep container build/deploy and developer‑portal paths healthy
- Maintain Gradle deploy flows; prevent regressions in CI/CD; track and apply upstream buildpack/platform updates.
- Own Backstage/Red Hat Developer Hub (RHDH) integration for Quarkus: curate catalogs, templates, and golden paths that encode Quarkus best practices (build, container, OpenShift deploy) and keep them current.
-
Provide guardrails across cloud‑deployment extensions and developer workflows
- Review changes for consistency and safety across modules; enforce standards reflected in Backstage templates and extension CLIs to avoid drift.
-
Author and maintain production‑grade operational guides and templates
- Keep OpenShift procedures accurate as platforms evolve.
- Maintain Backstage software templates and automation (catalog metadata, descriptors) so teams can self‑serve reliable Quarkus services from day one.
-
Manage lifecycle and simplification
- Deprecate or reshape modules/features that no longer fit strategy (e.g., service binding) and retire outdated templates/paths in the developer portal.
-
Build shared tooling primitives
- Provide and standardize CLI utilities for extensions and template generators; integrate with Backstage scaffolding for consistent developer ergonomics.
-
Triage and unblock quickly
- Resolve Kubernetes/OpenShift issues, coordinate across teams, and safeguard release cadence; ensure Backstage/RHDH remains a trustworthy source of truth (no broken templates or stale catalogs).
-
Quarkus adoption depends on first‑class Kubernetes/OpenShift and developer‑portal experience
- Many enterprise workloads target these platforms; correctness plus golden‑path onboarding (Backstage/RHDH) directly impact production stability, time‑to‑value, and adoption.
-
Upstream ecosystems change rapidly
- Kubernetes, buildpacks, Gradle, and OpenShift tooling evolve quickly; Backstage templates and catalogs must track these changes or they become liabilities.
-
High‑quality operational docs and golden paths reduce cost and lead time
- Accurate procedures and maintained templates lower support burden, shorten onboarding, and raise delivery consistency across teams.
-
Guardrails protect releases and trust
- Centralized ownership prevents regressions that are costly to remediate late in pipelines or post‑release and avoids template/catalog drift that confuses users.
-
Clear accountability improves execution at scale
- One owner for runtime integrations and the developer portal converts a fragmented, cross‑cutting surface into a managed capability with fast decisions and measurable outcomes.
-
Increased production and delivery risk
- Incorrect manifests or broken deploy integrations cause failed rollouts; stale Backstage templates lead to misconfigured services and inconsistent pipelines.
-
Missed upstream windows and falling behind
- Lag on buildpack/platform updates forces hotfixes and delays; developer‑portal content diverges from reality, eroding stakeholder confidence.
-
Growing support burden and slower onboarding
- Out‑of‑date OpenShift procedures and golden paths drive tickets and extend time‑to‑first‑value for new Quarkus services.
-
Accumulating technical debt and fragmentation
- Deprecated modules linger; tooling and templates diverge; developer experience becomes inconsistent across teams and environments.
-
Strategic slippage in cloud‑native differentiation
- Cloud‑native features and reliable golden paths slow, ceding advantage to competitors in Kubernetes‑centric environments.
Hiring for this role ensures Quarkus maintains a reliable, current, and differentiated cloud‑native deployment and developer‑portal experience—protecting customer outcomes, reducing operational risk, and sustaining release velocity.