6 ms·

I feel like the term "Serverless" has been hijacked to a point that it will soon become meaningless just like "AI", "IoT", etc. Basically "Serverless" in 2017

I feel like the term "Serverless" has been hijacked to a point that it will soon become meaningless just like "AI", "IoT", etc. Basically "Serverless" in 2017 has become just a hype friendly marketing friendly way of saying "Saas". That said, I think the platform looks great!

sorenbs 9y ago
Thanks a lot for your comment! The term serverless is certainly being overused to attract attention. I do think though, that there is value in talking about new kinds of software architecture is enabled by serverless infrastructure. I wrote up a post on how we at Graphcool use serverless functions internally and what we are planning to integrate in the platform in the future: https://www.graph.cool/docs/blog/introducing-the-serverless-graphql-backend-architecture-ahde7paig2/ https://www.graph.cool/docs/blog/introducing-the-serverless-...
- libria 9y ago
  I think minute incremental charges are the signature for a service that is "serverless". While serverless components are part of your architecture, what is exposed and billed monthly is a standard SaaS interface. In this sense, it is only utilized for its buzzwordiness. That nitpick aside, this looks pretty neat.
resoluteteeth 9y ago
> Basically "Serverless" in 2017 has become just a hype friendly marketing friendly way of saying "Saas". Agreed. I was momentarily very confused when I clicked on the link thinking that this was some sort of pure client-side GraphQL library that was supposed to replace functions normally done on the server.
- revelation 9y ago
  I thought it was the GraphQL equivalent of SQLite.. Please don't call yourself "Serverless" if your service goes down with the remainder of the world once AWS has some problem. Please don't call yourself "Serverless" if someone acquihiring you means my database disappearing from under me.
  - nocman 9y ago
    In other words, please don't call your service "Serverless" if it runs on a freaking server! :-D Based on the title, I also was expecting something that was designed to run client-side.
    - allover 9y ago
      Serverless just means "as the user of this service, you don't need to worry-about/think-in-terms-of 'servers'". It clearly doesn't mean 'no servers involved'.
      - raarts 9y ago
        Not a really good choice for that word if you ask me.
      - squeaky-clean 9y ago
        It's kind of silly for them to compare themselves as "Serverless GraphQL Backend" vs "Backend-as-a-Service" on their homepage as if the two didn't mean exactly the same thing.
      - jjawssd 9y ago
        Hosted just means "as the user of this service, you don't need to worry-about/think-in-terms-of 'servers'".
        deleted 9y ago
        [deleted]
Jdam 9y ago
You forgot "Blockchain".
- paulddraper 9y ago
  Well, that might be overhyped, but at least it has a meaning that everyone agrees on: distributed, multi-party, append-only database.
  - firethief 9y ago
    You'd be surprised how many people think they want "blockchain" in situations where 1 or less of those criteria are applicable. For example, multiple large corporations seem to be funding "let's make our own blockchain" projects but don't intend for anyone else to mine.
gblock72 9y ago
@cocktailpeanuts Graphcool is using Auth0 Extend behind the scenes (https://auth0.com/extend/developers https://auth0.com/extend/developers) to handle the custom code execution. Extend is a Serverless extensibility platform i.e. there are servers but you don't have to manage them. I also agree with you that the term does get overused ;-)
thinkloop 9y ago
It might be a misnomer, but "severless" has been very consistent: temporary fully managed autoscaled lamdas. It's basically the app layer as a service.
tal_berzniz 9y ago
I think serverless currently means " I don't have to think about servers, provisioning or scaling". It's === to function-as-a-service. S3 is the best example so far since people see it as no servers at all, just static file serving (there USA server running S3, but as a user we don't really care)
- sorenbs 9y ago
  This is key to my use of the term serverless. With traditional infrastructure you have to think about capacity in discrete units of hardware. Should I provision one or two servers? Even if you can start and stop servers with an api call, you always have to keep these servers running, because rampup time is in the order of minutes. At Graphcool we have thousands of serverless functions. Most of the time they are not running, but they are all ready-to-go wit delay measured in milliseconds, and they scale individually unbounded of the number of servers you have provisioned up front. It's quite remarkable to think about the flexibility this characteristic afford you when architecting your applications.
