Re: [Discuss] Serverless scientific computing (function as a service)

2017-06-14 Thread Henry Neeman
A couple of thoughts: (1) Depending on specific libraries can be an unintended but unavoidable side effect of the programming language chosen. For example, we've seen plenty of examples of Python code that's quite brittle regarding Python version (and perhaps versions of various packages).

[Discuss] June Community Call?

2017-06-14 Thread Raniere Silva
Hi, the Software Carpentry Calendar has a "Community Call" schedule for tomorrow but I didn't saw any information on the website or this list. In addition, the etherpad for the "Community Call" is empty. Could anyone confirm or cancel the "Community Call"? Thanks,

Re: [Discuss] Serverless scientific computing (function as a service)

2017-06-14 Thread C. Titus Brown
Hi Peter, Nature had a piece on containers recently -- https://www.nature.com/news/software-simplified-1.22059 which has Lorena Barba making exactly the same points as you about software robustness! So at least the opinions are getting out there... In my experience, however, it's difficult to

Re: [Discuss] Serverless scientific computing (function as a service)

2017-06-14 Thread Bennet Fauber
Peter brings up an interesting point about code quality and its role in replicability. It may that too strong a reliance on particular underlying libraries is really an indication of unstable code or unstable methods. Good numerical code should largely survive recompilation. A good example of

Re: [Discuss] Serverless scientific computing (function as a service)

2017-06-14 Thread Peter Steinbach
Hi everyone, thanks for the interesting discussion so far. From my personal point of view, I'd fully agree with the computational burst based argument. If a robust pipeline needs to scale for a short amount of time and local HPC resources are blocked, the cloud is an essential resource.