Hi
I've just changed my job, and IT at the new company doesn't allow R for security reason. They "do not like the fact that a) it’s a development tool and b), it also requires .NET to run as a prerequisite (another IDE)..." . Any argument against these will be very much appreciated.
Zahra
If you need it to do your job it's their job to make it work for you. IT is a service, so if there is a reasonable/business need to have something on your computer, they should find a way to put it there, not find excuses to avoid.
Also, what does a) means?
8 Likes
You might ask for a source for this claim. RStudio does not require .NET (or use it in any way).
4 Likes
I agree with the "development tool" ambiguity. I've heard a lot of reasons for IT not wanting to support R. Usually it boils down to IT not knowing it and don't want to spend time learning it. I know that's a pretty harsh statement but that's been my personal experience. This "development tool" reason is a new one for me.
If it's an R Studio issue, then you can use most generic IDEs to code R and run R in terminal or the default GUI (the pre-R-Studio days).
If it's an R issue, then you may have to go over their heads. Some talking points.
- hrs needed to redo all your work in their acceptable language
- hrs needed to retrain or learn a new tool
- successful deployments by large enterprises using R
- as @mishabalyasin, the ability to do your job. they were aware of your skills before hiring.
I doubt this will work for IT but executives will probably be more receptive to these points.
Getting more details about security issue will help. They'll probably be annoyed but you need to understand their specific reasons. Their current reasons are ambiguous for part a) and wrong for part b). Some common specific reasons I've heard in the past.
- R has no LTS, like Node.js
- Packages are not vetted
- Find me docker/chef/puppet scripts to deploy R and install packages for me
- dependency management is not as clean as python or Node
Sometimes there's a misunderstanding of what you are trying to do with R. Many people imagine outward-facing apps built entirely in R so that R is doing all the web traffic and data roles. In this case, there aren't as many tools in the R community to do this securely. However, rarely would a data scientist create that in R. Most likely they'll be creating something only available internally with nothing outward-facing. you can use a Node/express of Python/flask to handle the web security stuff and call an R internal service.
6 Likes
You might find this article interesting:
There are others in the RViews "R for Enterprise" series. You are not alone!
While @Ixy009 makes a good point, we actually see lots of companies run R in production as well (even for external facing web apps!). It is typically a communication, knowledge, or process issue, not a technical one.
3 Likes
I completely agree with R being production ready. It's not only doable, there's only small differences between deploying apps in R vs. python, node, php, etc. I've seen it and done it for very large companies.
But there are other times where you get really stubborn people who just don't want to try out a new ecosystem. Sometimes I've been successful in convincing and sometimes I had no luck.
I can summarize the factors that helped in one instance.
a) Made sure I had a really great working demo. Showing is a lot better than telling. Something they can play with themselves.
b) Willingness to take more DevOps and SWE responsibilities. I learned about deployment, monitoring, and dependency management and showing how R can be done just like python.
c) Had executive support that can "overrule" IT skepticism. I also had a lot of support from product.
It's not a fool proof formula. Tried the same thing at another shop but the executives always deferred to the IT architects.
1 Like
Thanks Misha for the response. As for the meaning of part a), I think they are afraid I will develop something to harm the organization?? I'm going to ask for more clarification, and also let them know that point b) is not correct.
1 Like
Thanks Slopp. The article was very useful indeed.
Thanks for all the pointers. I'll try to build a case based on them.
One more thing. We use ArcGIS with has python built in it, and Excel, which has VBA. Can I use them as examples of 'development tools' and argue why IT allows them and not R?
I think that's a good point to raise. They may just lack understanding of what R is. I've heard people lump R in with Tableau.
1 Like
If your company uses AWS, there are a few RStudio AMI which work well (http://www.louisaslett.com/RStudio_AMI/). This enables you to use RStudio through a web browser on AWS, with the highest levels of security depending on how your set up the instance.
I have git set-up and all my RStudio projects can push/pull from my companies git repository, and I execute functions from a terminal with Rscript from a conda environment, and use the optparse package to pass a single json variable, which contains all the configuration information. You can get much more complicated with this setup, for example, one can set-up lambda and step functions which initiate a specific R function automatically based on a trigger (from an s3 bucket, for example), meanwhile being "serverless"... unfortunately, most people under-estimate what R can do. In many cases it is much more efficient than other scripted or object based languages, as long as you take advantage of the cluster and mclapply type functions/packages, the options are endless...
1 Like
Regarding "production ready" ...there is a powerful way to make R functions super portable and executable from a terminal with Rscript MyFunction.R --json=config_file.json If, for example, you're using conda environments (which can be turned into dockers, more or less) than this simple implementation of Rscript along with the optparse package make R super portable and production ready (in my opinion) 
Thanks Joe for the feedback. But this is beyond me
I'm an engineer and use R to analyze environmental data, as a lot of scientists/engineers do.
Again, thanks for all the responses.