Cloud is to the IT department as big consulting companies are to HR.

And mainstream news will be either "company X offline for hours" if its just you, or "Amazon cloud outage takes multiple companies off line for hours" - the latter is better.

Average person hears on the news that company X or cloud Y had an outage, at most they have some anger towards the company for a day or so until the next thing in the news cycle comes along.

Switches are easy and cheap to put in a fail-over config. DB's are also running atleast in a primary / standby config everywhere. Besides if your running a single DB instance in a cloud VM the same thing can happen.

And don't get me started on the trouble you can get in with for example GCP SaaS PostgreSQL...

While I do look back with nostalgia on the days of editing files in Notepad++, FTPing them to a live server, then quickly switching to my browser to refresh the page and make sure it works...

Those days are in the past for a reason. No, git is not "fancy FTP". Yes, version control really does add much-needed structure to collaborative projects and change tracking.

You can still run a small business web server on a colocated server and FTP files to it if you want. You just won't find any modern engineers who want to touch that with a 10ft pole. The world has moved forward since then, and for good reason.

If you just add local machine testing, and a test server to that mix, what is the problem?

I was specifically referencing an old fad (might still be a thing but I haven't run into it in years) where production is a remote and a dev pushes their main branch to it to deploy. Yes, version control is amazing and it was something I used a bunch before my hiatus, but back then, it was usually SVN IIRC.

I think you're clinging a bit too heavily to the "good old days". It's ironic how this entire thread has turned into a mix of people either

1) complaining that modern technology is too complex and complicated

or

2) complaining that modern job applicants have lost the skills necessary to run things

There is much I love about today and I look forward to the future. I was just stating my observations. And yes, `git deploy prod` is a fancy FTP, but probably even worse than FTP if the build actually happens on the production server (which is something I saw more than once) and causes a production outage (also saw more than once).

Complexity is not a virtue. It is a dangerous resilience anti-pattern and should not be lionised.

Unless you're insinuating that things in fact remain simple but the complaints of complexity are down to the stupidity of commenters.

Its only innovative in an 'Apple released it and now everyone is on the bandwagon' way.

I've worked at companies that were using CVS for config file management in the 90s, the concept was already in play, it just wasn't as mainstream and didn't have a trendy infrastructure as code branding.

Good reasons for some people. But it turned out that those reasons (which you avoid explicating) were not so good for some people after all. Methods upon which you now "look back with nostalgia" had value which endures, namely control, simplicity, low cost at small scale, and a basis in standardised, accessible knowledge. These things are not valued much any more, but it's my opinion (and of others) that is a mistake.

I lived through part of that transition - I'll try and explicate through my own experiences.

The biggest thing automated deployments solved was human error. No more "oops, you forgot to FTP the JPEGs in binary mode" or "accidentally unploaded into a nested www/www folder". The transition was initially to tools like Ansible and Fabric which automated the transfer steps but had to be triggered manually. This also saved me a lot of time and pain.

However, this still left a gap where it was still possible to push broken code into production, so Continuous Integration (and/or Continuous Deployment) became fashionable. The benefits of these were you'd never push code that fails tests to production, the depth and breadth of tests being left up to you.

Incidentally, these developments coincided with my working with ever growing team sizes. There's no way I could have worked with 5 people with everyone S/FTP'ng stuff to prod. Neither would have Fabric + git been sufficient for four 5-engineer team working on the same software product. That's yet another benefit of the new way of doing things: it scales.

I think the additional benefits of checking-in your configuration and deployment steps into a version control system are self-evident.

Modern IT is swapped with CYA / No Accountablity

Cloud is not the only area this presents itself, everyone is more concerns about not being blamed for an issue than they are with resolving the issue. The more vendors you can point the blame to the better in their eyes...

AWS has never gone down across all regions at once. So we can do something about going down. You build the system to be multi-region and be able to evacuate traffic from one region to another, so when us-east-1 goes down again, you simply route around the damage and use resources in us-west2 until us-east-1 comes back up. People don't appreciate how much backend engineering goes into keeping something like Twitter up at all times.

Put it another way. Little guys go down when us-east-1 goes down. The big boys stay up no matter what.

Look back at all the big AWS outages of recent memory. Tons of the so-called big boys were down for the day along with AWS.

I still recall last year's AWS LSE when AWS went down globally, due to us-east-1

https://www.datacenterdynamics.com/en/news/aws-us-east-1-out...