Drupal has been a consistent leader in the Gartner Magic Quadrant for Web Content Management. However, enterprises leveraging Drupal have traditionally relied on PaaS providers for their hosting, scaling and lifecycle management. And that usually leads to enterprise applications being locked-in with a particular cloud or vendor. As container and container orchestration technologies disrupt the cloud and platform landscape, there’s a clear way to avoid this state of affairs. In this webinar, we discuss why it's important to build a cloud-native Drupal platform, and exactly how to do that. Join the webinar to understand how you can avoid vendor lock-in, and create a secure platform to manage, operate and scale your Drupal applications in a multi-cloud portable manner. Key Takeaways: - Why you need a cloud-native Drupal platform and how to build one - How to craft an idiomatic development workflow - Understanding infrastructure and cloud engineering - under the hood - Demystifying the art and science of Docker and Kubernetes: deep dive into scaling the LAMP stack - Exploring cost optimization and cloud governance - Understand portability of applications - A hands-on demo of how the platform works

1. How to Build a Cloud Native Platform
for Enterprise Drupal Applications
Pavan Keshavamurthy , Head of Enterprise Architecture, DevOps & Cloud Practice
Girish Kumar, Senior Cloud/Infrastructure Architect
#SrijanWW | @srijan

2. Introductions
Pavan K leads Srijan's Enterprise Architecture, Cloud & DevOps Practice.
His charter within Srijan is to engage customers and teams in a
consulting/advisory role, particularly around areas concerning platform
building & microservices architectures.
Girish is a Sr Cloud / Infra Architect with 10+ years of experience. He has
had prior stints an Infrastrcutre / DevOps Engineer in FiberLink (IBM), SAP
and several startups before joining Srijan.
At Srijan he leads multiple projects with a focus around cloud engineering
for various classes of workloads.

3. Enterprise Architecture
● Platform Engineering
● Cloud Engineering
● API Management
● Microservices
● Agile & DevOps
SRIJAN is a full lifecycle digital engineering firm.
We specialize in enterprise product & platform
innovation, fuelled primarily on open source & cloud
technologies.
Our customers say we run software delivery like a
hospitality business.
Digital Engagement
● Enterprise Content
Management
● Portals
● Front-end engineering
Data Science
● Analytics
● Machine Learning
● Data Engineering
● Chatbots
➔ 15+ years of profitable growth
➔ 10+ Multi-year enterprise customers
➔ Global consulting & delivery: HQ’d in
India with operations across America,
EMEA, APAC
➔ 300+ Headcount
➔ Thriving culture of Agility, Engg & Open
Source Contributions
∞

4. About this session
This session is relevant for you if
you are:
● An IT / Business stakeholder
responsible for the development and
operations of Drupal projects
● An infrastructure or cloud engineer
curious to gain a worldview around
running Drupal on the cloud
● A Drupal developer / application
engineer who loves to dabble with
things on the ops side.
● A Drupal Company / Managed Services
Org that builds (OR) maintains a number
of Drupal sites
What you will learn during this session:
● Gotchas around “running” Drupal
○ By yourself vs NOT
○ When to & when NOT to
● Def:
○ “Platform”
○ “Cloud Native”
● LAMP stack Gotchas
○ On Docker Containers
○ Kubernetes (a full refresher)
● How to build and run your own

5. Before we go ahead: A Quick recap on Drupal
● Formerly a Content Management System
○ With D8 - Evolved to a Symfony-esque Content
Management Framework”
● Amongst the most popular OSS projects in the world:
Active community of 100K+ contributors with a plugin
ecosystem of 40K+
● Powers a whole range of web applications in diverse
domains: Gov, Media/Entertainment, Education,
Publishing, Non profits Consumer Internet unto high
tech
● Mature ecosystem of service providers: Single-person
studios to SIs with whole units focussed on Drupal
development
Powering in excess of 1M sites.
> 2% of websites on the entire
internet

