The entire "serverless" movement seems to preach something that is impossible. You can't have internet without a server. You can offload server management and maintenance onto a provider, that is true, but you can't remove it entirely from your stack. So preaching "serverless" architecture is disingenuous and IMHO rather ignorant.
For example, API powered by traditional web cserver + database can be replaced with lambda/function + dynamo/s3/firestore. Cron jobs can be replaced by cloud scheduler + lambda/fargate/cloud run. As a serverless user, you really don't interact with "servers", but instead a highly-available and scalable managed task execution environment.
The only downside is each layer of compute abstraction comes at the cost of spending more and more money.
You're tying your own software into somebody else's all-encompassing and potentially hostile (to your business goals) framework instead of preferring the library way with clearly defined and exchangeable interface boundaries.
Doesn't bode well if your OPS tools have one company's name in them.
Sort of like unlearn a man to fish, and he'll be depending on you forever.
We experienced that recently, moving our ETL jobs away from a Hadoop cluster managed by a sister company that was having some issues (as in "all our data engineers resigned half way through a long overdue cluster upgrade, now nothing works")
Our data science team found Amazon Glue and fell in love with its ease and simplicity...
...and then spent three months trying to figure out why everything kept breaking. TL;DR - Glue's DynamicFrames come with a bunch of caveats and mousetraps, and a severe lack of documentation or source code.
Oh sure, you can read the Python source code for a DynamicFrame... ...source code that promptly delegates computations to a Java class you can't get the source code for.
After a few months of our experienced data engineers (myself included) saying "Just write a Spark job and run it in EMR", they finally did, and now everything's fine.
But the initial simplicity of Glue got them hooked, and they threw good money after bad on it. And as for those goddamned Glue crawlers...
TL;DR - things like Glue are great for early prototyping, but they tie you down to the AWS APIs and infrastructure. At least with EMR the Spark job you're running could be easily switched to another provider's infrastructure or your own infrastructure without any heavy refactoring.
We're migrating from a traditional DC into AWS because a) our current DC provider makes stupid mistakes that impact us severely and b) it's pretty easy to spin up the same K8s cluster in two availability zones to ensure we're (very nearly) always up.
Stupid mistakes list - "Oops, one of the disks in a machine in your Couchbase cluster had to be replaced, and we replaced the wrong one!"
"Oops, we lost your machine. It's responding to pings, but we can't find it, so we're going to have to go through the DC pulling plugs to figure out where it is"
"Oops, our sys-admin accidentally deleted your OpenStack deployment because he was testing something in the wrong window."
And this is the best DC we've managed to find in Europe over 12 years of operating there.
Going into AWS will nearly double our infrastructure costs, but our business is willing to pay for it for the reliability factor. No point having a self-healing k8s cluster if the underlying machines disappear because someone typed a command in the wrong window.
BTW my team has investigated OpenFaaS to be able to share code between the cloud and local installations, and if we do OpenFaaS looks promising. The architecture is well documented and makes sense.
Why don't they just call it "Sysopless" or something?
I'd encourage you to checkout my video on Serverless 2.0 which draws out some of the issues with "Serverless 1.0" (which I think you are describing)
In 2019, serverless is not about SaaS products anymore. https://www.youtube.com/watch?v=JvXm-oHi5Mg&list=PLlIapFDp30...
Ah, a marketing term.
It's just a step further then running instances with any cloud provider. There is still physical machinery in the stack, but you don't have to worry about it anymore.
Even if you don't agree with the definition, it is how it is used by most of the people in IT roles currently, so you'd probably have to learn to deal with it.
Not every term in computing is literal. Think about "the cloud" - is it really in the sky? Of course not and Serverless like aivisol is rightly pointing out is an approach and architecture.
To the developer, it's "serverless" when they don't have to care about infrastructure. So if you're using OpenFaaS Cloud or AWS Lambda, as a developer you literally don't have to care.
Also, a CDN would also classify as "serverless", under the definition used by the article.
...not actually without server hardware.
Gitlab Pages and GitHub Pages will gladly host a git branch for you as a static site. Gitlab has built in support for building static sites with any command you want. They have more than enough infrastructure to host a static site for you and it will take <1hr to set it up.
The author has written that really well, simulating a style that some cloud marketing guys still will take serious. Of course every developer with some background in webdev will start to chuckle after a few sentences, but he keeps the flow on a very high level, great!
I wonder if some kind of NLP was involved and a second article with sources attached will follow.
Very good piece of parody!
If the point of using this is to learn how to use k8s for FAAS, great. If the point is to save pennies and create a hassle-free deployment, I would rethink the approach. I've heard good things about Netlify, although as a tinkerer myself I used AWS and CloudFormation with Sceptre to create my site. As unrelated note, if you are familiar with React you should probably consider using Gatsby. It's much easier to extend and customize which happens quite often once you start adding your own little cool widgets.
Static pages can easily be maintained well by a single person; Kubernetes is a nasty king rat of pain and complexity which requires a team of highly-skilled engineers and architects to do well. Its complexity is worth it, in many circumstances, but it is not — repeat, not — the first thing one should reach for. Or the second, even.
I have GitHub set up to push my merge requests to AWS Lambda. The lambda downloads the specific Hugo release I deemed to run on, generates my pages, an pushes to S3 + Cloudfront. Takes less than 10 seconds from merge to publish. No servers. No services fees. Costs $13/year (95% domain fee). Truly "serverless".
At some point I want to retry this on Gitlab, it seems to support the same flow
"The goal of this tutorial is not to show you that you need a Kubernetes cluster to run a static website, it’s to show what can be done with OpenFaaS and Kubernetes."
I don't think it is being advocated that you should make this switch, just an informative article showing the steps required to do so.
You can trigger it by other means, such as if a file is added to a cloud based file storage (think Azure Blob Storage, not Google Drive, though it wouldn't surprise me if that's a hook too) or something happens in your cloud based database. Or old school: someone visits a URL.
The whole web aspect of serverless is just the most popular.