41–50 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.
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.
Shouldn't serVER architectures be/get easy enough that the flexibility/transferability far outweighs whatever the BaaS's are providing? Is it really that hard to run a server in this day-in-age?
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 with them it's easy to switch to an alternative. If Algolia no longer works for you, simply switch to Elastic. If you're not happy with Mapbox, use google maps. No longer like, getstream.io, use Stream-Framework. It's relatively easy to change since you're not handing over your entire backend.
Also see my post on HighScalability about this: http://highscalability.com/blog/2014/12/22/scalability-as-a-...
Earlier quoted context omitted.
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…
Parent post didn't say anything about abstracting away "serverless". Lock-in refers to (as the OP article discusses) the fact that if you use AWS Lambda, you are tied to their APIs and deploy mechanisms. If you want to move to Google's FaaS offering, you have a lot of work to do, and may need to restructure your app logic as well.
You provide an entry point to your application. AWS provides you with an `event` and `context` object, both of which are nonstandard. You extract, out of those objects, the data you care about... and you pass it down to whatever it is you want to run.
The extraction is very simple. Here, take a look at a SNS-triggered lambda:
https://github.com/HearthSim/HSReplay.net/blob/e12a6b8217b3b...
One line of code is vendor-specific. I could move to a different vendor in a heartbeat. Yes, bits and pieces are using SNS/S3; some of which are already abstracted away, the rest which can be easily replaced.
And frankly, when dealing with platforms as large as AWS, the vendor you choose is a big deal. You're not supposed to change every week... so it doesn't matter if it takes a little cleanup to move to another vendor. If it's taking you more than a few hours, your code is making assumptions it shouldn't about the underlying architecture and that's your fault, not amazon's.
Its an architecture that relies on multiple, supposedly distributed services, all of which are hosted on servers...
Why not just call it "Multiserver" instead.
If they mean "containerless servers" or "microservices", then why don't they say so?
If they mean "distributed servers" why not call it that.
If they mean that the client relies on multiple services (each hosted on different servers) why not just call it a thick/fat/stateful client?
Even a database is a remote service (if not embedded), that is run on some sort of server.
Calling anything serverless is just ridiculous as long as it depends on services on the network.
This smells really bad of just another attempt at marketing a pointless definition just to get more business.
If successful this could lead reduction in developers needed in companies that use say AWS lambda.
What a ridiculous and strange definition this is. Its an architecture that relies on multiple, supposedly distributed services, all of which are hosted on servers... Why not just call it "Multiserver" instead. If they mean "containerless servers" or "microservices", then why don't they say so? If they mean "distributed servers" why not call it that. If they mean that the client relies on multiple services (each hoste…
What a ridiculous and strange definition this is. Its an architecture that relies on multiple, supposedly distributed services, all of which are hosted on servers... Why not just call it "Multiserver" instead. If they mean "containerless servers" or "microservices", then why don't they say so? If they mean "distributed servers" why not call it that. If they mean that the client relies on multiple services (each hoste…
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.
Earlier quoted context omitted.
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…
For you. At the moment. "Dead on arrival" has a meaning, and this isn't it.
I remember this movie the first time around, when it was called "virtual hosting". What a revolution -- transitioning from needing a Unix box running Apache to run your PHP e-commerce site to having your host take care of that for you -- and everybody else.
Just because you're doing something old "in the cloud" now doesn't make it a new thing. Just like you can't append "...with a computer" to an existing method and get something patentable.