Managed hosting is used in at least two different ways:
* As a synonym for dedicated hosting. E.g. you rent a machine, and run what you want on it. And have to patch stuff etc.
* As a separate tier of service above dedicated hosting where the hosting provider is responsible for running the services on the machine. Some managed hosting providers will take responsibility for scaling too, though often it will be a semi-manual process.
Managed hosting in this second sense is to serverless what dedicated hosting is to "regular" cloud instances.
You might even toss in running managed services externally in the second definition, for example DNS for your own domain - pretty much every service small to large offers a DNS hosting service with your account, typically at no charge. Otherwise, you'd have to run your own server, etc.
> When you are just using a VM - it’s your responsibility to keep the VMs and the runtimes patched, design a scaling solution, etc.
Your comment did nothing to address the point, which is that your definiiton of "serverless" is actually just a buzzword used to refer to the old as the web commercial practice of managed hosting.
Serverless is not just “managed hosting” in the cgi-bin since - serverless implies there is no server to manage and it’s for all intents and purposes “infinitely scalable”.
For instance, Amazon’s hosted versions of Mysql, Postgres, Sql Server, etc are not what they consider “Serverless” you still have to size it appropriately and if your needs increase, have to move to a larger server. You have to worry about CPU utilization, memory utilization etc.
DynamoDB is considered “serverless” because you don’t have to manage any of that.
The same is the difference between S3 and provisioning storage that you attach to your VM.
Please don't digress. The questions regarding you assertions on "serverless" don't change or are addressed with your attempt to divert attentions to other buzzwords.
> Serverless is not just “managed hosting” in the cgi-bin since - serverless implies there is no server to manage and it’s for all intents and purposes “infinitely scalable”.
You're running in circles by trying to pin a buzzword on managed hosting.
> For instance, Amazon’s hosted versions of Mysql, Postgres, Sql Server, etc are not what they consider “Serverless”
I wouldn't use AWS as an example of coherent classification, as AWS's database offerings have multiple ovelapping concerns, including an overreaching gray area of "serverless-ness". See for example Amazon RDS and Amazon Aurora.
Yes Aurora Serverless is a distinct offering. Regular Aurora you have a certain server of a certain size. Aurora Serverless autoscales - just like lambda.
> Aurora Serverless autoscales - just like lambda.
If you're confused to the point of confounding autoscaling with serverless then I'm afraid there is no point to continue this discussion. You're just underlining the fact that "serverless" is a fad being mindlessly disseminated by clueless proponents.
Well, no I’m not “patently wrong”. Aurora Serverless has limitations and features that are not available with Aurora. This includes lacking the ability to load and unload from S3 and it has the “Data API” which lets you use APIs to interact with the database instead of your typical database connections. This feature is not available with regular Aurora. It was implemented specifically for Serverless workloads so your lambda doesn’t have to “run inside your VPC” since that increases the cold start times.
We specifically could not use Aurora Serverless for our ETL jobs because of the lack of integration with S3
Again there is a difference between reading documentation and actually using it.
I’m also not confounding “Autoscaling” and services. Being able to scale on demand and “scale down to zero” is one of the parts of how Serverless is defined.
>cgi-bin didn’t have any type of process isolation
"Lambdas" don't by nature either. I can run cgi-bin in a FirecrackerVM-like ecosystem with one script per VM.
>Also, it didn’t tie in to other none web based events.
Webhooks aren't new.
I'm not disputing the popularity and convenience of serverless. I'm just noting it's somewhat like Docker. Packaging existing tech in an easier-to-use bundle.
Lambdas by nature do exactly that. AWS’s runtime launches the “VMs” in response to an event.
And with webhooks I’m required to keep enough server capacity running all of the time to handle the events. Can a web hook automatically instantiate enough VMs on demand without reducing throughput?
That still begs the question, why am I as a developer wasting time fiddling with infrastructure that I could just throw a little money and a yaml file at AWS and let them do it? How am I adding a business value that will make my company money doing grunt work?
cgi-bin had pretty strong process isolation for the day (Unix user account and process boundaries/limits/quotas). Enough to have remarkably robust multitenant setups on single servers.
Could Godaddy’s side business launch isolated VMs when items appeared in a queue? A file appeared on a server? Events came from a stream? Could it respond to any events besides http?
To you. But the world has moved on from Apple 2e and now managed hosting is analogous to serverless.
See because only science has a concrete fixed point for measuring which is the speed of light.
Human culture is subjective buzzwords where the only relative fixed point is when they learned a term.
Serverless is “managed hosting 3.0”.
First there was bare metal, run your cage. Then ec2/traditional VMs. Now just an ephemeral thread.
Computer people need to stop thinking in terms used by product & marketing people. Reasoning around it from the perspective of how it’s implemented specifically helps with the understanding.
It’s a Linux OS wrapped in layers of UX to facilitate composition of services. Unix command line tools at scale.
Cloud provider is just an OS at scale. They handle CPU, memory, scheduling, etc., all the same things a desktop OS does from the end user perspective, using a different process model we don’t generally care about as end users
Hopefully OpenAPI will help normalize this interface. Who knows though. Rich people like to drag their feet when they think sticking with the status quo gives them an advantage. Bezos may feel like making it easy to copy paste away from his cloud is a shitty idea
I can’t tell what your point is. I’m agreeing that managed hosting is the next evolution.
But Lambda is more than just for APIs. But if you’re worried about the “lock in” boogeyman for APIs, there are small packages for every language that lambda supports that allows you to run your standard Node/Express, C#/WebAPI, Python/Django/Flask API, etc on lambda just by changing the entry point.
Right now I’m deploying a Node/Express app to both lambda and Fargate (Serverless Docker) withoit any code changes.
