6 ms·

The API gateway made me smile. In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests -

The API gateway made me smile. In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests - they're all the same thing. There's merit in serverless, no doubt. There are many things that worry me. Not owning the infrastructure means I don't get the telemetry I'd like, making triage difficult. Direct access to the database is a good idea said nobody ever. And at what point does my own infrastructure become more cost-effective than cloud? Those concerns don't invalidate the applicability or relevance of serverless though. I think its value as a protyping tool, or to validate a proof of concept is huge.

rahkiin 10y ago
> And at what point does my own infrastructure become more cost-effective than cloud? I am no expert at all, but one idea came to mind: say you have this small festival each year (or once) where you have 1 month (or less) you can buy tickets. Instead of setting up, securing, etc a whole server stack you can simply run te ticket-purchase code on a FaaS and have a database with results. Running your single page app all year on a very simple host, but having this database and compute thing only one month.
- dottedmag 10y ago
  Or, better, utilise PaaS service for ticketing, which hopefully has better UX, design, security etc.
marktangotango 10y ago
The vast majority of web sites on the internet today don't need much infrastructure, they're low traffic blogs, web sites for the hair salon down the street, or a landing page for a non software corporation. Facebook fills this role for a lot users, and they in turn sacrifice their data and privacy to a souless corporation. Don't forget the $billions dollars industry of shared hosting providers out there. A lot of businesses still pay $10 a month for a shared server, mysql, and php. Why should this be the case? Why should it cost anything to have an online presence today? Why shouldn't users own their data? In my personal opinion, these types of FAAS (function as a service) and mBAAS (mobile Backend as a service) the article is talking are an enabling technology in this regard.
- jeswin 10y ago
  Even if it costs nothing, Facebook is a far better option for hair salons and other similar small businesses. Facebook drives engagement and views, while nobody will bother with a self hosted website. The oft repeated lesson here is that convenience trumps privacy for the vast majority of users. If you look at the last decade, in spite of there being robust, self-hosted solutions for syndication and engagement such as RSS, pingbacks, OPML etc, in the end closed systems won. Maybe there is a secret ingredient to making it work again, but we don't know what that is. Yet.
  - marktangotango 10y ago
    I think the secret sauce may be in things like 'call ahead seating' or 'get in line, online' that some restaurants and hair styling places do now. You don't typical get that capability on facebook, and it's a differentiator.
    - icebraining 10y ago
      Thing is, why would a hair salon (which presumably has no advanced technical skills) choose to write or purchase software to run on their FaaS service, instead of simply registering an account on a SaaS service that takes care of everything for them, and even integrates with FB?
- icebraining 10y ago
  FAAS and mBAAS still cost resources, so they still cost money, and someone has to pay for that. If you're hosting a low traffic, mostly static site, I think you're better off paying $18/y on NearlyFreeSpeech (for a dynamic site with a database), where you are actually a client, than relying on the freemium plan from a cloud service for which you are just a prospect.
SideburnsOfDoom 10y ago
> In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests - they're all the same thing. On AWS, you have options a message queues (SQS), busses (SNS), API gateways, and load balancers (ELB). i.e. many of the existing proven patterns are still around, and you can choose which one is best for the particular circumstance. And that indicates that while they have similarities, they're not exactly the same thing. I can see cases where a design of "API gateway -> lambda fn -> database" is performant, simple and very cost effective. particularly where the function is very simple and load is low or varies a lot. That won't be everything though. I don't understand why you think that "Direct access to the database" is always bad. Someone has to access that database directly, on behalf of everyone else who is insulated from it. A lambda fn may not be worse than a web app for that role. But if it is inadvisable, then it can use the same indirect requests that a web app would.
- Spearchucker 10y ago
  If you give client code access to your database you have to trust that client to respect data types, sizes and, depending on how your database is designed, referential integrity. There's risk of data loss because again, you have to trust the client. There's risk of denial of service in scenarios where the client fills up your database with junk. It's risk all the way down and using it or not is down to probability x impact.
  - SideburnsOfDoom 10y ago
    > If you give client code access to your database you have to trust that client to respect ... I get all that but I still am unsure of what you mean. A database is useless if no-one can ever access it. So some code somewhere accesses that database, not so? And other code makes request to this code? What do you consider "client code" and what are you comparing this to? Why do you think that lambda functions cannot be in the second category, and if they cannot be, why can't they use the same gated mechanisms as other "client code", and I would assume that they use restful http to read, and http or message queues to write? > There's risk of denial of service in the AWS lambda case, the rate limiting is specifically the role of the api gateway. There's always the risk, and I don't think that lambda increases it.
