In my former life I was a Drupal consultant and architect with Palantir.net. One of my former colleagues there, Michelle Krejci, had a saying she liked to repeat: “Production is an artifact of development.” She even presented on the topic a few times at conferences. What she was saying made sense, but I didn’t fully grok it at the time.
Now I do.
As a PHP developer of 15 years, I like many developers had gotten into the habit of deployment being a question of “put code on server, run”. That’s PHP’s sales-pitch; it’s the sales pitch of any scripting language, really. The same could be said just as easily of Python or Ruby. What is an artifact of development other than code?
Quite a lot, of course. Developers in compiled languages are used to that; source code needs to be compiled to produce something that can actually run. And as long as you have a build process to compile code, throwing other tasks in there to pre-process the source code, or generate other files, is a pretty short leap. For scripting language users, though, that is a weird concept. Isn’t the whole point of a scripting language that I don’t need to compile it?
And let’s not forget 3rd party dependencies. Any mainstream PHP project these days is built with Composer. Python uses pip, but the effect is the same. 3rd party dependencies are not part of your code base, and do not belong in your Git repository, but are pulled in externally.
On top of that, many systems today do have a PHP code generation step, too. Symfony’s Dependency Injection Container and Routing systems, Doctrine ORM’s generated classes, and various others all entail turning easy-to-edit-but-slow code into uneditable-but-fast code.
For years I’ve been largely avoiding such tools, because I worked mostly with either heavily-managed hosts that had no support for such steps (or their support was far too hard-coded) or client-hosted servers that still believed in hand-crafted artisanal server management. Short of checking the generated CSS, JS, and PHP code into my repository (which we did with Sass/CSS for years), there wasn’t much way to square the clear shift toward even scripting languages having a compile step with the 2005-era thinking of most of the servers I used.
And then I found Platform.sh.
From the very beginning, Platform.sh has been built on the “production is an artifact of development” model. Your application doesn’t consist of just your code. It’s your code, plus 3rd party code, plus your server configuration, plus some CI scripts to generate CSS, compressed JS, optimized PHP, and so forth. Platform.sh was built specifically to address that modern reality. Your git repository may only contain your code, but that gets turned into, repeatably and reliably, a set of application containers, service containers, and “output code” that will actually get run. What that process looks like is up to you and your application; it could involve Sass, or not; compiling TypeScript, or not; dumping a dependency container or routes, or not.
The compiled artifact of development isn’t just your code; in fact it’s not even an application container that includes your code. It’s the entire constellation of tools that form your application — your code, your database, your cache server, your search index, etc. That’s exactly how Platform.sh works, and why it offers far better support for modern web applications than any other managed host I’ve used. (Give it a spin.) And no, I’m not just saying that because I work here. :-)
So thank you, Michelle, for convincing me of what modern web hosting should be. And thank you Platform.sh for making it a reality.