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.

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?

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.

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

“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.

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.

An optimized vm boots in < 2 seconds...

Heck, a hardware server can boot in seconds if you skip POST entirely

My experience with Azure and AWS is that it takes quite a bit longer than 2 seconds before a new server is up.

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?

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

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.

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.

With serverless you only pay for a request and you (almost) don't care about scaling. While non-serverless implies that you have to manage how many server instances you want, and have them running and pay for them even if you have no traffic.

I feel the whole "not paying for underused server" argument is pointless when a serverless solution is way more expensive than paying for an idle server.

It isnt more expensive!

Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete. Not only would it cost more but you'd probably hit the concurrency limit in AWS Lambda.

But we also have an admin UI that gets about 2500 visits a day. We're running that for about $4 a month - with virtually no operational burden whatsoever, and with a reassurance of resilience.

We worked out that the inflection point of value is at about 3 million requests a month. (that's an fag packet estimate, arbitrarily expensive 'request', your mileage may vary).

Its no silver bullet, but for some applications, particularly personal projects, low traffic and startup scenarios it can be ideal.

I just hate it that discussions end up in people talking about keeping the function warm and quickly go downhill from there.

A managed app runtime can be great though: for those who tried Google AppEngine back in the day, it was amazing to work with.

>> Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete.

I'm curious about this statement because I'm currently working on a project where the intent is to port a legacy app to AWS Lambda. The legacy app is currently distributed across 96 VMs and handles ~ 50K reqs/min during normal times but can run into ~ 3M reqs/min during high demand.

Are you saying AWS Lambda can not scale to handle this type of demand and if so can you point me to some resources/references that explain this?

For the record, I'm not the one that came up with the architecture.

mcrittenden is right in that it probably will cost more to run than just having the old processes run on ECS/EC2. Lambda charges a premium for maintaining its control plane and development of the product that only makes sense to pay if your app has 'idle time'.

But also there is a per account per region concurrency limit of 1000 parallel executions. That's shared across all lambdas. If you hit it, requests will not be for-filed, increasing this limit is entirely at Amazons discretion, and wont they necessarily do it. I stand corrected, see comment.

https://docs.aws.amazon.com/lambda/latest/dg/limits.html

In your case 3m reqs/min will be fine if each request can be completed in no more than 20 milliseconds, and then you'll be on the knife edge.

If you wanted to reap the benefits of Lambda on the development side, loose the limits and keep server costs low(er) you could deploy OpenFaaS or similar in ECS. However you then loose the operational benefits of a managed solution.

The 1000 concurrency is a default limit, and we're very happy to raise it if you need more. The instructions for a limit increase request are here: https://docs.aws.amazon.com/lambda/latest/dg/concurrent-exec...

(Source: I work on Lambda at AWS)

Fair play - added a correction, that statement came from discussions with our DevOps facility rather than first hand contact with Amazon, so there could be something else going on.

I think he/she meant that Lambda wouldn't compete on pricing (as opposed to on performance).

Both pricing and performance. It will scale, but it’s gonna cost a ton, and won’t be faster than running servers (and could be considerably slower for a percentage of requests).

So the main advantage is that it scales easily, but then it's only cheaper if you actually don't need it to scale?

But it's so much cheaper bud (it's not). It maybe is only when you're doing <= $10/month.

I don't know if it's the HN effect but I never had a scaling problem. Prior acquisition the story says whatsapp used to run on a single server