6. ..and Docker & Kubernetes
● Docker: De-facto standard for containers. Tiny footprint
vis-a-vis conventional VMs. Shared kernel and
separated user space
● Kubernetes: De-facto standard for container
orchestration (born at Google)
○ Containers need management = distributed
systems problem
○ Manage lifecycle of containers, distribution,
scheduling, command & control, etc
● Together: de-facto standard for cloud abstraction.
Ability to run on any cloud without binding to IaaS
primitives

7. Running Drupal
Source: Drupal runing on RPi,
https://blog.adafruit.com/2015/06/12/introducing-the-dramble-raspberry-pi-2-cluster-run
ning-drupal-8-piday-raspberrypi-raspberry_pi/
PaaS: Aka you build
it, they run it
Public Cloud IaaS:
You build it;
you also run it
Run it on your own infra: (aka eating your own
dogfood)

8. Hosting Options: Comparison
PaaS
Platform ability to provision and spawn
environments. Your teams concentrate on
building and not running
Scalability concerns are a platform issue
Security is a joint responsibility model (platform
security is PaaS responsibility, Application
Security is your responsibility)
PaaS gives you basic lifecycle management
tooling: Building and deploying is via UI or
higher level APIs
PaaS gives you run tooling: monitoring, DR,
support (along with SLAs: 99.xxx)
Usually restrictive on what you can run:
Constraints plus lock in
$$. Expensive. IaaS + nX.
IaaS
You're responsible for both building and running
Scaling up and scaling out are your problems
Security is a joint responsibility with IaaS (You're also
responsible for "security in the cloud" alongside
application security)
Build your own
You're all on your own
Run whatever you want (aka control on own destiny)
Just IaaS. Very significant cost savings at scale

9. There’s a third option
Build your own platform *.
*
➔ If you have a business case: ex, high
volume application, high traffic, polyglot
architecture etc
➔ In general, you have control or cost
requirements meritorious of building one
➔ If you already have a sizable investment in
public/private cloud and have an ops team
(even if for security governance &
compliance only) with capacity available

10. Cloud Platforms
Platform: What must one do?
A wishlist
1. Provide a layer of
abstraction above IaaS
2. Ecosystem: Deliver
agile, efficient and
effective experiences for
a. Developers
b. Operators
3. Handle cross cutting
concerns
4. Scale
5. Secure

11. Cloud Native
Cloud Native is a foundational & prescriptive
methodology towards designing and building
applications that are meant to run in the cloud.
Strongly internalises Agile, DevOps and modern,
resilient software architectures like
microservices

12. Cloud Native and Drupal: An aspirational model
➔ Drupal ideally as a containerized stack
➔ Running on LAMP/LEMP, well governed base images (host OS provisioning, container
golden images)
➔ Developers have idiomatic experience: Can build high fidelity local environments easily
➔ Minimal or No Ops: CI/CD systems do the hard work
➔ Distributed / Bucket Filesystem. Docroot is ideally immutable and read-only
➔ Public / Private Files Externalized (such as S3 or abstracted from block device - S3
fuse fs)
➔ Take advantage of PaaS services: For Databases, Cache Stores, Load Balancers,
Queues, Gateways, etc.
➔ Run on any cloud (or lift & shift with minimal overhead)
➔ Scale up, Scale out and Scale down
➔ An operational model: provisioning new applications, routing, monitoring, releases,
deployment

13. Drupal Platforming Concerns
● Logical Architecture
● Stack Topology: Physical & Security Architecture
● Local Development
● Dev & Build Tools
● CI & Delivery Pipeline
● Monitoring & Management

14. Part A: The first thing: LAMP Stack architecture
A typical LAMP stack
application architecture.
Docker provides the
additional benefit of a host
agnostic runtime and a way to
govern autonomous local
development.
High fidelity environments.
Aka what you build is what
you deploy.

15. A second step: Deeper dive into LA|E|MP
concurrency model
Apache Concurrency Model options
Nginx: Typical PHP runtime model