e12e 9y ago
I had a hard time figuring out what this is. But looking at the justification fb wrote about graphql: https://code.facebook.com/posts/1691455094417024/graphql-a-data-query-language/ https://code.facebook.com/posts/1691455094417024/graphql-a-d... It would appear it's a half-assed string-based, semi-structured ddl / query-language aiming to be a middleware between actual data storage and thin clients, presenting legacy data as a graph (rather than, say, a (filesystem-like) tree or a relational table structure). Surprisingly the responses are json while the queries, as far as I can tell, cannot be parsed as js/json - but look very similar. Based on that, I gather this is firebase with a graphql front-end: a db-as-a-service with no clear path to move off of if needed? (compared to, say, sql-server as a service). Perhaps harsh, but at least put like that I think both the value-proposition and trade-off is more obvious? Assuming I understood it correctly, of course. Corrections welcome.
- andrewingram 9y ago
  I think "half-assed" is rather harsh. As far as i'm concerned, GraphQL is revolutionising front-end component-based development, and solving a large number of API/platform issues. It's not an exaggeration to say that rarely a day goes by when I don't overhear a conversation describing a problem that simply wouldn't exist if they were using GraphQL. It's not a new idea, there's a lot of prior art, but GraphQL is starting to gain serious traction - with a lot of big name adopters. You're right in that Graphcool is essentially a GraphQL-server-as-a-service, personally I don't have any use for it, but i'm glad it exists.
throwaway13337 9y ago
Whenever I hear serverless, I think backend as a service remarketed. A few years ago they were tried and never fully caught on largely because people saw the inherent vulnerability of betting your entire backend on a company you don't control. It has that old problem of being beholden to a single vendor.
- zeptomu 9y ago
  Yeah it's a new word for an old thing - I think "hosted" is often a better word.
- sorenbs 9y ago
  Thanks for the comment throwaway! Our view is that the main reason Parse and Firebase didn't manage to gain mainstream adoption is that they were too limited. At the time, limitations imposed by available infrastructure forced them to to adopt a nosql model that made it very hard to implement advanced business logic. We have come a long way since then, but unfortunately Firebase is still stuck with the same fundamental data structure. Here are some good resources on this topic: https://www.graph.cool/docs/tutorials/graphql-vs-firebase-chi6oozus1/ https://www.graph.cool/docs/tutorials/graphql-vs-firebase-ch... https://medium.freecodecamp.com/firebase-the-great-the-meh-and-the-ugly-a07252fbcf15 https://medium.freecodecamp.com/firebase-the-great-the-meh-a...
SkyMarshal 9y ago
When I hear "serverless" I think "no middleware, all business logic moved either to the frontend or persistance layer". Frontends are now rich UI's that can consume data directly via API from the persistance layer, and whatever transforms, queueing, etc the middleware used to do is now handled either in the UI or the persistance layer.
dcosson 9y ago
I don't understand this complaint at all, these terms each highlight an interesting set of properties that seem worth having names to refer to them by. AI is usually an algorithm that is generalizing patterns from data, IoT means low-powered, cheap devices that are internet enabled (which obviously have very different properties than, say, a desktop computer). Serverless also seems to have a pretty concrete definition of being built on top of AWS Lambda (or possibly a hosted Kubernetes-like system fits the bill as well) where the server/VM/OS is completely abstracted from you. This leads to completely different systems than, say, a LAMP stack where you're managing a Linux OS and the single-point-of-failure issues that come with it or a SAAS service where none of the code running is your own. I guess it's most similar to some "PAAS" systems (like Heroku or Firebase), but from what I've seen serverless seems to focus on being composable, small/simple independent building blocks whereas a lot of PAAS services that I've seen are a single framework where you're often running something like a monolithic rails app. Serverless kind of feels to me like PAAS meets microservices. It's nice to have a name to refer to this idea. Of course lots of things won't fall exactly into one of these buckets as technology continues to evolve, and other things will try to use these names when maybe they arguably shouldn't qualify. But that hardly makes the categories themselves meaningless.

