Live data from Hacker News

Serverless Architectures

martinfowler.com

71–80 of 149 posts

Re: Serverless Architectures

#71
post #10

Earlier quoted context omitted.

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

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.

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?

Re: Serverless Architectures

#72

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…

"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."

You mean sort of like every web page that uses javascript?

I agree, that is alarming. Unfortunately, the horse on that has long ago run out of that stable, and most people don't seeem to care.

Re: Serverless Architectures

#73
The serverless architecture appears to have many servers provided by different people instead of having no servers, as "serverless" leads me to think. Is this just trading wrangling a server farm for wrangling contracts with 3rd party service providers?

Am I missing something?

Re: Serverless Architectures

#74

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 :)

Thanks for taking a look. :)

Re: Serverless Architectures

#76

Earlier quoted context omitted.

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…

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

Re: Serverless Architectures

#77
By 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 little bit of syntactic sugar so it looks like we're just adding functions to a queue.

* We have no ops or devops staff. We just deploy code that implements functions (http endpoints).

* Persistence is also scaled by Google; there's no database server, just an API to read/write data that scales infinitely (or at least, scales with linearly our bill, not limited by the dataset).

It sounds to me like the article is trying to distinguish between "serverless" and PaaS by describing PaaS done poorly. For the longest time, GAE didn't even expose the # of instances servicing your app. They've exposed a lot more of the underlying constructs since, but you can still ignore them unless you're trying to hyperoptimize your bill.

Re: Serverless Architectures

#79

The serverless architecture appears to have many servers provided by different people instead of having no servers, as "serverless" leads me to think. Is this just trading wrangling a server farm for wrangling contracts with 3rd party service providers? Am I missing something?

Serverless is just a buzzword similar to NoSQL to gain traction, nothing new!

Re: Serverless Architectures

#80

http://martinfowler.com/articles/serverless/sps.svg Is there something wrong that the client browser is connecting directly to the database, so JS -> MySQL direct connection won't expose credentials ?

It doesn't say "MySQL database".

The client could conceivably connect to something like an ElasticSearch database (JSON API), setup with no auth/read-only permissions and appropriate rate-limiting.

Post reply on HN