4 ms·

I will answer here as you kinda summed up what other person said. 1. Same kinda happens with python modules for example 2. All my servers are managed by someo

I will answer here as you kinda summed up what other person said. 1. Same kinda happens with python modules for example 2. All my servers are managed by someone else. You can down vote all you want, but this is in no way different the spawning a bunch of machines somewhere... Also once you start having networking issues there is a server on your diagram... cos all that this is describing is booting up worker nodes. And you can stretch your imagination to call it whatever you like but in the end that is what you are doing.

aidos 9y ago
It's different in that someone else is taking care of the details infrastructure, but to a really high degree. Your function is effectively a single bit of binary executable that will execute once and at termination the fabric it existed on will effectively cease to be. You can definitely say that the lines between that and other forms of execution are blurry but there are quite different modes of operation going on. I have dynamic workers that scale to handle load in our system. I need to know about how the Python binary runs in the system, the upstart jobs that keep the workers running, the queues that push the jobs in, hosted on another machine, the underlying autoscale system, the watchers to figure out how to scale the autoscale system, the network rules between the machines, etc. I know it's kinda the same thing, but it's also kinda not.
- mirko22 9y ago
  So basically you cut a need for in-house sysadmin? The way you are explaining it sounds ok when you have very small team. And if you look at comments below they seem to have an issue of how to do warmup and cold function calls which suggest that you have to know what the platform is doing anyway (has JIT warmed up, do we need to replicate warmed up functions, how do we cold execute fast etc). So to sum up, it is serverless as long as a 3rd party is in charge of the actual servers and auto-scale infra and if we do it in house it is normal server farm? And sorry if i sound "edgy" but I am just trying to stretch the meaning of actual word "serverless" in my brain to what is being talked about here. I am not a native speaker so that might hinder me as well.
  - aidos 9y ago
    As ever, looking at some extreme examples can be instructive. Imagine you have no infrastructure at all, and there's only a single function you need to run. In my case, I have a function that takes a file and produces a file and can take 5 minutes to an hour to run. The warm up time doesn't matter then. If I could just write one big old python function to do all the work and then push it to someone else so I can run as many instances of that function as required then that's a very different mental model from dealing with all the setup required to host that function myself. There are other tasks too, where you just have some one off admin function (maybe some monitoring thing) where it's a pain to build all the infrastructure around it just to run it. You're right though, it really doesn't matter what you use - you have to understand what's going on. For reference, I don't use any serverless stuff in my stack — though I can see where the uses lie and could definitely imagine building for what they offer in some cases. It's a useful tool to have available, but not the only one you should reach for. One of the best environments I ever used was PiCloud. We used to farm out our long running functions to them. Within your code you could say something like, run_fn_on_picloud(fn, args) and they would ship your code into their environment and execute it. It was absolutely wonderful and you could just fan out as much as required.

aidos 9y ago

It's different in that someone else is taking care of the details infrastructure, but to a really high degree. Your function is effectively a single bit of binary executable that will execute once and at termination the fabric it existed on will effectively cease to be. You can definitely say that the lines between that and other forms of execution are blurry but there are quite different modes of operation going on. I have dynamic workers that scale to handle load in our system. I need to know about how the Python binary runs in the system, the upstart jobs that keep the workers running, the queues that push the jobs in, hosted on another machine, the underlying autoscale system, the watchers to figure out how to scale the autoscale system, the network rules between the machines, etc. I know it's kinda the same thing, but it's also kinda not.

mirko22 9y ago
So basically you cut a need for in-house sysadmin? The way you are explaining it sounds ok when you have very small team. And if you look at comments below they seem to have an issue of how to do warmup and cold function calls which suggest that you have to know what the platform is doing anyway (has JIT warmed up, do we need to replicate warmed up functions, how do we cold execute fast etc). So to sum up, it is serverless as long as a 3rd party is in charge of the actual servers and auto-scale infra and if we do it in house it is normal server farm? And sorry if i sound "edgy" but I am just trying to stretch the meaning of actual word "serverless" in my brain to what is being talked about here. I am not a native speaker so that might hinder me as well.
- aidos 9y ago
  As ever, looking at some extreme examples can be instructive. Imagine you have no infrastructure at all, and there's only a single function you need to run. In my case, I have a function that takes a file and produces a file and can take 5 minutes to an hour to run. The warm up time doesn't matter then. If I could just write one big old python function to do all the work and then push it to someone else so I can run as many instances of that function as required then that's a very different mental model from dealing with all the setup required to host that function myself. There are other tasks too, where you just have some one off admin function (maybe some monitoring thing) where it's a pain to build all the infrastructure around it just to run it. You're right though, it really doesn't matter what you use - you have to understand what's going on. For reference, I don't use any serverless stuff in my stack — though I can see where the uses lie and could definitely imagine building for what they offer in some cases. It's a useful tool to have available, but not the only one you should reach for. One of the best environments I ever used was PiCloud. We used to farm out our long running functions to them. Within your code you could say something like, run_fn_on_picloud(fn, args) and they would ship your code into their environment and execute it. It was absolutely wonderful and you could just fan out as much as required.