I was on my commute today at around 6:00am, and someone had road rage, then took it out on someone else who also got road rage, and then I got that same road rage from dealing with all of it.

I’ll calm down eventually, but I know that my readers want to access the HOOK_drupal() in this screed. (See what I did there?)

I was recently in a job interview for a Drupal Dev-Ops role and I was fortunate enough to be interviewed by another Drupaler. They wanted to know how I felt about DDev and Docker as the prefered way to develop Drupal applications for use in the US Public Sector.

I can’t lie, when they asked the question I was conflicted. Toe the Drupal party-line, or tell the truth?
My existential traffic-jam ended in less than a second and I gave an overview of Drupal application security, and why I teach LAMP the way I do.

The internet environment is changing in a volatile and mercurial way. For the last decade, most of us have noticed an annual redoubling of malicious activity directed towards web based interfaces. API’s, websites, CDN’s, and code repositories are all in the headlights of bad actors.

I’m not going to debate the effacacy of Docker. It’s a tool that in my opinion is over-valued.

Drupal does not seem to endorse any other training vector for enterprise level Drupal developers that I am aware of, and it really makes my typing break the speed limit, and my radiator boil.

In my opinion, we are screaming towards the destination without paying attention to the road ahead.

Webserver tuning is usually outside the purview of most server administrators. Their responsibility is making sure that server software is properly installed and updated, and running well. A loose analogy would be that the web techs drive the car and the server admins are the pit crew. Generally speaking.

It is not in anyones best interest to subscribe to the belief that the webserver of a Drupal web site is anyone elses vehicle to steer but the Drupal developers. All developers must strive to internalize fully the capabilities of their webservers to make their applications secure and robust against external threats. It’s imperative that we developers think of the whole stack as the application, not just our codebases.

The 7 layer OSI model of our internet is a good way to understand this Drupal gridlock. What Docker and DDev do is simulate the “Presentation Layer” and “Session Layer” of the LAMP stack, ostensibly to allow Drupal developers to concentrate on the Application Layer.

Students of Drupal need more training in application security, not less. Many settings and configs that are critical to making an application secure are found in the presentation and session layers. In the same way a driver knows not to grind the gears or drop the clutch, a Drupal dev should know LAMP. (All the LAMP not just the “P”).

The reason why one would use Docker and DDev is to circumvent the developers involvement in the webserver and database servers configuration and tuning. When it comes to building out complex Drupal applications in the Public Sector where security restrictions are vastly more draconian, devs should be deeply trained in LAMP to ensure the success of any Drupal based application.

I know not every driver out there knows how to change their own timing belt, but I would bet that every driver out there knows that the engine is important and moreover, how an engine problem is experienced and handled.

Fellow Drupal Developers, let’s all ask ourselves; “Do we want to understand the engine, or just drive the car”?

I am all for blowing your own horn, but I think that without investing more in training the developers that are driving the metaphorical car, it will soon be heading for a bad crash, without a seatbelt.

I’ll get back in my lane now.
Beep! Beep!