It depends on the type of application. But when at 5pm your traffic grows by 200x (hint: it doesn't) and you petascale your aws vps megafleet (hint: you don't, especially your database you don't) then you are on route to unicorn-scale hypergrouth cash-money-team-happiness.

My personal take is this...

1. start with docker (or dokku), on a single server, it's easy enough to get going, automate CI/CD. Make sure your backups are working and relatively frequent.

2. Break your lower environments on to a separate server.

3. Break out your database, and set up redundancy at that layer. Leverage DBaaS if you can.

4. Grow to multiple app/api instances for redundancy, and setup rolling deployments.

5. Scale Vertically (bigger servers/instances)

6. Migrate to Kubernetes and expand your automation and tooling.

7. Break apart your application into smaller pieces to scale individually. Possibly leveraging platform tools like Lambda/Functions.

8. Work towards redundant datacenter and application data sharding to deliver a closer experience.

By the time you get to 5-6, you should be making money or have a good investor strategy in place for capital. There's very little need to go all out when at concept or earlier release stages.

6-8 may take place in a different order, depending on your needs.. but again, you should have money or have raised capital by this point, or you have a relatively good problem to have otherwise.

IIRC Stack Overflow grew vertically pretty big on a single server, then two (db/application split).

Also, you don't need to worry about server security or server setup outside of the code you're running. With a typical VPS, you'd have to install software updates yourself and have a plan for how to set up a server from scratch again if needed (nontrivial if you do a lot of setup manually over SSH).

Essentially, a good way to set something up that requires minimal maintenance.

They were talking about Webhosting, not VPSs. With webhosting, the hosting company usually manages the software, you just dump your code (or cgi-bin binary) into a directory. For example https://www.hostgator.com/web-hosting

Just like old shared webhosting :)

I made a quick list[0] of cheap shared hosting providers I found on LEB[1]

[0] https://gist.github.com/shaunpud/35f77b542eaec7c7024bbb15c2e... [1] https://lowendbox.com

Most webhosting plans are fixed monthly fees, AFAIK. The only one I knew that billed for used resources was NearlyFreeSpeech.

Was? [1]

1: https://www.nearlyfreespeech.net/services/pricing

Was, at the time I last looked at it :)

The way I see it, it's basically just a cost-saving measure. If you have some very varying workloads, instead of paying for having a bunch of servers running all the time (and idling most of that time), when you actually need the extra compute power you can let AWS Lambda spin up a server, run the code, then spin it down again. That's clever and all, and might save you a pretty penny if you have huge workloads only part of the time - but for most users, it's hardly worthy of the hype.

It does feel like just FTPing a .php file into your LAMP webhost, but with autoscaling, slicker UX and much more vendor lock-in.

> and much more vendor lock-in.

This is a myth that really needs to be busted. There is almost no lock in with serverless. The serverless products from all the major providers are nearly identical.

The lock in comes from the services you are using within a particular cloud, which you can avoid if you want to by running everything else in k8s.

regarding your k8s comment, did you mean kubeless?

k8s == kubernetes, like i18n == internationalization

With the difference that you pay per request instead of per month / year. Mind you, given how cheap LAMP webhosts can be, I'm fairly sure they would be cheaper if you don't need the autoscaling.

Seriously, VPS hosts are so far ahead of the cloud when it comes to cost/resource ratio. I can get a 4-core 4GB 120GB SHDD instance for ~$2/month.

https://lowendbox.com/blog/hostedsimply-4gb-ram-ssd-cached-v...

EDIT: cheaper even, $1.58/month:

https://lowendbox.com/blog/n3servers-vps-hosting-and-hybrid-...

Low-cost VPSs are great, but their uptime is usually garbage. I myself run almost everything on a 9€/mo Contabo box (6c, 16GB) and while it's nice and powerful, it gets randomly rebooted way more often than acceptable (and I've heard similar about other hosts). For the "I'll get an angry phone call if the app is down for half an hour at 4 am" category of projects, the cost of a reliable enough VPS comes very close to the equivalent in the cloud, where you also get the benefit of pointing a finger at your provider if something goes wrong.

Doesn't happen to my VPS. I think my uptime is 100% this year.

Does it really? As far as I understand it, in a traditional webhost you have a certain set of resources allocated to your account for which you pay even when 0 traffic hits it. Serverless consists of an isolated chuck of logic that runs only when a request hits your server. When the traffic is 0, server resources are blocked on an idle service.

It’s kind of similar, but imagine php without the ability to break anybody else on the web host and infinite resources as much as you wish to pay. So no server migrations. No debugging performance problems.

So it is just the natural progression of a shared LAMP host that’s worked well for 20 years.

