Originally published at winterwindsoftware.com.
Like many industry buzzwords before it — "cloud computing", "DevOps", "big data" — debates over th...
For further actions, you may consider blocking this person and/or reporting abuse
Great collection!
But .. I do not think the last two quoted definitions are correct.
Paul Johnstons definition is only an effect of the serverless not the source. You can achieve the same effect with zero scaling technologies like AppEngine too, which are not serverless.
Peters is not so completr, you do not need to focus on low level when dealing with containers, but you still have to handle some configs like os type and min max scaling limits, which are not low level but still missing from serverless.
A good list of definitions. What if the provider's server (We've recently faced issue with Microsoft servers and all our apps are down for hours) is down? Should we call it server-less :P
There's always a Dave...
Great article!
I'm thinking of trying the serverless approach in my next pet project. As a PHP developer I've always worked with a server. Do you know any guide ir article for a serverless implementation with PHP?
Thanks! 😀
Jelly Fin is planning on using serverless with Firebase. I'm going this route because I don't want to have to deal as much with setting up server boxes, vms, or containers and then have to monitor them for stability, uptime, etc. etc.
I just want an endpoint I can hit, when I want, and how I want. The beauty is that is scales with the app. When you hit a serverless endpoint once, it takes a few hundred milliseconds longer to execute. This is known as a cold start. In most small apps, this is ok.
As the app scales, you need a faster response. Whatever service you use begins keeping the endpoint in memory and highly-available as it gets used more often resulting in faster responses.
To many, this is a dream come true! Setting up infrastructure in an automated fashion is a pain. You have to provision vms, install operating systems, patch them for security holes, THEN install your app, monitor performance, make sure your servers aren't slammed...the list goes on.
Whenever we cross these boundaries from shared hosting and now serverless architecture, it begs the question...what's next?
That means it's synonymous with PaaS. And it's inferior to the term PaaS, as PaaS comes packaged with the terms IaaS and SaaS to differentiate against.
I don't get why a new word is hyped for an old concept, a word that is both misleading and uninspired. I understand that marketing people use it, but engineers have no justification talking like that. They should know better.
Its a great platform you created...Hats off
TL;DR: Name things after what they are, not what they feel like.
This is a great description of what serverless is. Very readable and easy to understand. Thanks for that!
In my opinion ...
You're totally right.
I think, especially the billing part is left out too often.
"Cloud" is Marketingish for "other people's computers". Say "other people's computers" if you mean that.
I actually did mean the cloud, as in, run on a cloud provider vs. the server my neighbor has in their basement.
So it makes a huge difference for you whether the computer of other people stands in a rack or in a basement?
It does! If it's in a basement and the basement floods or a tornado hits or the neighborhood experiences a power outage, I'm done. A major motivation for going to the "cloud" is to take advantage of features like high availability and regional failover that I don't get from my neighbor's basement. I'd rather not have to set up things like BGP on my own.