We use Vagrant because it is the best toolchain for having a standardized development environment that is readily provisoned with just a single command on macOS, Linux, and Windows.
There's a lot of things that could be better; the thing I dislike the most is how Vagrant configuration file is a Ruby script with weird semantics around conditionals, which makes it its own special language to learn. They would have been a lot better off with the configuration approach taken by Xen (where the configuration file was a straightforward Python system).
Also, it's error messages are optimized too much for people developing Vagrant itself, and not enough for helping end users who are using Vagrant, which means one has to google often to figure out what the actual problem is.
Still, I don't think there's a better alternative for a development environment that Just Works for hundreds of developers. Docker isn't really designed for the development environment use case in my view, since it's optimized for throwing away state and getting a clean one when you make changes, and that's sometimes really not what you want. And having to SSH into a remote development environment has significant latency and editor setup costs that in my view make it a backup plan, not the main way to do things.
We use collectd because of it's low footprint and great capabilities. We use it to monitor our Google Compute Engine machines. More interestingly we setup collectd as StatsD replacement - all our Clojure services push application-level metrics using our own metrics library and collectd pushes them to Stackdriver
We use Terraform because we needed a way to automate the process of building and deploying feature branches. We wanted to hide the complexity such that when a dev creates a PR, it triggers a build and deployment without the dev having to worry about any of the 'plumbing' going on behind the scenes. Terraform allows us to automate the process of provisioning DNS records, Amazon S3 buckets, Amazon EC2 instances and AWS Elastic Load Balancing (ELB)'s. It also makes it easy to tear it all down when finished. We also like that it supports multiple clouds, which is why we chose to use it over AWS CloudFormation.
We build a Slack app using the Bolt framework from slack https://api.slack.com/tools/bolt, a Node.js express app. It allows us to easily implement some administration features so we can easily communicate with our backend services, and we don't have to develop any frontend app since Slack block kit will do this for us. It can act as a Chatbot or handle message actions and custom slack flows for our employees.
This app is deployed as a microservice on Amazon EC2 Container Service with AWS Fargate. It uses very little memory (and money) and can communicate easily with our backend services. Slack is connected to this app through a ALB ( AWS Elastic Load Balancing (ELB) )
Considering myself an 80%/20% full-stack, my time using Node.js at the backend is limited. This is why I have started using Firebase as the back for most of my personal applications. The amount of tools and resources is amazing and covers the most common needs like #authentication, storage, database, real-time database, actions, and hosting. It's a total grown-up product and the free tier is enough for most of my personal projects.