Honestly I've yet to be convinced of the value of having to learn to use all these extra tools which supposedly make devops "easier".
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.
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.
The thing is "yum install httpd php8 mariadb" will NOT get you a working local server stack, the extra configuration is super, duper important. Are you documenting the extra configuration? What modules have you a2enmod'ed, what configs did you put in place, what permissions did they have, what firewall rules and selinux grants? What PHP config values did you adjust? Kernel parameters?
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.
The self-documenting nature of these tools and the ability to get many people running quickly are both extremely valuable and I don't think OP has to deal with this issue- perhaps a smaller team or just an independent approach.
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.:
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.
In general, devops tooling makes management of cloud resources and services programmatic. You put in effort now, in order to save effort later.
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.
I agree with you, when you have the knowledge and have fun doing your local devops, you can skip such software.
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 :)
Why stop there though? You can simplify the whole build and bundling process with Nix. Remove the Composer, npm, Docker, and let it all be in one declarative language, Nix.
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.
> This wouldn't be useful for starting up a new PHP project.
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.
You've got to make sure you don't miss anything important, as well as being able to distinguish between details which are incidental, vs details which are deliberate.
Which could vary from "very easy" to "does anyone know who put this file there, and why, 9 months ago?".
I get what you're saying, but the article is talking about a development environment. I may be off, but devops is generally concerned with delivering an app to production and then keeping it alive. The development environment may not be part of this (though it could be I suppose.) To me, devops starts with code which is already in the repo. It may not be concerned with code which is on a developer's system.
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.
The nice use-case I see for Nix is: you can specify your env requirements cleanly in a way that you can install them both in MacOS (eg replacing ‘brew install Postgres’), and into a Docker container (which happens to be very slim as it doesn’t carry a full Linux distribution with it).
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.
Well yea thats all nice if you are running one single thing and one php version.
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.
It depends on the problem you're trying to solve. In some cases you have a team and you need everyone to have a reproducible environment so you can be sure that behaviors are due to code changes and not subtle differences in environment configs.
DevEnv looks like the most exciting thing to happen with Nix recently.
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.
My experience with devenv was disappointing. It claims to play well with existing tools but I ended up screwing around with arcane language-specific env cars to get a simple Python/pyenv/node setup going. It wasn’t quite so “oh just add your packages and roll” it was just like anything else “add your packages and fiddle with it til it works” and then it basically never worked. I was excited for it but it didn’t really add much value for me
This is a great guide! Took a stab at DevEnv a few weeks back after reading about it (and loving the concept). It messed with my OS host path / install locations for non-devenv packages and I found the docs to be lacking. So thanks for this great example
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.