Enterprise Drupal Cloud Modernization & DevSecOps

The subscription, the billing, the identity boundary and the audit trail belong to the organization. Anyone operating the platform does so inside that boundary rather than instead of it.

The application is a standard Drupal codebase managed with Composer, which describes itself as a tool for dependency management in PHP. What the platform adds should sit around the application rather than inside it.

Site configuration lives in the repository and is imported on deploy, so an environment can be rebuilt from what is written down rather than from what somebody remembers doing.

The environment is defined in code that the organization holds, so a second region, a recovery environment or a replacement account is a repeat of a known procedure.

Runbooks, diagrams and decisions are deliverables, not tribal knowledge held by whoever is on the account this quarter.

Using a managed database, a managed cache or an edge platform is a reasonable engineering choice. Depending on one in a way nobody wrote down is not.

CDN, WAF and DDoS protection at the front, on a platform the organization has approved. This is where most traffic should be answered and most hostile traffic should stop.

Distribution across application instances, with health checks that know what a healthy Drupal response actually looks like.

PHP, the web server and the Drupal codebase, deployed as an artifact rather than assembled in place.

Development, staging and production built from the same definitions, so what passes in staging is a real rehearsal of production.

Database, file storage, search and cache. The parts that hold state, and therefore the parts that decide what recovery means.

Identity, secrets, certificates, logging and the path by which security events reach the people who watch them.

Metrics, logs, traces, synthetic checks and alerting, covering infrastructure and application together.

Backup, retention, restore rehearsal and a documented recovery procedure with owners.

The pipelines, provisioning and lifecycle tooling that make every layer above repeatable.

Source control, pull requests, build, test, security gates, artifacts, approvals, release promotion, deployment orchestration and rollback. Microsoft describes Azure Pipelines as combining continuous integration, continuous testing and continuous delivery to automatically build, test, and deploy code projects to any destination. That last phrase is the one that matters here: the delivery plane does not have to come from the same vendor as the target cloud.

HashiCorp describes Terraform as an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. It is how networking, compute, database, storage, security and backup resources come to exist, repeatably, in an account the organization owns.

Drush describes itself as a command line shell and Unix scripting interface for Drupal. It performs the operations only Drupal can perform. Its own deploy command standardizes how Drupal deployments work by running database updates, configuration import, cache rebuild and deployment hooks in a defined order.

Infrastructure as Code, held by the organization, applied through a pipeline rather than by hand.

A pipeline that builds an immutable artifact once and promotes that same artifact through every environment, and that can create and tear down environments from the same definitions used for production.

Drush and scripted operations for updates, configuration import, cache and maintenance, able to act across a whole estate and report what succeeded.

Cloud native metrics plus open observability covering the application, and a catalog that exposes approved actions to delivery teams without granting infrastructure access.

Automated backup, defined retention, and restore rehearsed on a schedule rather than assumed.

Identity, secrets, WAF, centralized logging, a route into security monitoring, and somebody accountable for the platform on an ordinary Tuesday and on a bad Sunday.

Inventory what actually exists, which is reliably not what the documentation says, then score each site on version, custom code, data volume, integrations, authentication, traffic, criticality and technical debt. The result drives sequence, test depth, rollback requirements and acceptance criteria.

Design the target once for the whole estate, including the cases the first pilot will not exercise, and stand it up from Infrastructure as Code so the environment is reproducible before any site depends on it.

Build the pipelines, the migration tooling and the validation before the volume arrives, not during it. This is what makes the second site cheaper than the first.

Move representative sites, chosen because they are representative rather than because they are easy.

Group by complexity and risk so each wave teaches the next, with functional, security, performance and content checks run the same way every time against a defined pass mark.

Watch the moved sites under real traffic before calling them done, then hand over to a named operating model with monitoring, support and a patching cadence already running.

Dependency and configuration validation, coding standards and static analysis run on the pull request, where a finding is cheap to act on.

Software composition analysis of the dependency tree. OWASP describes Dependency-Check as a tool suite that identifies project dependencies and checks whether any have known, publicly disclosed vulnerabilities.

A machine readable inventory of what shipped, and evidence of how it was built. CycloneDX describes itself as a modular and extensible framework designed to represent a broad range of supply chain information; SLSA is organized into a series of levels that provide increasing supply chain security guarantees.

Runtime testing against a staging environment that resembles production closely enough for the result to mean something, then a deliberate human decision before production. In Azure DevOps a pipeline is made up of stages, and control over whether a stage runs is exercised through approvals and checks.

WAF, DDoS protection, TLS, single sign on, multi-factor authentication, role based access, least privilege, managed secrets and platform hardening.

Application, infrastructure and security events collected where they can be correlated and retained, and routed to whatever the organization uses for security monitoring.

Infrastructure metrics and application metrics together, including Drupal health, PHP, database, cache and load balancer behavior. OpenTelemetry is a useful vendor neutral way to generate and export that telemetry, and it is worth being clear that OpenTelemetry is not an observability backend itself.

Thresholds that page a named person, tied to a runbook that says what to look at first. An alert nobody owns is a log line with ambition.

Checks that exercise the journeys that matter, from outside, so a site that is technically up but functionally broken is noticed by a machine rather than a visitor.

NIST defines the recovery point objective as the point in time, prior to a disruption or system outage, to which data must be recovered, and the recovery time objective in terms of the maximum amount of time a resource can remain unavailable. Both are decisions, and both should be written down.

A backup that has never been restored is a hypothesis. Rehearsal on a schedule is what turns it into a capability.

A portal or catalog can expose provisioning, deployment, backup, restore and status to delivery teams without granting infrastructure access. Backstage is one way to build it and is not required.