… well ok, it is, but it’s not the only way of doing Serverless.
Serverless - The Serverless Application Framework powered by AWS Lambda and API Gateway
Build web, mobile and IoT applications powered exclusively by AWS Lambda and API Gateway
Now, I’m very impressed by what the Serverless guys have achieved and got out to the community in the last year or so. It’s been one of the best ways of getting into the Serverless approach.
But it’s not the only way, and I’m concerned that the whole approach outside of the community may be seen to be boiled down to “this framework”. Which is frustrating.
Because it’s not the only way of doing it.
It’s not necessarily even the best way of doing it because the best approach is linked directly to what you want to do.
So for some, it will definitely be the right way of doing things.
But there are other frameworks. See Serverless Heroes for a list of other tools and frameworks currently
serverless-resources - A curated list of excellent resources on serverless technologies and architectures
At Movivo, we started using AWS Lambda while the Serverless framework was still called JAWS, and I evaluated JAWS and it didn’t fit what I wanted to do, so I decided not to use it.
We went our own way, and learned a lot of the issues that Serverless is trying to solve, and many others that it doesn’t.
Then JAWS changed it’s name to Serverless which it was entitled to do of course. But this caused a problem to the nascent community.
Because JAWS coopted the name Serverless, and now when someone does a google search for Serverless, they find the Serverless framework rather than details of what the Serverless approach is. A triumph for SEO of course.
But this doesn’t help.
Especially when you’re trying to hire people.
Because they assume that you’re using the Serverless framework.
Which we’re not.
And it’s frustrating.
The worry I have is that in a year’s time, “Serverless” will mean “The Serverless Framework” much like “Our website is built using ruby” most often means “We’ve built our website on Ruby on Rails”.
There is always a predominant framework at some point in an architecture’s life. Unfortunately, I think we’ve got to a point where a framework has become the “de facto” framework because of the name, rather than because it is the best solution out there.
Of course, it could become the best solution.
It might be the best solution now.
But it might not be.
That’s why I’d still like to call it something else.
But I think the discussion may already be over.
And that may not be a good thing.