11–20 of 215 posts
If successful this could lead reduction in developers needed in companies that use say AWS lambda.
How so ? to me it makes development even more complicated, cheaper relative to hosting fees maybe, but simpler ? I don't think so. What if I want to use language XYZ not supported by lambda ?
The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
This is not a concern if the platform is open-source (like RethinkDB's Horizon) and you can choose to self-host.
Edit: I'm not very familiar with Horizon. It looks promising but I assume it's tightly coupled with RethinkDB?
Earlier quoted context omitted.
You can't evaluate a technology by looking at drawbacks alone, you have to consider the benefits as well, and whether they outweigh the drawbacks.
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…
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 AWS have been huge for us, and anyone saying they're outweighed by the potential downside has no idea what they're on about.
The right tool for the job is sometimes a vendor with specific services that, yes, sometimes have a lock-in component, even for long-term use.
In this specific case this particular BaaS implementation may not be full-cooked enough to entice you onto it, but saying vendor lock-in is bad as a blanket statement or incontrovertible truth is just silly.
The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.
Technology lock-in without vendor lock-in isn't that huge of a liability. A popular PL under an appropriate license isn't going to disappear tomorrow, and its creator doesn't have the power to hold your business at gunpoint. Conversely, B/FaaS providers upon which you truly depend definitely can extract (or by disappearing simply destroy) much more value than you originally anticipate.
[1] If you use Wolfram Language or Matlab then your choice of PL causes vendor lock-in, but most PLs aren't like this.
Earlier 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 successful this could lead reduction in developers needed in companies that use say AWS lambda.
> If successful this could lead reduction in developers needed in companies that use say AWS lambda. How so ? to me it makes development even more complicated, cheaper relative to hosting fees maybe, but simpler ? I don't think so. What if I want to use language XYZ not supported by lambda ?
Has anyone gone through https://pragprog.com/book/brapps/serverless-single-page-apps?
The example material looks good. Overall it could be a bit short.