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.
Serverless Architectures
71–80 of 149 posts
Re: Serverless Architectures
#72There 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…
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
#73Am I missing something?
Re: Serverless Architectures
#74There 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
#75Re: Serverless Architectures
#76Earlier 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…
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* 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
#78Is there something wrong that the client browser is connecting directly to the database, so JS -> MySQL direct connection won't expose credentials ?
Re: Serverless Architectures
#79The 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
#80http://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 ?
The client could conceivably connect to something like an ElasticSearch database (JSON API), setup with no auth/read-only permissions and appropriate rate-limiting.