A good title would probably be "Benefits and Risks of Going Serverless", which is a subhed that occurs later in the article.
Although confusing/misleading names might be good at getting attention because they prompt people to dig deeper to figure out what they mean.
You're "hardwareless" from the management perspective, the cost center perspective, in that you don't own it, manage it, or maintain it, you simply use it.
I'll concede it's a bit of a mind bending term, though. You have to think of it from the right angle and in the right way (which means taking off your engineer hat to a degree.)
I'm not super fond of the term myself but the only cases in which it seems to 'require a small conversation' is when people who know exactly what it means complain about how it doesn't mean what they think it should mean.
However, "serverless" is pretty much the only concept (please post more examples if you know of any), which is used to talk about something that is not the literal meaning of the word (it's etymology).
The word "serverless" literally means "without server", but it's being used to mean something that requires a server.
It's almost as if ethernet connections had been branded/marketed as "wireless".
"Your headline should never be a yes or no question, because people will always say 'no'".
Everywhere I travel, tiny life. Single-serving sugar, single-serving cream, single pat of butter. The microwave Cordon Bleu hobby kit. Shampoo-conditioner combos, sample-packaged mouthwash, tiny bars of soap. The people I meet on each flight? They're single-serving friends.
~ Fight Club
It's the gig economy for servers. Rather than a server having a stable comfortable job, it must get one piece of work at a time and only gets reimbursed for services performed, not for its availability.
The next step, obviously, is a softwareless infrastructure, allowing C-level unicorn execs to simply exert their will without going through pesky developers. Is this what the current "no code" trend is about?
Honestly it’s faster/cheaper than doing proper integrations most of the time, simply because the tools are already well-known to the users so there isn’t a lot of futzing around with unfamiliar tools or APIs.
It turns a technical challenge into a business challenge simply by automating the lowest common denominator through the stupidest possible means, and automating it through a point and click GUI. It’s the final nail in the coffin of the swivel-chair data analyst at most companies, however.
This is already happening widely across fortune 500s today... the bloodbath is being felt by the Indian offshore folks who are losing a ton of basic automation support / development work to these RPA tools (which can be operated by onshore management consultants doing operational design work).
I would say UIPath has a pretty good product at the low-mid range though. The high end tools require serious enterprise architecture capabilities like business process management already be in place. UIPath is pretty good if you just want to set up a simple API gateway, parameterize some flows and pass data back and forth.
This space is only now heating up, but IMO a dumb technology like RPA can be more transformative to the industry than we think simply because it’s not technologically elegant. It does solve a real business problem (need to keep deep technical knowledge in many many areas on staff) with a very general-purpose setup.
Source: Worked with senior devs long enough to hear the term uttered before.
Like so many things in tech, it existed long before there was a catchy name for it. I'm sure Google wasn't even the first, but they were selling "Serverless" technology with App Engine 10 years ago.
Serverless is about making as much computing power as you demand available on demand with a "pay only what you use" price model without demanding that you maintain the underlying systems. In addition, embracing this model tends to allow you to break out of the request driven model of needing to call APIs for everything. Instead, you enable a whole host of new event driven interactions between application components.
Even this article misses one of the more interesting advantages: scalability under varying load. AWS Lambda may cost more than an equivalent EC2 instance if run constantly, but it scales up and down almost instantly without adding cost. You just pay for the compute time. So, burst traffic is no sweat (up to your account limits or function configured limits). If your application has highly irregular load, Lambda can keep it more responsive while saving you money too.
And it is nothing like paying for shared hosting or other single unit, where you still have no horizontal scalability.
Many tasks can be done with reduced security privileges directly from the client, by setting up some declarative security via something like Firebase Security Rules.
We don't even need a server for handling File Upload, that is handled by something like Firebase Storage. Of course that there is a server somewhere, its just that don't develop it ourselves but we instead use it as a service.
For tasks that require increased security privileges, or for things like video or image processing we can still spin up a node server if needed using something like Firebase Cloud Functions.
The end result is that we only end up writing minimal server code, and almost all of our code is client code. This does not mean that there is no server though, so the term is a bit misleading but it still captures well the fact that we only have to write a reduced amount of server code.
Umm.. there IS a server in the middle. With some form of docker image with some code on it.
Same as if 10 years ago you spun up a EC2 instances, or 1 year ago spun up a docker image on one of the many providers that supports such things.
If you've ever had to develop an MVP from the ground up and build a business around it, services like this are critical to your acceleration, time to market, and budget.
The more experienced the developer, the faster they are. The faster the technology enables you to be, the faster you'll produce something. Both go hand in hand.
An experienced developer would absolutely love Serverless for most problems they face. Having the option of doing as little Ops as possible and just solving problems in software is the very definition of a software developer (which certainly might be changing over time) :)
That's in the standard environment. Even in the Flexible Environment the configuration is equally nonexistent.
Give AppEngine a try: I honestly believe you'll consider it the true definition of Serverless.
Isn't this 2015's topic?
PAAS takes it one step further, SAAS completely takes servers off you hand. You only deal with the app.
Serverless is probably sitting between PAAS and SAAS, function or code as a service. So maybe we should call it CAAS or FAAS. Serverless sounds nicer but is too vague and meaningless.
Moving everything into lambda doesn't make sense, but for instant horizontal scaling it makes some parts of our app much more responsive and parallel.
When I'm scripting a system deploy to AWS (for example), provisioning and deploying a Docker image to ECS, or even an AMI via Packer is a roughly equivalent amount of development work to configuring a Lambda.
And, usually a container or EC2 instance will have much better performance and cost characteristics than serverless. The exception is services that can benefit from a "scale to zero" capacity, which is great for personal projects but doesn't fit very many production apps.
Isn't that what cloud meant in the first place... and to be honest "nice package" sounds a little bit like a container.
At least, that's what makes most sense.
"Outsourced servers" would be considered IaaS, which is sort of the most basic cloud-level computing abstraction. Abstraction levels increase as you make the leap to PaaS and finally FaaS.
 https://en.wikipedia.org/wiki/Infrastructure_as_a_service  https://en.wikipedia.org/wiki/Platform_as_a_service  https://en.wikipedia.org/wiki/Function_as_a_service