> Ummm...no. Just no. Have you ever had to create multiple subnets, DMZs, SD-WAN setups, plus VPN access, etc. etc. with multiple locations, all with security in mind, and full redundancy across three data centers?
>> Again, if that's your use case, then we're not talking about 1 cloud engineer vs 3 non-cloud engineers.
At my company we operate a setup like this on AWS with about 8 people total (5 infra engineers and 3 security engineers, I suppose we could also count their 2 managers), and that's not even their full job.
At my company we operate something similar to that with 2 system engineers and 2 network engineers. 2 main offices and 2 separate physical COLO datacenters + lots of satellite offices and remote workers. Everything is HA and we have a DR site that is mostly unused. Everything is backed up securely (push only) and can be easily restored (database aware) extremely quickly if needed. In an absolutely worst case shit hits the fan scenariou there are automated tape backups stored offsite.
Hardware is easier, cheaper, and more reliable than ever and I rarely (system engineer) have to go out somewhere. Harddrives still occasionally fail but with a strong RAID and multiple hot spares your system will not even think about failure until you have a lot of failed drives (and even then you have a whole separate redundtant storage array to HA over to). I would estimate someone has to drive out there every 6 months on average - often less. Rarely a piece of RAM will fail. By the time I drive to the COLO the replacement drive or part is already there (the system automatically calls home and orders a replacement part from the vendor).
All of these systems are daisy chained together with multiple 40 or 100gig ethernet links so that even if a core switch goes down + multiple servers everything will keep running.
Does this take awhile inititally to setup? Yes it does. Does it take a lot of work to maintain and upgrade? Not at all.
> Does this take awhile inititally to setup? Yes it does.
This is fundamentally the difference to me. I've worked with hardware before, and if your business and load is predictable, and you understand how to architect it before going in, it's a good option. You can put in a bit of extra up-front work and get more control and lower costs.
The other issue I have ran into is that developers all have worked at a startup where they had really shitty on prem setups. As in just a bunch of devs hacking it together without much thought and no actual sysadmin or system engineer / dedicated ops people. That leaves a bad taste in peoples mouth
>> Again, if that's your use case, then we're not talking about 1 cloud engineer vs 3 non-cloud engineers.
At my company we operate a setup like this on AWS with about 8 people total (5 infra engineers and 3 security engineers, I suppose we could also count their 2 managers), and that's not even their full job.