Hacker News Reader

> Handling everything from server procurement to FTPing the files to the server and even server maintenance. When I got back, this was "a big no-no" and mostly frowned upon. Everything was deployed by "git push" (fancy FTP?),

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.

> No, git is not "fancy FTP"

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.

Using source control tools as part of the deploy process really is a valuable innovation. It's not an "old fad".

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

> complex and complicated

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.

That's an interesting take. But nah, I like some things the way they are now vs. back then. I love having cheap/easy CI that deploys to prod for me. I love having IDEs that are actually geared towards whatever language I'm writing in this year. I love having access to cheaper coloc space because most people aren't using it. I love having skills that most people don't even bother learning anymore when digging into performance issues. ...

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).

> Using source control tools as part of the deploy process really is a valuable innovation. It's not an "old fad".

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.

> and for good reason.

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.

> But it turned out that those reasons (which you avoid explicating) were not so good for some people after all.

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.

> 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...

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

The key to this is: which is worse for middle management; a 15 minute outage which is your fault, or a 2 hour outage you can blame on AWS?

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

Except realistically AWS is down maybe 2 hours a year and if you blow an on-prem switch with no configuration backup or a database server hard crashes while syncing its backup, you might be down days.

> if you blow an on-prem switch with no configuration backup or a database server hard crashes while syncing its backup, you might be down days.

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...

In a former life (before clouds) we had a SAN go down because of a backplane problem. It was down for days while being diagnosed/fixed and then in read-only mode for another couple of days while the disks were in repair mode. I know people say things like "you should have a backup device" or "switches are cheap" but sometimes it IS the backup system that goes down and sometimes that system is VERY expensive.

I learned recently that the customers kick you in the balls once per minute either way. Loudly on Twitter.

Your average person doesn't listen to twitter, they listen to the mainstream news.

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.

That’s not true in our sector. We’re very industry specific and everyone shitposts on twitter and follows everyone else.

Your sector != average person.

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.

In my experience, an average person seeing that one of their commonly-used tools is down due to a big tech company failure is just going to proclaim "snow day!" and not really mind at all.

Depends if it gets in the way of them making commission or money.

>>That last sentence was something you never said to a boss back in '07-08.

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...

Not really IT's fault. Mainly management always wanting a neck to choke.

AWS going down is in no way dissimilar to L3 going down back in the day. You were still down and there was not much you could do about it.

> it's ok, everyone else is down too and we have no idea when it will be back.

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.

> 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.

Yeah, that was embarrassing. Point is, AWS being down isn't cause to sit around and do nothing but instead, work on how to make things more nesilient.

> AWS has never gone down across all regions at once.

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...