Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
That's one definition of monitoring, but certainly not the only one, and whether or not you came up with it yourself, it's the definition you've personally adopted. Just using higher-level aggregates doesn't make it not monitoring. I didn't suggest that you shouldn't be triggering alerts based on thresholds for any of the metrics I listed; by the definition you linked, triggering alerts is the defining quality of monitoring.
If a single node is acting up, it should be automatically terminated and replaced, so I don't need to know about it. Monitoring instance-level metrics for auto-scaling is done by the scaling controller, not by the IT monitoring system.
If you're using auto-scaling, all of the listed metrics are useless for monitoring in the majority of cases on a per-instance basis. I don't care what the CPU usage of any one instance is, because if load is high enough, instances will be added, and if it's low enough, instances will be terminated. Monitoring is very situational.
This may not fit your personal definition of monitoring, but it's definitely monitoring, and it's the level of data that's important for managing infrastructure and services in an auto-scaling environment.
Did they remove the basic web UI from Chef OSS? It's there in v11, just not as full-featured as the one in enterprise. I'm not saying it's necessary, I'm saying the LoE for the additional security is next to nothing, there's no reason not to be more secure. I don't see why anyone would advise against free extra security.
SSL prevents eavesdropping/MITM attacks but does not provide any security against DDoS, brute force attack of the password-based web login, etc. And generally speaking, if you don't need to expose your central infrastructure management system to the entire world, you shouldn't. It certainly doesn't hurt to maintain simple best practices of least privilege and minimal attack surface.
It's also a good idea to either a) IP restrict public internet access to your Chef server to your on-prem IP(s), or b) use a VPN connection to Azure to join on-prem to cloud and access it using private IPs.
Yes, but the impacts also vary greatly over time, between teams, between projects, and between companies, making the result of any measurement or study outside your own specific situation of limited value.
Never rollback? That's insane. Let's say a change gets deployed to prod, revealing an environment-specific flaw not exposed during testing. Total service outage, fix will take hours. Anyone voting to let production rot while a fix is developed, rather than just rolling back, should be barred from IT.