sorenbs 9y ago

Thanks a lot for your comment! The term serverless is certainly being overused to attract attention. I do think though, that there is value in talking about new kinds of software architecture is enabled by serverless infrastructure. I wrote up a post on how we at Graphcool use serverless functions internally and what we are planning to integrate in the platform in the future: https://www.graph.cool/docs/blog/introducing-the-serverless-graphql-backend-architecture-ahde7paig2/ https://www.graph.cool/docs/blog/introducing-the-serverless-...

libria 9y ago
I think minute incremental charges are the signature for a service that is "serverless". While serverless components are part of your architecture, what is exposed and billed monthly is a standard SaaS interface. In this sense, it is only utilized for its buzzwordiness. That nitpick aside, this looks pretty neat.

resoluteteeth 9y ago

> Basically "Serverless" in 2017 has become just a hype friendly marketing friendly way of saying "Saas". Agreed. I was momentarily very confused when I clicked on the link thinking that this was some sort of pure client-side GraphQL library that was supposed to replace functions normally done on the server.

revelation 9y ago
I thought it was the GraphQL equivalent of SQLite.. Please don't call yourself "Serverless" if your service goes down with the remainder of the world once AWS has some problem. Please don't call yourself "Serverless" if someone acquihiring you means my database disappearing from under me.
- nocman 9y ago
  In other words, please don't call your service "Serverless" if it runs on a freaking server! :-D Based on the title, I also was expecting something that was designed to run client-side.
  - allover 9y ago
    Serverless just means "as the user of this service, you don't need to worry-about/think-in-terms-of 'servers'". It clearly doesn't mean 'no servers involved'.
    - raarts 9y ago
      Not a really good choice for that word if you ask me.
    - squeaky-clean 9y ago
      It's kind of silly for them to compare themselves as "Serverless GraphQL Backend" vs "Backend-as-a-Service" on their homepage as if the two didn't mean exactly the same thing.
    - jjawssd 9y ago
      Hosted just means "as the user of this service, you don't need to worry-about/think-in-terms-of 'servers'".
      - deleted 9y ago
        [deleted]

Jdam 9y ago

You forgot "Blockchain".

paulddraper 9y ago
Well, that might be overhyped, but at least it has a meaning that everyone agrees on: distributed, multi-party, append-only database.
- firethief 9y ago
  You'd be surprised how many people think they want "blockchain" in situations where 1 or less of those criteria are applicable. For example, multiple large corporations seem to be funding "let's make our own blockchain" projects but don't intend for anyone else to mine.

gblock72 9y ago

@cocktailpeanuts Graphcool is using Auth0 Extend behind the scenes (https://auth0.com/extend/developers https://auth0.com/extend/developers) to handle the custom code execution. Extend is a Serverless extensibility platform i.e. there are servers but you don't have to manage them. I also agree with you that the term does get overused ;-)

thinkloop 9y ago

It might be a misnomer, but "severless" has been very consistent: temporary fully managed autoscaled lamdas. It's basically the app layer as a service.

tal_berzniz 9y ago

I think serverless currently means " I don't have to think about servers, provisioning or scaling". It's === to function-as-a-service. S3 is the best example so far since people see it as no servers at all, just static file serving (there USA server running S3, but as a user we don't really care)

sorenbs 9y ago
This is key to my use of the term serverless. With traditional infrastructure you have to think about capacity in discrete units of hardware. Should I provision one or two servers? Even if you can start and stop servers with an api call, you always have to keep these servers running, because rampup time is in the order of minutes. At Graphcool we have thousands of serverless functions. Most of the time they are not running, but they are all ready-to-go wit delay measured in milliseconds, and they scale individually unbounded of the number of servers you have provisioned up front. It's quite remarkable to think about the flexibility this characteristic afford you when architecting your applications.

