I've used docker for process isolation at two companies now. In both cases, we were executing things on the server based on customer input values, and desired the isolation to help ensure safety.
In the first company, these were one-off import jobs that would import customer information from a URL they provided.
In the other, these are long-running daemons for a multi-tenant service, and I need to reduce the risk that one customer could exploit the system and disrupt the other customers or gain access to their data.
I have some other experiments in play right now in which I am packaging up various services as docker containers, but this is currently non-production.
I was involved with a company that received several attacks on AWS. We were premium support customers, and were able to work with our AWS TAM to get a mitigation device in place and turned on. It was a bit shaky at that time, as this was not a common service offering. Things may be better now.
FWIW, offering SSL is a giant pita considering that it requires a unique IP address for each endpoint. Scaling that is not easy. Add the diminishing pool of IP4 space to that and you've got something that you have to think very carefully about.
I love PagerDuty, and it has already paid for itself many times over. The fact that it will phone my house if I miss the text messages has been a big win over AT&T's lousy coverage in my area.
It's also worth pointing out that this might have been more of a failure of EBS (elastic block storage, an abstraction over S3) than with native S3 buckets.
Ultimately, my EBS device become unusable by any operating system, and Amazon support stated that the data was lost due to several backend systems failing.
You should certainly backup your data. While the engineers at Amazon are certainly among the smartest, they are not infallible. Things do fail from time to time.
I lost 1TB of data several months ago due to some backend issues with EBS and S3. Fortunately for me, it was just a backup of a backup of a backup. ;-)
The company that I work for and those that I have worked for in the past would never reject an application because it was written in .NET. We would only reject an application that did not fit our needs.
I think you are right to stick with what you know.
Well, I'd like to believe that, but Dreamhost has had Ruby support for quite some time. I figured they're about the biggest of the shared hosting providers.
Maybe the new cPanel will make it even easier, though...
In the first company, these were one-off import jobs that would import customer information from a URL they provided.
In the other, these are long-running daemons for a multi-tenant service, and I need to reduce the risk that one customer could exploit the system and disrupt the other customers or gain access to their data.
I have some other experiments in play right now in which I am packaging up various services as docker containers, but this is currently non-production.