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.
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
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.
In many cases it's an additional abstraction, but there are advantages beyond just better hardware utilization.
Heck, a hardware server can boot in seconds if you skip POST entirely
As soon as the idle state is abstracted away, then it's serverless.
Essentially, a good way to set something up that requires minimal maintenance.
[0] https://gist.github.com/shaunpud/35f77b542eaec7c7024bbb15c2e... [1] https://lowendbox.com
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).
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.
A managed app runtime can be great though: for those who tried Google AppEngine back in the day, it was amazing to work with.
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.
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.
(Source: I work on Lambda at AWS)
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.
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-...
So it is just the natural progression of a shared LAMP host that’s worked well for 20 years.
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.
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
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.
"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
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.
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.
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.