Pickling is very convenient for its purpose. It's also... very bad in production. The problem is that the serialization format is derived from the implementation and not very stable, so if the implementation changes - sometimes in subtle ways like upgrading your Python version - the serialized data isn't readable anymore. You're almost always better off either using an explicit data serialization format (JSON with schemas, protocol buffers, etc.) and writing your own logic for saving and restoring to/from it.
> the pickle file is just a black box input data flows in, response flows out of it
There's 100% more to it than that - there's got to be something that's evaluating the data in the pickle file and actually using it to compute the response. That substrate layer probably doesn't change often, but it should have its own versioning and deployment story.
Could be wrong, but I do not believe this is true anymore. There are pickle versions, but I believe the format has been standardized such that you should be able to freely move between Python releases.
I suspect that is the Microsoft Azure ML part I'm not sure. As I said I don't write the models, I just come along afterwards and review the results. I don't know anything about Python.
The equivalent would be a .dat file :-)
From point of view of the integration process the pickle file is just a black box input data flows in, response flows out of it. If something changes with the model (trained it on a new dataset etc.) then it's just a matter of drop in a new pickle file and it all keeps working.
I don't know if you can do the equivalent with packaging R code like this. All of the tooling is setup around Python and I think this is pretty industry standard we use Azure and I'm pretty sure this is all out of the box stuff.