Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless Architectures

martinfowler.com

Post reply on HN
Print view View original

61–70 of 149 posts

Re: Serverless Architectures

#61

Post by SideburnsOfDoom »

Spearchucker wrote: post #58
SideburnsOfDoom wrote: post #55

Earlier quoted context omitted.

> 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…

First, "client". A client is anything that calls a server but is outside the trust boundary of that server. And yes, of course there's code that accesses the database. The problem is that if it's client code, that code must be trusted by the database. A better approach is where there's code between the client and the database, also on the server (server estate, at least), that verifies data going into and out of the…

Why would a lambda fn be considered untrusted client code?

If the database and the lamdba fn are both in AWS, then they're on the same "server estate". How is this any different from the server portion a web app?

Re: Serverless Architectures

#62

Post by Spearchucker »

SideburnsOfDoom wrote: post #61
Spearchucker wrote: post #58

Earlier quoted context omitted.

First, "client". A client is anything that calls a server but is outside the trust boundary of that server. And yes, of course there's code that accesses the database. The problem is that if it's client code, that code must be trusted by the database. A better approach is where there's code between the client and the database, also on the server (server estate, at least), that verifies data going into and out of the…

Why would a lambda fn be considered untrusted client code? If the database and the lamdba fn are both in AWS, then they're on the same "server estate". How is this any different from the server portion a web app?

Maybe I wasn't clear on that - a lambda function calling the database is indeed trusted.

Re: Serverless Architectures

#63

Post by SideburnsOfDoom »

Spearchucker wrote: post #58
SideburnsOfDoom wrote: post #55

Earlier quoted context omitted.

> 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…

First, "client". A client is anything that calls a server but is outside the trust boundary of that server. And yes, of course there's code that accesses the database. The problem is that if it's client code, that code must be trusted by the database. A better approach is where there's code between the client and the database, also on the server (server estate, at least), that verifies data going into and out of the…

> The author, however, specifically calls out direct database access from the client without lambda functions.

Ah sorry, I missed this part:

> 2 Using another example of BaaS, we’ve allowed the client direct access to a subset of our database (for product listings)

"The client" in this sense is a web browser and is thus completely untrustworthy. He seems to be talking about read access, hopefully with an api gateway for auth and rate limiting in front of it. But yes, it is wise to be much more wary of this case.

Re: Serverless Architectures

#64

Post by djb_hackernews »

Spearchucker wrote: post #3

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 e…

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.

Re: Serverless Architectures

#65

Post by vmateixeira »

mikegerwitz wrote: post #50

There are a number of things I find alarming about this (which is nothing new): Firstly, the author is encouraging the conversion of traditional web pages to single-page web applications, which means that users would now have to download actual software to use the website rather than using the software that they already have and trust: their web browser. Perhaps most alarming is the acknowledgement of this: > One of…

Hi Mike,

Just read your presentation, couldn't agree more with the state of the web.

Ironically, thanks for sharing :)

Re: Serverless Architectures

#66

Post by [deleted] »

atrudeau wrote: post #33
osipov wrote: post #26

Earlier quoted context omitted.

Since serverless is a kind of a PaaS, it offers many of the same benefits. However, unlike Heroku, Cloud Foundry, OpenShift, and other traditional PaaSes focused on supporting long running applications and services, serverless frameworks offer a new kind of a platform for running short lived processes and functions, also called microflows. The distinction between the long running processes and microflows is subtle bu…

Sounds like inet.d, or CGI behind a webserver.

[deleted]

Re: Serverless Architectures

#68

Post by icebraining »

andreasklinger wrote: post #25
gmazza wrote: post #14

Serverless = new name for PaaS. VPS (virtual private servers) were available (and largely ignored) for quite a while before 2006, when AWS came along with the catchy word "cloud". This single word changed everything. Same technology all of the sudden became cool, and everybody started using it. Maybe now it is the turn of PaaS [1] - call it "serverless" and folks finally start seeing all the benefits (true scalabilit…

Might get this wrong but from my understanding: PaaS: Platform (as in Server eg used for API) on demand (as in api.something.com/*) FaaS: Function (as in eg api endpoint) on demand (as in api.something.com/v1/get_latest_posts) Of course you can create the 2nd with the approaches of the 1st but the from my understanding the main benefit is that you dont have to - as in: you can just take one endpoint and have it manag…

Yes, you could simply upload some code to the service, and they will be called only when there's a request to that particular code, instead of running a process continuously.

It's called "shared hosting" and was invented in the 90s.

Re: Serverless Architectures

#69

Post by solipsism »

SideburnsOfDoom wrote: post #61
Spearchucker wrote: post #58

Earlier quoted context omitted.

First, "client". A client is anything that calls a server but is outside the trust boundary of that server. And yes, of course there's code that accesses the database. The problem is that if it's client code, that code must be trusted by the database. A better approach is where there's code between the client and the database, also on the server (server estate, at least), that verifies data going into and out of the…

Why would a lambda fn be considered untrusted client code? If the database and the lamdba fn are both in AWS, then they're on the same "server estate". How is this any different from the server portion a web app?

This is something that annoys me about relative terms like "client" and "backend". An entity can simultaneously be the client of one pair and the server of another.

No good solution comes to mind, aside from being very explicit. "database client" vs "user client".

Re: Serverless Architectures

#70

Post by jrs235 »

jrs235 wrote: post #31
Tomte wrote: post #24

Earlier quoted context omitted.

Yes, but that's probably because the HN submission bookmarklet puts the site name behind the dash. It annoys me every time I'm submitting something. But evidently not enough to finally edit the bookmarklet.

Ditto about the annoyance. Never thought about editing the bookmarklet... I'm going to do that now!

Here's is my slight change to the bookmarklet code. It's not fool proof and and I'll have to see if it actually results in me editing submitted story headlines less often or not. It basically takes the substring of the document title from the start until it finds the first hypen (-) or pipe (|) which are what seems like most sites use when appending the site name.

  javascript:window.location="http://news.ycombinator.com/submitlink?u="+encodeURIComponent(document.location)+"&t="+encodeURIComponent(document.title.substring(0,document.title.search(/[-|]/)).trim())
Post reply on HN