I would recommend you check out some of the serverless providers, it might make the benefits more clear to you;
Check out this case study for AWS and autodesk: aws.amazon.com/solutions/case-stud...
If the physical server starts failing, then Amazon will send you a message that we should back up and migrate our stuff. So we are not admin-less.
This is not how serverless will work, you are not exposed to the server running your functions. If any particular server goes down, traffic will seamlessly be migrated to another server. There is no migration for the end user to handle.
It saves us the task of installing the server but a seasoned Linux admin could install Linux/service in a day if not less.
While the initial setup of a server can be done in a day, the management of that server in a production environment is a reoccurring cost, especially in a production environment. Someone needs to monitor that server. Perhaps scale its resources based on load. Secure that server. There will always* be operational tasks
Updating the server is also trivial for Linux is yum update (a single command) that it could run under a task scheduler (cron), so the administrative job is fairly low, we don't need a full-time Linux admin.
There is a lot more to updating a production environment than making sure you run sudo yum update once a day. Who makes sure that all the packages you upgrade to provide your production environment don't collide? What do you do when upgrading would cause downtime?
Serverless is painfully expensive and slow.
Most hosts are over provisioned. Rarely will you see a server which is operating at full capacity. Any extra cpu, ram, or disk you have left on a traditional server that is not being used is costing you money. With serverless you pay for what you use. Many cloud providers also offer free usage within limits. techbeacon.com/enterprise-it/econo...
Serverless is vendor-lock, so we can't recommend it.
As far as I know, Vendor lock starts and ends with the inclusion of libraries for the cloud provider. Abstract that away from the rest of your code and only your integration point is locked to the vendor.
And Serverless is not even easy to program, it's fast and easy to use the basic but it fails with complex tasks.
Serverless is no harder to program than traditional programming, check out the autodesk case study, or have a look at some of these tutorials, I think you'll agree! cloud.google.com/functions/docs/tu...
Serverless is scalable but it involves a variable cost.
This I completely agree with and is a double edged sword. It's very cheap with low load, but costs will scale quickly under load. This can be unpredictable. But providers will offer budgeting and alerting to keep your costs in check.
*True automation in a self managed environment is very hard; speaking as a DevOps architect, I can testament to that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would recommend you check out some of the serverless providers, it might make the benefits more clear to you;
Check out this case study for AWS and autodesk: aws.amazon.com/solutions/case-stud...
This is not how serverless will work, you are not exposed to the server running your functions. If any particular server goes down, traffic will seamlessly be migrated to another server. There is no migration for the end user to handle.
While the initial setup of a server can be done in a day, the management of that server in a production environment is a reoccurring cost, especially in a production environment. Someone needs to monitor that server. Perhaps scale its resources based on load. Secure that server. There will always* be operational tasks
There is a lot more to updating a production environment than making sure you run sudo yum update once a day. Who makes sure that all the packages you upgrade to provide your production environment don't collide? What do you do when upgrading would cause downtime?
Most hosts are over provisioned. Rarely will you see a server which is operating at full capacity. Any extra cpu, ram, or disk you have left on a traditional server that is not being used is costing you money. With serverless you pay for what you use. Many cloud providers also offer free usage within limits.
techbeacon.com/enterprise-it/econo...
As far as I know, Vendor lock starts and ends with the inclusion of libraries for the cloud provider. Abstract that away from the rest of your code and only your integration point is locked to the vendor.
Serverless is no harder to program than traditional programming, check out the autodesk case study, or have a look at some of these tutorials, I think you'll agree! cloud.google.com/functions/docs/tu...
This I completely agree with and is a double edged sword. It's very cheap with low load, but costs will scale quickly under load. This can be unpredictable. But providers will offer budgeting and alerting to keep your costs in check.
*True automation in a self managed environment is very hard; speaking as a DevOps architect, I can testament to that.