Don't forget: We are solving business needs.

Jorge Castro on January 22, 2019

If we are developing a system, program or script for a business then, we are solving a business needs. Sometimes, we are guided (or misguided) tech... [Read Full]
markdown guide
 

'I like useless fad: Serverless. Serverless is not server-less.'

What do you mean here?

 

Serverless is not a real cloud service, it uses a physical server (that it could fail physically).

 

Major cloud providers would disagree! Serverless aims not to remove using servers, but instead to remove the responsibility of managing servers from the user. In the case of a physically failing server, the serverless provider is responsible for ensuring fault tolerance. Big cloud providers are in a better position to provide that tolerance than if you run your own services.

Serverless architectures have tremendous use in event-driven environments. Consider a business need to transform images by adding a watermark and adding metadata to images uploaded to their service.

https://memegenerator.net/img/instances/81647019/not-convinced.jpg

I will explain.

  • 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.
  • It saves us the task of installing the server but a seasoned Linux admin could install Linux/service in a day if not less.
  • 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.
  • Serverless is painfully expensive and slow.
  • Serverless is vendor-lock, so we can't recommend it.
  • 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 scalable but it involves a variable cost.

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.

 
 

Small and Medium Size Business, a PYME in spanish :-P

 

Thanks to clarify.

I did search for it but I got:

  • Server Message Block
  • SMB Protocol
  • Staatliche Muzeen zu Berlin
  • Super Mario Bros
  • etc....

You can see the reason of my confusion now 😂

code of conduct - report abuse