4 ms·

To me, it's about the abstraction layer that you interact with when bringing up your stack. That abstraction layer has gradually moved higher over time as provi

To me, it's about the abstraction layer that you interact with when bringing up your stack. That abstraction layer has gradually moved higher over time as providers try and deliver more for their customers: 1) Hardware) 'I want to run Linux + Stack + App'. You get an empty rack, a network port and a power socket. You have to buy iron, install and maintain OS/platform, runtime environment and your service. Scaling requires more work and buying more stuff. 2) VMs) 'I want to run Stack + App'. Machine and OS is provided for you and maintained. You still have to build runtime environment and your app. Scaling doesn't require capex like (1), but still slow - you have to decide how much capacity you want. 3) Containers) Still 'I want to run Stack + App' but faster scaling so can be responsive rather than in advance. A halfway step to: 4) Serverless) 'I want to run App'. Runtime environment, hosting etc is all taken care of. You just write the app and everything else works at the capacity you need. We've been aiming at this last level of abstraction for a while. As you pointed out, the classic VPS with LAMP got you some of the way there, but without the scaling advantages. Google App Engine got closer but was its own special world. Containers are an important technical enabler to doing it more portably.

Huggernaut 8y ago
I'd like to think 4) is actually Containerless or PaaS - "I want to run App". Serverless or FaaS takes this a step further to "I want to run App on demand". What do you think?
- rkangel 8y ago
  I was going to write a point disagreeing with you, but the logic didn't work. The fact that the PaaS implementation used requires scaling in advance, vs FaaS which can scale as requests come in means that you are exposed to one more (important) detail with PaaS - number of instances. So yes, FaaS has gone up the abstraction stack one more step.
y4mi 8y ago
let me guess, you don't have any experience in ops? 1) Scaling doesn't really require more work. It needs a bigger investment because a hardware hypervisor costs significantly more than a vm... after all, that hard metal can host tens of VMs 2) you still need to manage your linux system and OS if you're buying a VM... the only thing you don't need to worry about is hardware. So, a faulty hard drive, hypervisor failover and similar stuff is taken care of. That doesn't mean that it works, however. It just means that somebody else will take care of it... though it might not work and you're entirely on their mercy to fix it 3) containers don't inherently give you better scaling either. creating images from VMs has been done for ages before docker was a thing, and provisioning a new Node from a VM Image is pretty easy if you're already using Terraform or similar. you're just able to utilize a higher percentage of your hardware with containers, as you don't need to virtualize the kernel... so its a cost-cutting issue, not scaling
- prepend 8y ago
  “let me guess, you don't have any experience in ops?” This is precisely the benefit. It lets you not require as much ops experience to get the same output as what once required a lot. This is pretty neat because now more teams can do more stuff since lots of orgs don’t have good ops or can’t pay.
- tracker1 8y ago
  I would dissent from #3 in that containers also have the inherent advantage of being able to scale and start quickly. A full VM takes time to boot and run through whatever setup/initialization needs to happen at the OS level, where a container just needs to copy/deploy and start. In many cases it's an additional abstraction, but there are advantages beyond just better hardware utilization.
  - y4mi 8y ago
    An optimized vm boots in < 2 seconds... Heck, a hardware server can boot in seconds if you skip POST entirely
    - tracker1 8y ago
      My experience with Azure and AWS is that it takes quite a bit longer than 2 seconds before a new server is up.
windexh8er 8y ago
I would say something like step 3 is mainly needed to get to step 4. While it doesn't have to be containers most of the implementations, as I understand them, use containers as the underlying mechanism to offer up serverless / FaaS. So you have container runtimes, microVMs (Amazon Firecracker) and... What other components are out there?
cortesoft 8y ago
There is a step between 1 and 2, where you pay a per-month fee for an actual server that the provider owns. That was pretty standard operating procedure in the mid 2000s.
throwawa485 8y ago
Is Heroku considered Serverless? Or is it still more like Digital Ocean (which I consider to be more like #2)?
- tln 8y ago
  Heroku is more like containers in this list. Your app is packaged up, runs on as many machines as needed, but you pay while it is running even if idle. As soon as the idle state is abstracted away, then it's serverless.
OnlyRepliesToBS 8y ago
it's a 'pay Amazon forever' layer above all else

Huggernaut 8y ago

I'd like to think 4) is actually Containerless or PaaS - "I want to run App". Serverless or FaaS takes this a step further to "I want to run App on demand". What do you think?

rkangel 8y ago
I was going to write a point disagreeing with you, but the logic didn't work. The fact that the PaaS implementation used requires scaling in advance, vs FaaS which can scale as requests come in means that you are exposed to one more (important) detail with PaaS - number of instances. So yes, FaaS has gone up the abstraction stack one more step.

y4mi 8y ago

let me guess, you don't have any experience in ops? 1) Scaling doesn't really require more work. It needs a bigger investment because a hardware hypervisor costs significantly more than a vm... after all, that hard metal can host tens of VMs 2) you still need to manage your linux system and OS if you're buying a VM... the only thing you don't need to worry about is hardware. So, a faulty hard drive, hypervisor failover and similar stuff is taken care of. That doesn't mean that it works, however. It just means that somebody else will take care of it... though it might not work and you're entirely on their mercy to fix it 3) containers don't inherently give you better scaling either. creating images from VMs has been done for ages before docker was a thing, and provisioning a new Node from a VM Image is pretty easy if you're already using Terraform or similar. you're just able to utilize a higher percentage of your hardware with containers, as you don't need to virtualize the kernel... so its a cost-cutting issue, not scaling

prepend 8y ago
“let me guess, you don't have any experience in ops?” This is precisely the benefit. It lets you not require as much ops experience to get the same output as what once required a lot. This is pretty neat because now more teams can do more stuff since lots of orgs don’t have good ops or can’t pay.
tracker1 8y ago
I would dissent from #3 in that containers also have the inherent advantage of being able to scale and start quickly. A full VM takes time to boot and run through whatever setup/initialization needs to happen at the OS level, where a container just needs to copy/deploy and start. In many cases it's an additional abstraction, but there are advantages beyond just better hardware utilization.
- y4mi 8y ago
  An optimized vm boots in < 2 seconds... Heck, a hardware server can boot in seconds if you skip POST entirely
  - tracker1 8y ago
    My experience with Azure and AWS is that it takes quite a bit longer than 2 seconds before a new server is up.

windexh8er 8y ago

I would say something like step 3 is mainly needed to get to step 4. While it doesn't have to be containers most of the implementations, as I understand them, use containers as the underlying mechanism to offer up serverless / FaaS. So you have container runtimes, microVMs (Amazon Firecracker) and... What other components are out there?

cortesoft 8y ago

There is a step between 1 and 2, where you pay a per-month fee for an actual server that the provider owns. That was pretty standard operating procedure in the mid 2000s.

throwawa485 8y ago

Is Heroku considered Serverless? Or is it still more like Digital Ocean (which I consider to be more like #2)?

tln 8y ago
Heroku is more like containers in this list. Your app is packaged up, runs on as many machines as needed, but you pay while it is running even if idle. As soon as the idle state is abstracted away, then it's serverless.

OnlyRepliesToBS 8y ago

it's a 'pay Amazon forever' layer above all else