9 ms·

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 langu

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.

Mizza 10y ago
I got burned by Parse on this already. One of the nice things about Zappa (https://github.com/Miserlou/Zappa https://github.com/Miserlou/Zappa) is that you can return to a non-serverless architecture if you want to.
mseebach 10y ago
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.
- nickpsecurity 10y ago
  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 disappear in a few years or less have less risk for lock-in. We still see those disrupted on occasion when the vendor abruptly disappears. Users had to redo their work, which wouldn't have been necessary in lock-in free approach.
  - themartorana 10y ago
    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 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.
    - idunno246 10y ago
      we use dynamodb heavily, among other services, and the lockin question always comes up. and its like, would you rather get to market a month earlier, or spend a month building something just in case one day it doesn't work - it seems like a no-brainer that lockin is often a cost to push off to later especially considering you may never have to pay it.
      - themihai 10y ago
        The question is how much are you willing to trade-off for the managed infrastructure benefits. The database is a level but BaaS is a totally different level. Next would be the programming language. Would you feel comfortable to base your project on a proprietary amazon programming language? (i.e See Apex of SalesForce). Maybe yes but I can't see this becoming mainstream anytime soon. It would be a backward step. I use some managed/proprietary services too but I always consider it a liability/short term workaround. Most of the AWS services were successful because they are based on open source/3rd party software (i.e. the OS, DB engine etc). BaaS changes totally changes that. It's all proprietary except the programming language which may not be one of your preferred one either. Google lost a lot of ground on cloud service because it promoted a proprietary platform(GAE). The concept was great but we can see how it played out. These are the reasons why I think the current BaaS offers are dead on arrival.
        krakensden 10y ago
        GAE is a great example of the lockin problem- they changed the pricing model, bills skyrocketed, and it was super hard to get out.
        beat 10y ago
        But it's not on a proprietary Amazon language! The three most common/dominant languages in the back end app development world are already covered. Why are you inventing a problem that doesn't even exist to complain about? For that matter, any number of proprietary languages have been successful over the years. If it solves a problem, and solves it better and faster than reinventing the wheel, most businesses will use it. Time-to-market is a much bigger deal than abstract concerns about future platform change. I've been in this industry for 20-odd years, and the only things I've seen last are Unix and SQL. Everything else is new since I started. I sometimes work with bleeding edge, and I'm not afraid.
  - Spooky23 10y ago
    Lock-in is fine if it has value.
    - nickpsecurity 10y ago
      People keep saying that without a context. Non-lock-in usually has value too. Many times for similar or lower cost. And with way less risk. So, the question instead is "With these requirements, which products and services meet them with good, cost-benefit analysis? And which is best when benefits and liabilities are considered?"
      - Spooky23 10y ago
        Everything is situational. Nobody is going out and buying an IBM Mainframe because of my comment. I have seen people waste precious time and energy on "open" solutions, and lose focus on other, important things. I'd rather be stuck extricating myself from some lousy vendor relationship than not selling my product.
- themihai 10y ago
  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 place along with PaaS, DBaaS and IaaS but if you are locked-in to a specific vendor your options become quite limited very quickly. Maybe when something like Docker for BaaS appears I would reconsider this. The BaaS is not really more than a framework with various constrains so there is nothing stopping you to implement your own BaaS on top of an existing PaaS(to avoid managing servers). I'm actually doing just this and it works well but I can see how Lambda or any other vendor offer would not work due the amount of customisation required.
  - mseebach 10y ago
    For you. At the moment. "Dead on arrival" has a meaning, and this isn't it.
    - themihai 10y ago
      Well if I can't use it now due the constrains mentioned above it is dead to me. Would you bet your project on Google functions[0]? [0] https://cloud.google.com/functions/docs/ https://cloud.google.com/functions/docs/
      - scrollaway 10y ago
        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.
        themihai 10y ago
        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.
- golemotron 10y ago
  > 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. For a particular use you certainly can. Some problems have hard constraints. Freedom from lockin is a common one.
nileshtrivedi 10y ago
This is not a concern if the platform is open-source (like RethinkDB's Horizon) and you can choose to self-host.
- themihai 10y ago
  RethinkDB doesn't seem to be a general purpose BaaS. I definitely don't think BaaS is a bad thing. It's just that the current flavours are not worth it. They are mostly some kind of MVPs. Edit: I'm not very familiar with Horizon. It looks promising but I assume it's tightly coupled with RethinkDB?
davidw 10y ago
Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.
- safeignorance 10y ago
  In almost all cases, there's a significant difference in the sort of risk that comes from B/FaaS dependencies and the sort of risk that comes from PL lock-in. The former leads to technology lock-in and vendor lock-in, while the latter almost never[1] leads to vendor lock-in. 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.
  - davidw 10y ago
    I agree - "vendor lock-in" seems like a valid point, although I don't know the details of many of these services. "Locked into a programming language" is something that will probably happen kind of naturally anyway.
- themihai 10y ago
  I don't follow. You can write other modules in different languages. The data sources are language agnostic. Nobody forces you to do use a specific programming language in the first place unless the platform is close sourced. The point is that with a close source BaaS you have no control on the tools or costs or availability(i.e. deprecation policy) of the service.
- nawitus 10y ago
  Locked in maybe, but not vendor locked in if the language is open source.
  - 10y ago
scrollaway 10y ago
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", "abstract away serverless architecture" or some such, I'm replacing "serverless" with "asynchronous", or "functional", and it sounds bloody ridiculous, because it is. If competitors to AWS lambda arise, I do hope they'll have a similar architecture available because that's where the power of Lambda resides. The "lock in" is only whatever those fake WSGI objects lambda is passing to the function are, as well as internal triggers for the servers (SNS, S3, ...). Those things can be abstracted away if competitors offer similar mechanism. Trying to abstract serverless+serverful together is ridiculous. If you're successfully doing this, it sounds like your app doesn't belong in a serverless environment in the first place. PS: There's plenty of drawbacks which are vendor-specific, not tied to the serverless design itself. For example, the Amazon API Gateway is atrociously bad. AWS Lambda doesn't even support Python 3, only Python 2.7 (get your shit together Amazon). Those are things I'd switch to a different vendor for in a heartbeat... if there was actual competition.
- theptip 10y ago
  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.
  - scrollaway 10y ago
    And that's wrong; a complete misunderstanding of how both serverless in general and Lambda specifically works. 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/e12a6b8217b3b691bc3617fcd3b0815900710bd7/hsreplaynet/lambdas/uploads.py#L87-L104 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.
jakub_h 10y ago
Then why not have standardized APIs? You could just switch implementations, then, if you stop liking your current vendor. (Or maybe the future lies in call-by-meaning architectures and automated adapter generation?)
- prodigal_erik 10y ago
  Someday a standardized API will become popular enough that AWS will need to support it, but they aren't going to do anything to hasten it.
beat 10y ago
The language lock-in issue seems to be mostly an issue with Lambda at the moment, and I suspect it will resolve itself over time. As it, even on Lambda you have the choice of JS, Python, and Java, which is a lot of flexibility. I expect we will see "official" Go, Ruby, JVM languages like Clojure and Scala, etc. 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.
morgante 10y ago
That's true for things like Parse, but much less true for Lambda. 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.
pbreit 10y ago
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?
- blowski 10y ago
  Depends what you're doing. If your code is simple but serving at scale is the problem (Twitter?) then I can see why this kind of architecture appeals.
toddmorey 10y ago
I completely disagree that it's DOA. In fact, I think it's clear that is the future of development. Like any piece of the software stack, there are providers focusing on services that are proprietary, open source, and a mixture of the two. I am personally most excited about the hosted open source providers, because it gives dev teams immediate access to the technology, but the option to bring it in house when and how it makes sense.
- themihai 10y ago
  I didn't say the technology is DOA. Just the current offers which seem locked in to specific vendor implementations. The current BaaS offers are too intrusive and just not good enough to worth the switch from a PaaS to a BaaS.
  - BraveNewCurency 10y ago
    > good enough To whom? I see many people who need a trivial amount of server logic. Right now, they can do one of 3 things: - Use a random site who may or may not radically change their business model in the new few years. - Pay $5/month for a VPS, then get forcibly dragged up the learning curve of becoming a full-time sysadmin - Pay pennies for Lambda Is there a reason to re-write your backend? No. Is there a reason to consider it on your next project? Possibly.
    - dragonwriter 10y ago
      > To whom? I see many people who need a trivial amount of server logic. Right now, they can do one of 3 things: Since any site "may or may not radially change their business model" at any time, you really only list two substantive options: (1) Use an VPS, or (2) Use Lambda But, really, there's a more choices: (1) Use a VPS or IaaS (with full sysadmin overhead), (2) Use a PaaS (like Google AppEngine) and avoid sysadmin overhead (but probably have more code than a "serverless" function host like Lambda), or (3) Use a "serverless" function host like Lambda You probably don't want to do #1, since for low-volume and trivial logic its (1) comparatively expensive, and (2) high sysadmin and programming overhead compared to the other options. #2 is lower overhead (particular on the sysadmin side), but still more than #3. But possibly cheaper (e.g., if the requirements fit within the free quotas for AppEngine.) #3 may be the best solution for some things, but its not as stark as a choice as you present it to be.
joeyspn 10y ago
(ahem) Serverless v1.0 is multi-cloud and multi-language... https://github.com/serverless/serverless/tree/v1.0 https://github.com/serverless/serverless/tree/v1.0
tcarey83 10y ago
Well for AWS Lambda, they offer three languages: Java, Javascript, and Python. Even then, its really just running in a container and you have access to anything in their standard Linux AMI and whatever else you include with your code, so you could really use almost any language you want. I'm using wkhtml2pdf with my Python code which is a c++ executable. Also, although the Python is 2.7, you can easily use the existing Python 3 environment or include your own. As far as lock in, it is trivial to utilize the same code on your own servers. I do that for my Python code for development using a simple Cherrypy setup in less than 100 lines of code.

Mizza 10y ago

I got burned by Parse on this already. One of the nice things about Zappa (https://github.com/Miserlou/Zappa https://github.com/Miserlou/Zappa) is that you can return to a non-serverless architecture if you want to.

mseebach 10y ago

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.

nickpsecurity 10y ago
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 disappear in a few years or less have less risk for lock-in. We still see those disrupted on occasion when the vendor abruptly disappears. Users had to redo their work, which wouldn't have been necessary in lock-in free approach.
- themartorana 10y ago
  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 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.
  - idunno246 10y ago
    we use dynamodb heavily, among other services, and the lockin question always comes up. and its like, would you rather get to market a month earlier, or spend a month building something just in case one day it doesn't work - it seems like a no-brainer that lockin is often a cost to push off to later especially considering you may never have to pay it.
    - themihai 10y ago
      The question is how much are you willing to trade-off for the managed infrastructure benefits. The database is a level but BaaS is a totally different level. Next would be the programming language. Would you feel comfortable to base your project on a proprietary amazon programming language? (i.e See Apex of SalesForce). Maybe yes but I can't see this becoming mainstream anytime soon. It would be a backward step. I use some managed/proprietary services too but I always consider it a liability/short term workaround. Most of the AWS services were successful because they are based on open source/3rd party software (i.e. the OS, DB engine etc). BaaS changes totally changes that. It's all proprietary except the programming language which may not be one of your preferred one either. Google lost a lot of ground on cloud service because it promoted a proprietary platform(GAE). The concept was great but we can see how it played out. These are the reasons why I think the current BaaS offers are dead on arrival.
      - krakensden 10y ago
        GAE is a great example of the lockin problem- they changed the pricing model, bills skyrocketed, and it was super hard to get out.
      - beat 10y ago
        But it's not on a proprietary Amazon language! The three most common/dominant languages in the back end app development world are already covered. Why are you inventing a problem that doesn't even exist to complain about? For that matter, any number of proprietary languages have been successful over the years. If it solves a problem, and solves it better and faster than reinventing the wheel, most businesses will use it. Time-to-market is a much bigger deal than abstract concerns about future platform change. I've been in this industry for 20-odd years, and the only things I've seen last are Unix and SQL. Everything else is new since I started. I sometimes work with bleeding edge, and I'm not afraid.
- Spooky23 10y ago
  Lock-in is fine if it has value.
  - nickpsecurity 10y ago
    People keep saying that without a context. Non-lock-in usually has value too. Many times for similar or lower cost. And with way less risk. So, the question instead is "With these requirements, which products and services meet them with good, cost-benefit analysis? And which is best when benefits and liabilities are considered?"
    - Spooky23 10y ago
      Everything is situational. Nobody is going out and buying an IBM Mainframe because of my comment. I have seen people waste precious time and energy on "open" solutions, and lose focus on other, important things. I'd rather be stuck extricating myself from some lousy vendor relationship than not selling my product.
themihai 10y ago
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 place along with PaaS, DBaaS and IaaS but if you are locked-in to a specific vendor your options become quite limited very quickly. Maybe when something like Docker for BaaS appears I would reconsider this. The BaaS is not really more than a framework with various constrains so there is nothing stopping you to implement your own BaaS on top of an existing PaaS(to avoid managing servers). I'm actually doing just this and it works well but I can see how Lambda or any other vendor offer would not work due the amount of customisation required.
- mseebach 10y ago
  For you. At the moment. "Dead on arrival" has a meaning, and this isn't it.
  - themihai 10y ago
    Well if I can't use it now due the constrains mentioned above it is dead to me. Would you bet your project on Google functions[0]? [0] https://cloud.google.com/functions/docs/ https://cloud.google.com/functions/docs/
    - scrollaway 10y ago
      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.
      - themihai 10y ago
        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.
golemotron 10y ago
> 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. For a particular use you certainly can. Some problems have hard constraints. Freedom from lockin is a common one.

nileshtrivedi 10y ago

This is not a concern if the platform is open-source (like RethinkDB's Horizon) and you can choose to self-host.

themihai 10y ago
RethinkDB doesn't seem to be a general purpose BaaS. I definitely don't think BaaS is a bad thing. It's just that the current flavours are not worth it. They are mostly some kind of MVPs. Edit: I'm not very familiar with Horizon. It looks promising but I assume it's tightly coupled with RethinkDB?

davidw 10y ago

Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.

safeignorance 10y ago
In almost all cases, there's a significant difference in the sort of risk that comes from B/FaaS dependencies and the sort of risk that comes from PL lock-in. The former leads to technology lock-in and vendor lock-in, while the latter almost never[1] leads to vendor lock-in. 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.
- davidw 10y ago
  I agree - "vendor lock-in" seems like a valid point, although I don't know the details of many of these services. "Locked into a programming language" is something that will probably happen kind of naturally anyway.
themihai 10y ago
I don't follow. You can write other modules in different languages. The data sources are language agnostic. Nobody forces you to do use a specific programming language in the first place unless the platform is close sourced. The point is that with a close source BaaS you have no control on the tools or costs or availability(i.e. deprecation policy) of the service.
nawitus 10y ago
Locked in maybe, but not vendor locked in if the language is open source.
- 10y ago

scrollaway 10y ago

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", "abstract away serverless architecture" or some such, I'm replacing "serverless" with "asynchronous", or "functional", and it sounds bloody ridiculous, because it is. If competitors to AWS lambda arise, I do hope they'll have a similar architecture available because that's where the power of Lambda resides. The "lock in" is only whatever those fake WSGI objects lambda is passing to the function are, as well as internal triggers for the servers (SNS, S3, ...). Those things can be abstracted away if competitors offer similar mechanism. Trying to abstract serverless+serverful together is ridiculous. If you're successfully doing this, it sounds like your app doesn't belong in a serverless environment in the first place. PS: There's plenty of drawbacks which are vendor-specific, not tied to the serverless design itself. For example, the Amazon API Gateway is atrociously bad. AWS Lambda doesn't even support Python 3, only Python 2.7 (get your shit together Amazon). Those are things I'd switch to a different vendor for in a heartbeat... if there was actual competition.

theptip 10y ago
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.
- scrollaway 10y ago
  And that's wrong; a complete misunderstanding of how both serverless in general and Lambda specifically works. 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/e12a6b8217b3b691bc3617fcd3b0815900710bd7/hsreplaynet/lambdas/uploads.py#L87-L104 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.

jakub_h 10y ago

Then why not have standardized APIs? You could just switch implementations, then, if you stop liking your current vendor. (Or maybe the future lies in call-by-meaning architectures and automated adapter generation?)

prodigal_erik 10y ago
Someday a standardized API will become popular enough that AWS will need to support it, but they aren't going to do anything to hasten it.

beat 10y ago

The language lock-in issue seems to be mostly an issue with Lambda at the moment, and I suspect it will resolve itself over time. As it, even on Lambda you have the choice of JS, Python, and Java, which is a lot of flexibility. I expect we will see "official" Go, Ruby, JVM languages like Clojure and Scala, etc. 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.

morgante 10y ago

That's true for things like Parse, but much less true for Lambda. 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.

pbreit 10y ago

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?

blowski 10y ago
Depends what you're doing. If your code is simple but serving at scale is the problem (Twitter?) then I can see why this kind of architecture appeals.

toddmorey 10y ago

I completely disagree that it's DOA. In fact, I think it's clear that is the future of development. Like any piece of the software stack, there are providers focusing on services that are proprietary, open source, and a mixture of the two. I am personally most excited about the hosted open source providers, because it gives dev teams immediate access to the technology, but the option to bring it in house when and how it makes sense.

themihai 10y ago
I didn't say the technology is DOA. Just the current offers which seem locked in to specific vendor implementations. The current BaaS offers are too intrusive and just not good enough to worth the switch from a PaaS to a BaaS.
- BraveNewCurency 10y ago
  > good enough To whom? I see many people who need a trivial amount of server logic. Right now, they can do one of 3 things: - Use a random site who may or may not radically change their business model in the new few years. - Pay $5/month for a VPS, then get forcibly dragged up the learning curve of becoming a full-time sysadmin - Pay pennies for Lambda Is there a reason to re-write your backend? No. Is there a reason to consider it on your next project? Possibly.
  - dragonwriter 10y ago
    > To whom? I see many people who need a trivial amount of server logic. Right now, they can do one of 3 things: Since any site "may or may not radially change their business model" at any time, you really only list two substantive options: (1) Use an VPS, or (2) Use Lambda But, really, there's a more choices: (1) Use a VPS or IaaS (with full sysadmin overhead), (2) Use a PaaS (like Google AppEngine) and avoid sysadmin overhead (but probably have more code than a "serverless" function host like Lambda), or (3) Use a "serverless" function host like Lambda You probably don't want to do #1, since for low-volume and trivial logic its (1) comparatively expensive, and (2) high sysadmin and programming overhead compared to the other options. #2 is lower overhead (particular on the sysadmin side), but still more than #3. But possibly cheaper (e.g., if the requirements fit within the free quotas for AppEngine.) #3 may be the best solution for some things, but its not as stark as a choice as you present it to be.

joeyspn 10y ago

(ahem) Serverless v1.0 is multi-cloud and multi-language... https://github.com/serverless/serverless/tree/v1.0 https://github.com/serverless/serverless/tree/v1.0

tcarey83 10y ago

Well for AWS Lambda, they offer three languages: Java, Javascript, and Python. Even then, its really just running in a container and you have access to anything in their standard Linux AMI and whatever else you include with your code, so you could really use almost any language you want. I'm using wkhtml2pdf with my Python code which is a c++ executable. Also, although the Python is 2.7, you can easily use the existing Python 3 environment or include your own. As far as lock in, it is trivial to utilize the same code on your own servers. I do that for my Python code for development using a simple Cherrypy setup in less than 100 lines of code.