Devenv: Compose a Developer Environment Easily for PHP with Nix
shyim.me
shyim.me
If I want a PHP environment I'd launch a VPS or virtual machine and set one up manually with a few standard shell commands. That way I'm working with the actual technologies themselves and am learning how they work directly instead of forcing myself to learn the syntax and commands of several unrelated technologies (yarn, docker, nix, etc.) which are just wrappers for the "real" setup.
These abstractions are usually far less flexible and more restrictive than just setting up the services yourself, anyway.
How is going through all of that worth the considerable extra time, effort, and mental energy than just - you know - setting up the services themselves?
A single command `yum install httpd php8 mariadb` will get you a working local server stack with very little extra configuration.
This wouldn't be useful for starting up a new PHP project. Instead, it'd be great for situations where you've got a dozen different projects that you work on every few months to a year, all with different dependencies and settings, services (dbs, kv stores, whatever), env vars, and so on.
I've definitely spent a few hours, when going back to a project after a few months, just trying to remember exactly what the environmental assumptions and requirements are. Being able to just pop straight back into development without any of that is amazing.
Having to do the infra-as-code of a system that didn't have it and is already live is a royal pain. If you foresee you will end up having any level of complexity, you actually save time doing it from the beginning. It's just a way of avoiding tech debt down the line.
Which could vary from "very easy" to "does anyone know who put this file there, and why, 9 months ago?".
A few years back I built a fairly simple little python/flask app to solve and integration problem. It's been sitting there handling 5000 or so requests an hour. Nothing major. I set up an ansible script which pushed out the distro (Debian) provided flask and other deps and fired it up in uwsgi. There was about 200 lines of python and about 50 lines of ansible config for it over our base image. This was pushed out to a t2.tiny instance in AWS which was behind an nginx instance on a t2.small instance which was already doing ancillary crap. To deploy this, you literally had to "aws sso login" then "make" and it was done. I added a simple AWS CloudWatch canary to check it was alive still.
Along comes someone and rewrites it using docker because, well you know this has to go in the Kubernetes stack (bollocks it does - there is no ROI for changing it). So after a week of "devops engineering time" which consists of getting it running in a container, setting up the kubernetes manifests, setting up a github pipeline etc etc. So I look at this later and we burned $4500 dev time on it and increased the yearly spend, as it needs a multi-region redundant ALB and node push to EKS to $2250 from the RI cost of $220 a year.
That's progress apparently.
I'm going to buy a canal boat and forget this industry exists ASAP.
We have a lot of users (devs, designers, qa) which don't care about their local setup. Installed anything using a random tutorial and never change a running system. Last weeks, we just updated our node constraint from 16 to 18 and many users were lost to install the right version (only ~18 was allowed). So it's for us a huge benefit to be able to declare the environment and share it to all users who don't care about their setup and just wants to do their work :). I hope you got my point :)
One effort saved is the ability to scale up/down.
Another effort saved is source of truth / documentive. When you've got the infrastructure recorded "as code", then you don't have to worry about knowledge being lost if the devops engineer leaves. (You don't have to worry if the devops engineer made changes no one knows about).
The tools might not be valuable for all cases, sure; e.g. if you're always going to remember what changes you made, and it's just your server.
As soon as you have more than one project, some running on php 7 and some on php 8 for example you will end up with a big headache if you are not careful!
Thats why people use stuff like vagrant, docker, valet, etc to run their php apps in their own sandbox so to speak.
Did you document all those things?
Ok, great, you documented them! How are you sure your documentation is correct?
Ansible is executable documentation of the above. Need to replicate the setup because your old OS is going EOL? Run the playbook. Want to make sure that when EOL time comes that your documentation is correct? Set up a test box and run the playbook. Did your machine fall over and you need to get back up in business? Did a security vulnerability compromise your machine? Set up a new machine and run the playbook.
These tools provide significant value to many of us. I, for example, burn down half of our dev and staging environment every night, as long as the other half is healthy, and spin up machines from a base OS image. If our data center falls over, I have a pretty high confidence that I can bring up the bulk of our machines from a base OS image and a git repo, plus a handful of other artifacts.
In a company where you have some 5+ languages with even more frameworks, various package managers, multiple data stores, etc. you're really going to be spending a lot of time just running individual commands to set up, e.g.:
PHP 8.0, php-fpm NodeJS, pnpm, redis, memcached, Nginx, Elasticsearch.
In total you would have probably run or configured some hundred or more commands/LOCs yourself.
You run an update and all of a sudden you're PHP service is inaccessible. What now? This happens. But automated setups typically cover this scenario already so it's just working post-update, or provide means of debugging and resolving the issue.
Having some projects in the team where automation is not that great and even some where it's only halfway there, I've seen developers literally lose a full day or more just because of a system.
The same thing can happen with Docker Desktop - where something like Nix which declaratively documents and defines native system resources is a significant improvement over the current Docker status quo.
Edit
A development environment will be different than the production environment. The loads of available tooling for dev environments reflects different challenges that different devs face.
I agree that simple is best though.
I never liked “run your dev env in docker” as it’s quite slow. So in practice you end up with two sets of build envs, assuming you support local development.
Reducing that time can save money and improve the handling of versions between projects and developers.
Surely, if your just a solo dev on a closed source project. The benefits are minimal.
Previously, I think Nix was more of a benefit for the operations (who benefit from "make deployments where the programs run with the same behaviour). Though, I think Docker containers have already eaten that space.
Since Nix Flakes, most of the attention I've seen has been using Nix for developer setups.. where there really isn't much which does what Nix does. (VSCode's devcontainers / GitHub CodeSpaces don't seem to get a lot of attention).
DevEnv seems excellent for developer setups. I'm not sure the devenv services will be able to compellingly replace docker-compose setups. But, for nix-empowered developers, the tool looks really neat.