Earlier quoted context omitted.
That isn't what DoA means. "DoA" doesn't care for whether an individual can use it, it cares for the collective. I'm sure Stallman couldn't use the iphone when it came out because of constraints, that doesn't mean the iphone ever was DoA.
I can't speak for the collective. As far as I'm concerned the current offers of BaaS are dead on arrival. Time will tell. I could see some value in the iPhone but I don't see much value in the current BaaS offers. Not enough to switch from the current alternatives. They are not transformative like the iPhone was. To complete your analogy we had smart phones before just like we have various BaaS services now.
Serverless Architectures
111–120 of 215 posts
Re: Serverless Architectures
#112One of the bigger problems with serverless architecture (beyond catastrophic lack of good debugging and development tools) is the idea of managing multiple users, working on multiple code branches, and all needing environments that somewhat closely mirror production. This leaves servless as a decent way to hook an event callback to some AWS event (new file uploaded to S3, etc) but IMHO not anything that approximates…
Re: Serverless Architectures
#113There's a big difference between Paas, where you hand over control of your backend. Compared to Faas, where you just outsource a small part of your infrastructure. FaaS solutions like algolia, getsentry, getstream.io. mapbox, layer, keen.io, twilio, stripe etc only run a small part of your application. They scale well, are more reliable and often more cost-effective than an in-house solution. If you're ever not happy…
Re: Serverless Architectures
#114Earlier quoted context omitted.
> they could have just as well not be That's a weird logical leap. Let's make the servers not be by unplugging them. How's the abstraction working now?
I think you're misunderstanding. I read it as "they could just as well not be servers". It could be Diamond Age rod logic. It could be processing implemented on quantum foam. It could be gnomes. The point is that from the user's perspective, they no longer have to think about servers.
The whole idea of a server is to abstract away the details of the upstream computer and its software stack, so the user can think of it only as a provider of an abstract service. The irrelevance of their implementation as a host, VM, box, rack of boxes, pool of quantum foam, string and sparkles, is already built into the concept.
We all know that there's no unique process that is http://amazon.com. It's a service, provided by a (vast distributed) server.
Re: Serverless Architectures
#115Aren't 'serverless' PAASs just a reinvention of PHP hosting?
I see similar parallels, but where as PHP shared hosting often meant one server handling multiple sites upon request, FaaS seems to be more generic with multiple (virtual) server instances handling multiple site functions upon request. So while each site was a PHP monolith on shared hosting, a FaaS architecture could be many smaller units of code, spun up on demand to handle a specific need of a service, possibly acr…
Re: Serverless Architectures
#116Earlier quoted context omitted.
You may be misunderstanding the concept of Lockin. It says you are stuck with whichever vendor you used that created the lockin. Benefits of services always seem to increase. So, whatever benefits exist for a current service isn't worth forgoing all potential benefits of all future competitors. That's what lock-in creates. That's why it's always bad for anything meant long-term. Now, short-term projects that can disa…
I still see this as flawed. Avoiding all vendor lock-in means making every possible piece of software you write completely generic - no GIS from Postgres, no third-party queue/messaging servers/services - none of it. We're "locked in" to AWS - in that it would take a massive effort to move to Google/bare metal, despite not using any AWS-written servers (that is, we're FreeBSD, MySQL, Redis, etc.). But the benefits of…
If you feel locked in, you lift-and-shift your serverless logic to a new platform. Write some shims and wrappers. It ain't that goddamn hard.
Re: Serverless Architectures
#117Here is a case study: Last year I was working on an SMS app, QKSMS [1]. We offered a premium version for $2. We did a promotion on reddit where we gave away 10k free premium versions. So, take a second and ask yourself: how quickly do you think you could implement a promo code system + a website for distributing codes for one time use?
We did it in about 5 hours. It costed about $100. The website was (and still is) statically hosted on Github. [2] The website source code is ~22 lines of JavaScript. It pulled 12 promo codes from Firebase; and when a promo code was removed, it would (in realtime!) collapse it from the list and display a new promo code at the bottom.
The mobile app code was also very simple. First, check if the promo code is available (one API call); if so, enable premium and remove the code (another API call).
The reason why it costed about $100 is because we had too many concurrent users: the Firebase free plan allows only 50 concurrent users, and at our peak we were seeing ~500. Since the promo was only for a day, we bought an expensive plan that got pro-rated for just that day.
It was an extremely successful promotion. [3] The final result was very interactive. It was amazing to watch the codes disappear in real-time. It was like a game: you had to be fast to enter the code, because the codes were being used so quickly.
All in all, I believe we made more money in people buying it anyways (despite the promotion) than it costed to serve it. And keep in mind we built the entire system in about 5 hours. And I'm not even a web developer. An actual web developer could have implemented this in an hour or two.
For reference here is the entire JavaScript powering the promo code website:
var all_codes = new Firebase("https://qksms-promo.firebaseio.com/public_codes");
all_codes.on('value', function(data){
$('#remaining').text(data.numChildren());
if (data.numChildren() === 0) {
$('#status').text('No more codes!');
}
})
all_codes.orderByValue().limitToFirst(12).on('child_added', function(data){
$('#status').remove();
var str = '');
str = str.concat(data.key());
str = str.concat('');
$('#wrapper').append(str);
$('#'.concat(data.key())).hide().fadeIn(300);
});
all_codes.orderByValue().limitToFirst(12).on('child_removed', function(data){
$('#'.concat(data.key())).slideUp(300, function(){
$(this).remove();
});
});
[1] https://github.com/moezbhatti/qksms[2] http://qklabs.com/qksms-promo/
[3] https://www.reddit.com/r/Android/comments/36eix7/dev_a_year_...
Re: Serverless Architectures
#118Earlier quoted context omitted.
You may be misunderstanding the concept of Lockin. It says you are stuck with whichever vendor you used that created the lockin. Benefits of services always seem to increase. So, whatever benefits exist for a current service isn't worth forgoing all potential benefits of all future competitors. That's what lock-in creates. That's why it's always bad for anything meant long-term. Now, short-term projects that can disa…
I still see this as flawed. Avoiding all vendor lock-in means making every possible piece of software you write completely generic - no GIS from Postgres, no third-party queue/messaging servers/services - none of it. We're "locked in" to AWS - in that it would take a massive effort to move to Google/bare metal, despite not using any AWS-written servers (that is, we're FreeBSD, MySQL, Redis, etc.). But the benefits of…
Any kind of practice without such setup means you've decided to let the vendor control your situation ftom that point onward. Historically, from mainframes to servers yo desktop to mobile, this always led to less brnefits overtime where new, better stuff emerged that locked-in customers couldnt use at all or benefit as much as they liked. Those that avoided lockin could. Worse, some locked-in got hit with price hikes or even EOL'd products.
So, I think the default should be justifying a lock-in product rather than the other way around. Ive seen situations where it made sense. My comment mentioned one. It just rarely does esp today with so many cheap, flexible, and so on alternatives to commercial lock-ins.
Re: Serverless Architectures
#119Earlier quoted context omitted.
No, the idea is simple - the servers are invisible to the user, he doesn't know what or how many are in use. Since the servers are completely abstracted away, they could have just as well not be - hence serverless. An analogy escapes me but I sure there are some.
So it is about how the user perceives the application?! If so, why is it called "an architecture"? Or do you mean that the user don't have to care on how to configure the application? Then "Zero-configuration" is a better name. Or do you mean that the application hides that it use services on the net? Then it is even worse.
The user here is the developer. Here's an explanation from the article:
> "some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party ... One way to think of this is Functions as a Service."
FaaS is probably a better name.
Re: Serverless Architectures
#120Earlier quoted context omitted.
I still see this as flawed. Avoiding all vendor lock-in means making every possible piece of software you write completely generic - no GIS from Postgres, no third-party queue/messaging servers/services - none of it. We're "locked in" to AWS - in that it would take a massive effort to move to Google/bare metal, despite not using any AWS-written servers (that is, we're FreeBSD, MySQL, Redis, etc.). But the benefits of…
Getting locked into free software like PostgreSQL is a lot less risky than getting locked into a proprietary system whose owner could gouge you or evict you at your most vulnerable moment.
Not theoretical: Microsoft, Borland, IBM, HP, Oracle/Sun... all did it at least once with Microsoft doing it many times. They're not open, which drives up the cost of exiting dramatically.