Learning Ansible is not easier than dragging and dropping a file onto a server and having it run with no extra work.
They weren't saying it was hard but that it is not as easy as PHP. PHP is one level up from a static site for most beginners, you can simply drag and drop a file on many shared web hosts and get going. That is the attraction.
That's was the attraction. I guess it still is for very simple web apps that one person can build. It's been a while since I've worked on anything like that. It's probably been a few years since I've even signed up for any service like that. The web has moved on to building more scalable things.
If you're writing something moderately complex then you're very likely to be running it on a virtual instance (maybe more than one) on AWS/Digital Ocean/etc, and if that's the case then you'll go much faster if you have a testable, reproducible build process that your development team can tear down and build back up easily. That is much more complicated than FTP'ing a few scripts to a server and importing a SQL script with PHPMyAdmin, but at the same time, as soon as your service hits a few thousand users with hundreds of them accessing it concurrently, your PHP script FTP'd to a shared server probably isn't going to work very well.
Learning new things is not a reason to avoid moving forwards. If anything, it's why I got in to web dev in the first place. New things are what make it interesting. I don't learn all of them, and I don't switch tools very often, but sometimes something comes along that makes life better. Reproducible builds with Ansible/Puppet/Chef/etc is one of those things.
>That's was the attraction. I guess it still is for very simple web apps that one person can build.
It's better to insist on simplicity at every level, whether you're building "simple one-person web apps" or "complex large-team" ones. In fact simplicity at every level would be even more beneficial in the latter case.
So I find this "dead easy deploy is only beneficial for small apps" dichotomy false.
It's a great deal simpler to have a process that runs when code is merged in to a repo than to have a manual process of copying files to a server that relies on a human getting things right. "Dead easy to deploy" these days means "create a process that can run automatically, that checks things worked correctly, and rolls back changes if things go wrong". Doing those things manually is not simple.
If a deploy fails and a client is panicking because their app isn't available, the last thing you want is a team of stressed developers trying to work out which files they need to revert.
>It's a great deal simpler to have a process that runs when code is merged in to a repo than to have a manual process of copying files to a server that relies on a human getting things right.
Who said it's has to be either one or the other?
The "manual process of copying files to a server" can be done simply by a person for a small scale project, and it also can be automated any way one likes -- e.g. to "automatic copy files to a server when code is merged in to a repo".
"Copy a file to a directory and the server just works and shows it" doesn't imply manual ftp uploading or manual editing of any kind -- it's just so flexible and easy that can it work that way too.
And if anything breaks, it's still simpler to find out what went wrong -- as opposed to some convoluted server deployment process with more moving parts.
They weren't saying it was hard but that it is not as easy as PHP. PHP is one level up from a static site for most beginners, you can simply drag and drop a file on many shared web hosts and get going. That is the attraction.