To add to the other comments, using serverless with AWS Lambda has been very useful for us in our data pipeline, in a large part because you can hook them up to respond to a number of events like S3 uploads, updates to dynamo tables, or to an SNS or message queue topic. It scales up effortlessly and is very cheap to run. Could we have done this by avoiding serverless? sure but we would have to maintain quite a bit more infrastructure - why do that when someone else can handle that infrastructure cheaply? I realize my example is provider-specific but I think having them act as asynchronous data transforms and workflows are where the serverless really shines, especially given the invocation overhead of 20-30ms or so when hot, and several seconds when cold.

We have run into instances where the serverless model doesn't work so well, like when we updated our graphql API to query a postgres store - each lambda invocation created its own connection pool and would overload the database. Currently theres no way to reliably persist those somewhere else and have the lambdas pick up the persistent connection (like how a redis session store would work) - perhaps that will change. the lambdas work best when they're more-or-less "pure functions", so if you have to keep things like sql connection pools, or a session around, you still need your own persistent server.

Serverless is identical in every respect to traditional hosting/managed services with one exception: micro-billing. In web hosting you are often either constrained by the "level" you pay for, or have to configure scale and pay for the size of your domain. True serverless should auto-scale on demand without your intervention, and it should only bill you for what you use. Have a slow month and are idle? Pennies. Have a phenomenal month and huge usage? Dollars. There is less server, not no server, but instead of worrying about the OS or even platform level dependencies, you can focus just on the bit of code you want to run. If your server is a house and a virtual machine is like renting a house, platform-as-a-service is an apartment and serverless is a hotel (thanks to Scott Hanselman for that analogy).

People abuse the term serverless, yes to mean "cloud" or "somebody else server" and "just write the function you want we will find a server to run it on and report to you the result".

The term I like to associate with serverless is all peer-to-peer, not client-server architecture, for example any datwebsite, on datproject, and any zsite on zeronet.

There you dont have a server, really, a zite is a peer in a torrent swarm like any other, and can be found like any other torrent by its infohash (sha1) in the DHT, and can at any time go offline, while the swarm continues as nothing happened, new people can still access the zite from peers - and the zite despite rendering in a web-browser, can/should not really talk to any server, only to a peer-to-peer network. There is no "form submit" allowed on a zite, then it defeats the purpose of zeronet and similar techniques.

Another example is gun.js

You are coming up with your ow definition of serverless. For most people serverless means

1. Per invocation billing 2. No need to provision resources ahead of time

Taking AWS's example

1. EC2 is not serverless but Lambda is 2. RDS is not serverless but Aurora Serverless is.

It's not their own definition, this was the default definition just a few years ago.

People started to use the term for something else and now it became the main meaning.

"Serverless" is nowadays "AWS Lambda" (and similar products).

I wish people called it FaaS (function as a service), but they call it "serverless", and it's fine I guess

Yeah, now the term is an oxymoron, "serverless" but there is a server and a client.

This is not what "serverless" means nowadays.

What "serverless" means, in the context of the article (and basically how anyone uses it today), is "AWS Lambda" (or FaaS). The name is kinda stupid, since it still uses servers; it's just that you don't need to care about them and scaling is done magically by Amazon.

That is very interesting topic. If you were able to add secure computation with some kind of homomorphic encryption [0] it could be possible to get rid of centralized compute vendors. The only issue is the performance of such computations which are still cheaper to run unencrypted in a trusted env.

[0] https://en.wikipedia.org/wiki/Homomorphic_encryption

Serverless means "I don't have to maintain or even know anything about a server", not "there is no server".

If so any memory-managed language should be called memoryless, any non-low-level language should be called osless and so on. It's an absurd naming scheme.

It's the new PaaS, but scoped down to a smaller payload of just a single function, although most platforms now let you upload an entire app or container anyway.

The other big change was removing the concept of servers/instances altogether so there is no step-wise scaling at all that you can see or control.

It just simplifies an entire field of software engineering (devops) into a simple "one-click" setup.

Before, you had to open an account, provision a server, figure out your machine image, install dependencies, figure out error/process handling, deploy...

...figure out optimization, payment, RAM usage, longevity, how many instances do I need? What are peak hours, and should it autoscale?

No you just run a single command line and it's up in the cloud, figuring all that out for you automatically.