I think the word serverless makes more sense in p2p/decentralized architectures, than in platforms using pre-built servers.
Serverless Architectures
121–130 of 149 posts
Re: Serverless Architectures
#122Earlier 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…
> I get all that but I still am unsure of what you mean. Direct database access would be like exposing ODBC from the DB directly to a web application. You either have to trust that the application doesn't do a "drop table ..." or hope that the DB has fine-grained enough access controls to prevent that. Whereas in a SOA design, the API endpoint runs your code that gates access to the DB.
"web application" could mean a number of things. To me "web app" in the comments above meant the code on a server that handles http requests, not the browser client of it. You are talking about Javascript running in the browser of a random internet user, right? It could be catastrophic to allow that level of access to a database from the public web, obviously.
As is pointed out in (1) that can happen already through carelessness. And it does (2)
But it probably isn't what was intended in a newly designed general system. That would assume great stupidity.
I suspect that even the "no code, just access the database" actually has some kind of code and config in front of the db, like odata (3). I'm not saying that odata is great, but it is an example of trivial access to a database. it's gated, mostly read-only and configurable, but it probably doesn't count as "writing a custom server app to gate to a database"
1) https://news.ycombinator.com/item?id=11925043
Re: Serverless Architectures
#123There 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, Article author here. Don't worry, I'll be laying on some cold, hard, reality later in the series. I definitely don't encourage SPAs universally and I'll be talking extensively about the concerns of handing over responsibility to vendors.
I appreciate you not only explaining it but coming up with two, alternate terms that don't sound so dumb. As in, not calling a centralized architecture "serverless". Your names also fit within context of what people are calling other "N as a Service" schemes.
Re: Serverless Architectures
#124Earlier quoted context omitted.
If GAE has had "serverless" for most of a decade, then why did Google decide to create Google Cloud Functions? https://cloud.google.com/functions/docs/
Because Lambda/Cloud functions are meant for scripting tasks in your cloud environment, not for building full-fledged apps. (Lambdas couldn't even be triggered with HTTP calls when AWS Lambda launched.)
I spoke to a solutions architect on AWS who said that their recommendation for building a new backend service (eg. a REST API) is to use API gateway and Lambda. I definitely got the impression that he meant full-fledged apps.
Re: Serverless Architectures
#125[deleted]
Re: Serverless Architectures
#126It's just outsourcing. It "depends on 3rd party applications / services (‘in the cloud’)" It's like Salesforce's "No Software".
A real serverless architecture would be federated, like BitTorrent or Bitcoin.
Re: Serverless Architectures
#127How does this work with WebSockets? Like, a bit more than FaaS, but less than PaaS?
Raw WebSocket handling could be delegated to something like Pushpin [1] (disclaimer: author). This way, the backend doesn't have to maintain any long-lived connections of its own, but it retains a similar level of control over each connection that a full backend would have had. As an experiment, we built a chat app like this (using Stamplay as the FaaS) and it actually worked. [1] https://github.com/fanout/pushpin
Interesting. But I need my own server to run pushpin?
Re: Serverless Architectures
#128Earlier quoted context omitted.
Raw WebSocket handling could be delegated to something like Pushpin [1] (disclaimer: author). This way, the backend doesn't have to maintain any long-lived connections of its own, but it retains a similar level of control over each connection that a full backend would have had. As an experiment, we built a chat app like this (using Stamplay as the FaaS) and it actually worked. [1] https://github.com/fanout/pushpin
Interesting. But I need my own server to run pushpin?
That or you can use Fanout Cloud which provides Pushpin-as-a-service.
Re: Serverless Architectures
#129By this definition, we've been running "serverless" on Google App Engine for most of a decade. * We don't monitor how many instances are running and don't really care. Our "functions" are http endpoints. GAE spins up or down instances to meet the load. Our interface with "instances" is just the size of the bill at the end of the month. * Async task processing is also just an http endpoint function. We even have a lit…
Oh buzzwords... We've been discussing Google BigQuery as serverless lately. It's a nice succinct way of saying "fully-managed" + "no-ops" + "no resource deployment" + "seamless scaling" + "separation of storage and compute" + "deployed regionally" + etc. Some customers talk about BigQuery as "Data Center is the Database". So these buzzword help describe what BigQuery is and how it is different from other analytics se…
In the 1970s this was called the mainframe bureau...
Re: Serverless Architectures
#130It is misleading that the HN title suggests the author is Martin Fowler, but this is not the case for this guest article. The actual author is Mike Roberts, the article is hosted on Fowler's site.
Oh, I'll read it then - thanks! :-)