From Varnish and Drupal Tuning to Platform Engineering
- Shameem Abdul Salam
- Meta , Dev ops
- July 10, 2026
Table of Contents
In 2013 I wrote about Varnish in front of Drupal and where Drupal sites actually lose performance. The stack was Apache, PHP, MySQL, SSH, and a lot of hand-tuning. Today I work on AWS Batch, multi-region Terraform, and hybrid lab-to-cloud integrations in life sciences. The logos changed; the job did not.
Platform engineering is still making reliable systems other people can run without heroics—just with different failure modes.
The old stack
Support engineering in the LAMP era meant:
- Caching layers — Varnish, opcode caches, CDN edges. Same question as today: what is safe to cache, and for how long?
- Bot and traffic spikes — Magento launches, Drupal editorial traffic, crawlers hammering uncached paths.
- Health and visibility — “Is it up?” meant HTTP checks and tailing logs on a server—not yet a unified observability stack.
- Performance as detective work — traceroute, slow query logs,
top, and arguing about last-mile latency before blaming the app.
I was not a “platform engineer” on paper. I was a sysadmin and infrastructure engineer who owned the path from browser to database and got paged when that path broke.
What still applies
Read any of the platform-notes checklists published here—ECS deploys, Terraform layout, Logs Insights, Batch—and you will see the same instincts:
| Then (web ops) | Now (cloud platform) |
|---|---|
| Varnish cache invalidation | ALB stickiness, CDN, app-level cache keys |
| “Did we deploy?” | Immutable image tags + services-stable |
| Drupal module killed perf | Sidecar memory limits, wrong Batch vCPU sizing |
| SSH and edit config | IaC + pipeline-owned task definitions |
| “Works on my VM” | Dev/staging/prod drift in tfvars |
Caching, health checks, and “where does the time go?” never went away. The control plane moved from /etc/httpd to AWS APIs.
What changed
Three shifts matter more than the buzzwords:
- Containers and immutable artifacts — You ship an image, not a rsync’d tree. Rollback is a tag, not a backup tarball—if you pinned the tag.
- Infrastructure as code — Networks, IAM, and batch queues are versioned like application code. Mistakes scale faster; so do fixes.
- Managed services and boundaries — You own fewer kernels, more integration contracts: KMS key policies, security group rules, Batch job roles vs execution roles.
CI/CD replaced most SSH—but someone still has to design the pipeline and the failure behavior. That someone is the platform role.
From web ops to scientific platforms
E-commerce and SaaS taught me multi-tenant hosting, CI/CD, and cost-aware scaling. Life sciences added harder constraints:
- Batch-shaped work — Pipelines run, finish, and leave artifacts in S3—not steady HTTP RPS.
- Data gravity — Reference genomes, instrument output, and regulated data do not belong in a generic “app server.”
- Encryption everywhere — S3
GetObjectis not enough when SSE-KMS is on; IAM and key policy must agree. - Audit and repeatability — “We ran it manually once” is not a platform; job definitions, Terraform, and logs are.
That is why AWS Batch on EC2 fits the same blog series as GitHub Actions to ECS. Different scheduler, same discipline: network path, IAM, observability, immutable deploys.
Platform engineering vs. hero ops
Hero ops is the senior engineer who knows which server to restart. Platform engineering is the checklist, module, and pipeline so the restart is rare—and when something fails, the logs and runbooks are obvious.
I still respect deep troubleshooting. I just want it to be the exception, not the business model. The posts on this site are deliberately checklists you can hand to a teammate because that is how platforms earn trust in production.
Why I still write about Linux—and old Drupal posts
Foundations matter. cgroups, file descriptors, DNS, TLS, and NFS behavior show up in Batch jobs and ECS tasks the same way they showed up behind Varnish. Keeping the older Linux and Drupal articles on shameem.in is intentional: they are reference, not resume padding.
If you read one 2013 caching post and one 2026 pipeline checklist side by side, the through-line is faster to see than any “platform engineering manifesto.”
Where the series goes from here
The practical posts cover deploy → IaC → observe → batch. This essay is the capstone—not a replacement for them. If you are building similar systems, start with the checklists; come back here when you want the narrative thread.
More writing will follow on hybrid lab-to-cloud, Terraform in regulated environments, and operational patterns I use at CENTOGENE—same voice, same “hand this to a teammate” goal.
If you only do one thing: read one old ops post and one new pipeline post side by side—you will spot the through-line faster than any manifesto.