16. Summary
- Alignment of the right concurrency model is critical to scale
- Apache prefork for example is the easiest setup, but is notorious for resource
leakage
- Art & science HA setup involves often multiple pieces: Reverse Proxies, Reverse
Proxy Load Balancers, Process model (processes vs threads), Networking
(TCP/IP vs Unix Socket).
- KPIs: Process size in compute, I/O, network terms. Exploratory analysis with load
patterns will help you benchmark and test frontiers of stress
- Build observability into the system to ensure you application / platform is properly
instrumented and debuggable for underlying platform issues so you deal with problems
empirically

17. Part B: Physical / Virt Layer (Example: AWS)

18. Part B: Physical / Virt Layer (Example: Azure)

19. Part B: Summary
- Network & Secure Virt/Physical Architecture is a key foundational step
- Size and design your network
- For Availability
- Subnets by function (and access at such)
- Secure your network
- Almost all IaaS support some form of IAC and templating systems. CloudFormation,
ARM, Terraform etc.
- Consider a shared services network peered for concerns including monitoring /
telemetry / deployments and more
- For modern API applications with decoupled front-ends, strongly consider an ingress
service (such as an API gateway) for handling various cross cutting concerns

20. Part C: Developer Workflow: Local Development /
Build Tools

21. Part C: Summary (constituents of idiomatic
developer experience)
➔ Utilities to setup your environment: including (anonymized) databases. Time To First
Line of Code is the best heuristic of developer experience
➔ Galaxy of static code analysis tooling: Sonarqube, PHPMD, PHPCS, TaintPHP;
Eliminate garbage.
➔ IDE or Editor experience: Importantly, with debugging tooling (xdebug)
➔ Package management tooling: Composer, drush etc
➔ Drush: Important! (Drush aliases for your local environment)
➔ Check -> build -> test -> push idiom
➔ Your CI implements your local build idiom thus providing parity between what
happens locally and what happens remotely

22. Part D: CI / CD pipelines: Spinnaker

23. Deployment Models

24. Part D: Summary (CI/CD)
➔ Adopt (preferably) a GitOps style model: VCS as the single source of truth
➔ CI/CD in the context of Kubernetes. Artefacts are
◆ K8S Object Manifests (deployments, helm charts)
◆ Containers (in a registry)
➔ Separate build / bake / deploy
➔ Separate build and run (prod - non prod)
➔ You should be able to declaratively implement deployment strategies (aka, don’t engineer this
yourself - use Spinnaker, if you can)
➔ Spinnaker is not a replacement for your task runner / automation tooling: Can be complementary
to Jenkins (infact, leverages Jenkins for builds as a proxy), GitLab CI or others
➔ Mitigate risks: Have a responsible development process, but ability to rollback (hard, with
databases), rollforwards, hotfixes. Have SOPs in place including a DR strategy

25. Part E: Monitoring

26. Part E: Summary (Monitoring)
➔ Instrument your applications: Log stream telemetry. Without this, you’ll be on YOLO mode.
➔ You’ll need some form of a monitoring agent to collect log telemetry for analysis. If you can afford it, a
paid service is great: ex, NewRelic, Nagios etc. Better still, your cloud provider already provides a manged
service that can be leveraged with APIs (ex: CloudWatch, OMS etc)
➔ A network level monitor, ingress/service mesh/api gateway is a huge plus, particularly in cases where
Drupal is part of a constellation of microservices
➔ Otherwise, a standard ELK|EFK stack is useful.
➔ Cluster / Infra KPIs with Kubernetes is a breeze. Prometheus, Grafana, Sysdig, InfluxDB are standard
tooling. cAdvisor, Heapster provide advanced container level telemetry. Most of these tooling can be
deployed as services (which watch API server) OR DaemonSets (watch nodes directly)
➔ Prometheus provides an excellent AlertManager; SysDig provides advanced tooling like behavioural
analysis (Falco)
➔ Overall galaxy of monitoring tooling is vast. Awareness of key risks, KPIs and a strong operational model
(tailored for your needs) is necessary. This intersects people & process concerns as well

27. <DEMO>

28. </>
Questions?
(Srijan also provides consulting,
advisory and implementation
services for Drupal and other
platforming concerns)

29. Contact Us
Know More
www.srijan.net
business@srijan.net