e12e 9y ago

I had a hard time figuring out what this is. But looking at the justification fb wrote about graphql: https://code.facebook.com/posts/1691455094417024/graphql-a-data-query-language/ https://code.facebook.com/posts/1691455094417024/graphql-a-d... It would appear it's a half-assed string-based, semi-structured ddl / query-language aiming to be a middleware between actual data storage and thin clients, presenting legacy data as a graph (rather than, say, a (filesystem-like) tree or a relational table structure). Surprisingly the responses are json while the queries, as far as I can tell, cannot be parsed as js/json - but look very similar. Based on that, I gather this is firebase with a graphql front-end: a db-as-a-service with no clear path to move off of if needed? (compared to, say, sql-server as a service). Perhaps harsh, but at least put like that I think both the value-proposition and trade-off is more obvious? Assuming I understood it correctly, of course. Corrections welcome.

andrewingram 9y ago
I think "half-assed" is rather harsh. As far as i'm concerned, GraphQL is revolutionising front-end component-based development, and solving a large number of API/platform issues. It's not an exaggeration to say that rarely a day goes by when I don't overhear a conversation describing a problem that simply wouldn't exist if they were using GraphQL. It's not a new idea, there's a lot of prior art, but GraphQL is starting to gain serious traction - with a lot of big name adopters. You're right in that Graphcool is essentially a GraphQL-server-as-a-service, personally I don't have any use for it, but i'm glad it exists.

throwaway13337 9y ago

Whenever I hear serverless, I think backend as a service remarketed. A few years ago they were tried and never fully caught on largely because people saw the inherent vulnerability of betting your entire backend on a company you don't control. It has that old problem of being beholden to a single vendor.

zeptomu 9y ago
Yeah it's a new word for an old thing - I think "hosted" is often a better word.
sorenbs 9y ago
Thanks for the comment throwaway! Our view is that the main reason Parse and Firebase didn't manage to gain mainstream adoption is that they were too limited. At the time, limitations imposed by available infrastructure forced them to to adopt a nosql model that made it very hard to implement advanced business logic. We have come a long way since then, but unfortunately Firebase is still stuck with the same fundamental data structure. Here are some good resources on this topic: https://www.graph.cool/docs/tutorials/graphql-vs-firebase-chi6oozus1/ https://www.graph.cool/docs/tutorials/graphql-vs-firebase-ch... https://medium.freecodecamp.com/firebase-the-great-the-meh-and-the-ugly-a07252fbcf15 https://medium.freecodecamp.com/firebase-the-great-the-meh-a...

SkyMarshal 9y ago

When I hear "serverless" I think "no middleware, all business logic moved either to the frontend or persistance layer". Frontends are now rich UI's that can consume data directly via API from the persistance layer, and whatever transforms, queueing, etc the middleware used to do is now handled either in the UI or the persistance layer.

dcosson 9y ago

I don't understand this complaint at all, these terms each highlight an interesting set of properties that seem worth having names to refer to them by. AI is usually an algorithm that is generalizing patterns from data, IoT means low-powered, cheap devices that are internet enabled (which obviously have very different properties than, say, a desktop computer). Serverless also seems to have a pretty concrete definition of being built on top of AWS Lambda (or possibly a hosted Kubernetes-like system fits the bill as well) where the server/VM/OS is completely abstracted from you. This leads to completely different systems than, say, a LAMP stack where you're managing a Linux OS and the single-point-of-failure issues that come with it or a SAAS service where none of the code running is your own. I guess it's most similar to some "PAAS" systems (like Heroku or Firebase), but from what I've seen serverless seems to focus on being composable, small/simple independent building blocks whereas a lot of PAAS services that I've seen are a single framework where you're often running something like a monolithic rails app. Serverless kind of feels to me like PAAS meets microservices. It's nice to have a name to refer to this idea. Of course lots of things won't fall exactly into one of these buckets as technology continues to evolve, and other things will try to use these names when maybe they arguably shouldn't qualify. But that hardly makes the categories themselves meaningless.