31–40 of 215 posts
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.
Aren't 'serverless' PAASs just a reinvention of PHP hosting?
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 across multiple servers.
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…
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.
If you can't use some obscure hipster language, that might be a problem. But my biggest gripe at the moment is lack of Ruby, and I'm sure Amazon will fix that.
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.
I like to think that vendor lockin is something I care greatly about, for the correct reasons. In the case of AWS Lambda however, it doesn't apply. Serverless architecture isn't a "lockin" problem. You don't develop your app with serverless in mind, thinking that you might some day go back to serverful. Serverless is a core design of (some parts of) your app. When I hear people say they're trying to "be generic", "ab…
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.
The difference is one doesn't have access to Lambda infrastructure itself. IF I write an entire app in XYZ lang, I can still run it on my own server or make it an executable and call the code through RPC. If I base all my work on a third party vendor infrastructure I can't replicate it requires an even more massive effort to migrate to something else, because now I basically have to re-write my app from scratch. FAAS may have killed BAAS but isn't going to kill PAAS.
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.
Well, the point is that the benefits don't outweigh the drawbacks because of the vendor lock-in. Whenever you hit a limitation there is NOTHING you can do. No duct tape! Also on long term the vendor roadmap may not align with your business(i.e. pricing, features etc). Do you have a migration roadmap? Of course you don't... you are already too busy dealing with the BaaS restrictions/APIs. Definitely BaaS have their pl…
I'm cautiously optimistic that the vendor lock-in will fade away over time. Hopefully open source frameworks can provide a jQuery-like abstraction layer over all of the vendor-specific implementation details. Of course, there are lots of challenges when you start getting into deeper architectures - queues triggering layers of lambdas interacting with various caches and data stores. But I we'll see best practices emer…
I actually think the opposite. Serverless architectures are the future for most of the app servers that need a language agnostic API. Maybe I didn't get it right but to me BaaS is just a PaaS with a common API interface(i.e. authentication, input/output serialization, cache etc).
Aren't 'serverless' PAASs just a reinvention of PHP hosting?
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.
For the most part, Lambda code is just normal JavaScript/Python. It would take fairly minimal effort to take that code and package it up to deploy on a normal (non-Lambda) server.