djb_hackernews 10y ago
The direct access to the database no no is being challenged, with new technologies it doesn't imply what it historically has. If you haven't worked with DynamoDB you should check it out, via IAM roles you can assign fine grained access controls per user down to the row level. All of the authorization is done at the IAM level and you don't have to worry about validation or data integrity if the user is read only.

rahkiin 10y ago

> And at what point does my own infrastructure become more cost-effective than cloud? I am no expert at all, but one idea came to mind: say you have this small festival each year (or once) where you have 1 month (or less) you can buy tickets. Instead of setting up, securing, etc a whole server stack you can simply run te ticket-purchase code on a FaaS and have a database with results. Running your single page app all year on a very simple host, but having this database and compute thing only one month.

dottedmag 10y ago
Or, better, utilise PaaS service for ticketing, which hopefully has better UX, design, security etc.

marktangotango 10y ago

The vast majority of web sites on the internet today don't need much infrastructure, they're low traffic blogs, web sites for the hair salon down the street, or a landing page for a non software corporation. Facebook fills this role for a lot users, and they in turn sacrifice their data and privacy to a souless corporation. Don't forget the $billions dollars industry of shared hosting providers out there. A lot of businesses still pay $10 a month for a shared server, mysql, and php. Why should this be the case? Why should it cost anything to have an online presence today? Why shouldn't users own their data? In my personal opinion, these types of FAAS (function as a service) and mBAAS (mobile Backend as a service) the article is talking are an enabling technology in this regard.

jeswin 10y ago
Even if it costs nothing, Facebook is a far better option for hair salons and other similar small businesses. Facebook drives engagement and views, while nobody will bother with a self hosted website. The oft repeated lesson here is that convenience trumps privacy for the vast majority of users. If you look at the last decade, in spite of there being robust, self-hosted solutions for syndication and engagement such as RSS, pingbacks, OPML etc, in the end closed systems won. Maybe there is a secret ingredient to making it work again, but we don't know what that is. Yet.
- marktangotango 10y ago
  I think the secret sauce may be in things like 'call ahead seating' or 'get in line, online' that some restaurants and hair styling places do now. You don't typical get that capability on facebook, and it's a differentiator.
  - icebraining 10y ago
    Thing is, why would a hair salon (which presumably has no advanced technical skills) choose to write or purchase software to run on their FaaS service, instead of simply registering an account on a SaaS service that takes care of everything for them, and even integrates with FB?
icebraining 10y ago
FAAS and mBAAS still cost resources, so they still cost money, and someone has to pay for that. If you're hosting a low traffic, mostly static site, I think you're better off paying $18/y on NearlyFreeSpeech (for a dynamic site with a database), where you are actually a client, than relying on the freemium plan from a cloud service for which you are just a prospect.

SideburnsOfDoom 10y ago

> In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests - they're all the same thing. On AWS, you have options a message queues (SQS), busses (SNS), API gateways, and load balancers (ELB). i.e. many of the existing proven patterns are still around, and you can choose which one is best for the particular circumstance. And that indicates that while they have similarities, they're not exactly the same thing. I can see cases where a design of "API gateway -> lambda fn -> database" is performant, simple and very cost effective. particularly where the function is very simple and load is low or varies a lot. That won't be everything though. I don't understand why you think that "Direct access to the database" is always bad. Someone has to access that database directly, on behalf of everyone else who is insulated from it. A lambda fn may not be worse than a web app for that role. But if it is inadvisable, then it can use the same indirect requests that a web app would.

Spearchucker 10y ago
If you give client code access to your database you have to trust that client to respect data types, sizes and, depending on how your database is designed, referential integrity. There's risk of data loss because again, you have to trust the client. There's risk of denial of service in scenarios where the client fills up your database with junk. It's risk all the way down and using it or not is down to probability x impact.
- SideburnsOfDoom 10y ago
  > If you give client code access to your database you have to trust that client to respect ... I get all that but I still am unsure of what you mean. A database is useless if no-one can ever access it. So some code somewhere accesses that database, not so? And other code makes request to this code? What do you consider "client code" and what are you comparing this to? Why do you think that lambda functions cannot be in the second category, and if they cannot be, why can't they use the same gated mechanisms as other "client code", and I would assume that they use restful http to read, and http or message queues to write? > There's risk of denial of service in the AWS lambda case, the rate limiting is specifically the role of the api gateway. There's always the risk, and I don't think that lambda increases it.

djb_hackernews 10y ago

The direct access to the database no no is being challenged, with new technologies it doesn't imply what it historically has. If you haven't worked with DynamoDB you should check it out, via IAM roles you can assign fine grained access controls per user down to the row level. All of the authorization is done at the IAM level and you don't have to worry about validation or data integrity if the user is read only.