Problem
The platform needed to serve two different but connected user groups: business teams managing omnichannel content and engineering teams delivering web applications, APIs, and backend services.
Business users needed a governed content lifecycle covering design, moderation, publishing, versioning, translation, and feedback workflows.
Engineering teams needed a faster route from code to production without repeatedly managing DNS, networking, security, storage, OAuth, Kubernetes configuration, deployment pipelines, and operational tooling.
Constraints
The platform had to operate within enterprise cloud landing-zone, security, networking, and governance standards.
It needed to support both internal and externally exposed workloads across web applications, REST APIs, WebSocket services, GraphQL APIs, and backend services.
Networking required hub-spoke topology, corporate VPN integration, private connectivity, subnet segmentation, cross-subscription peering, private DNS, and controlled Kubernetes control-plane access.
The platform also needed strong workload isolation, multi-tenancy, reusable security controls, software supply-chain protection, and a scalable onboarding model for additional teams.
Architecture
The solution was designed as a shared Platform-as-a-Service with two primary experiences: a business content platform and a developer application delivery platform.
Contentful provided headless content management for content design, moderation, lifecycle management, publishing, and versioning.
Azure Kubernetes Service formed the primary compute layer for web applications, API services, and backend workloads.
Azure API Management provided governed API exposure, authentication, throttling, reusable policies, and traffic controls.
Akamai provided CDN and public DNS capabilities, while Azure networking, private DNS, Entra identity, storage, secrets, monitoring, and logging formed the shared platform foundation.
GitHub Actions and Argo CD provided CI/CD and GitOps-based application and platform delivery.
Decisions
The platform was treated as a product rather than as a collection of infrastructure components.
A Platform-as-a-Service model was adopted so application teams could consume standardized capabilities instead of independently managing infrastructure concerns.
Open-source and CNCF technologies were preferred where suitable, with technology choices validated through proofs of concept.
GitOps was selected as the primary deployment and configuration model using reusable GitHub Actions workflows and Argo CD.
Multi-tenancy was designed into the platform using workload isolation, Kubernetes network policies, Kyverno policies, node-pool segregation, and network boundaries.
Split-origin DNS and separate control-plane and user-traffic paths were introduced to align with enterprise cloud and security requirements.
Implementation
Designed and contributed hands-on to the Azure AKS-based Web App Platform as a reusable Platform-as-a-Service offering.
Implemented hub-spoke networking with corporate VPN integration, virtual networks, subnet segmentation, gateway subnets, workload subnets, network peering, and automated private DNS.
Built reusable GitHub Actions workflows and Argo CD GitOps patterns for code-to-container and service deployment.
Created reusable Kubernetes templates for application services and pod deployments, including node-pool selection and workload scheduling patterns.
Automated multi-architecture OCI-compliant container image creation and introduced Trivy-based vulnerability scanning, SBOM generation, provenance, and security baseline validation.
Implemented workload isolation using Kubernetes network policies, Kyverno, affinity and anti-affinity rules, taints, tolerations, and dedicated node pools.
Automated public and private DNS configuration for externally exposed web applications, REST APIs, WebSocket services, and GraphQL services.
Implemented reusable Azure API Management policies for request throttling, SSL enforcement, authentication flows, authorization injection, URL redirection, error handling, and reusable policy snippets.
Integrated observability through New Relic, Azure Monitor, Azure Log Analytics, and Slack or Teams notifications.
Supported use-case discovery, product roadmap development, backlog prioritization, platform onboarding, governance, promotion, and SLA management together with product owners, technical leads, business owners, and content teams.
Business Capabilities
Business teams gained a governed omnichannel content lifecycle covering content creation, moderation, approval, publishing, versioning, translation, and feedback.
The platform provided standardized content distribution for large user populations and multiple digital channels.
The content platform created a foundation for AI-assisted use cases such as draft-content generation and automated content translation.
Business users could manage content independently from application release cycles while retaining governance and lifecycle controls.
Developer Capabilities
Engineering teams gained a standardized code-to-web delivery path for web applications, APIs, backend services, and other digital workloads.
Self-service capabilities abstracted common concerns such as DNS, networking, security, OAuth, storage, ingress, deployment configuration, and observability.
Reusable templates, GitOps workflows, API policies, infrastructure automation, and deployment standards reduced repeated engineering effort.
Teams could focus on application functionality while consuming platform capabilities through established interfaces and paved-road patterns.
Outcome
The initiative evolved from a project-level solution into a more mature digital product and platform offering serving both business and engineering teams.
Business users gained a governed foundation for omnichannel content management and distribution.
Engineering teams gained a repeatable and secure route from code to production with substantially less infrastructure overhead.
Reusable automation, GitOps workflows, API policies, networking patterns, security controls, and observability improved consistency and developer productivity.
Multi-tenancy, workload isolation, standardized onboarding, and shared infrastructure created a scalable foundation for adding more teams and workloads.
Reserved and spot compute, node pools, affinity rules, taints, and tolerations introduced repeatable workload scheduling and cost-optimization patterns.
What we learned
A successful Platform-as-a-Service can serve both business and engineering users when business capabilities and technical platform capabilities are designed as parts of the same product.
Content management, application delivery, identity, networking, security, observability, governance, and developer experience need to be treated as connected platform concerns rather than separate implementations.
Platform maturity depends not only on infrastructure automation but also on roadmap ownership, onboarding, governance, SLAs, reusable standards, and close collaboration with business and engineering stakeholders.
The most effective platform abstractions remove repetitive infrastructure complexity while preserving clear ownership and operational boundaries for application teams.