5 ms·

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.
        themihai 10y ago
        I didn't say there is a proprietary language. I just said that the current trend leeds to total lock-in. After BaaS,the programming language is the only open piece of your stack. I hope you can see the difference between licese per core and cloud services. The cloud vendor can render your code/business useless at any time. You control nothing on your stack. Some are comfortable with that but I don't think it's a good thing for the industry or society. Proprietary software is sometimes a necessary evil but it's not really the case with BaaS. At leat not in the current form.
  - themihai 10y ago
    Well that's my point! In this particular case(BaaS) the current implementation is not worth it due the lock in. The issue with the lock in is that you can't fix it yourself if it's broken. Maybe if it would be free and my project would be a toy I would consider it but as it is now it's not worth it. I also doubt you jumped on the AWS wagon on its day one. AWS has a wide range of services. With the right abstractions I think most of them can be easily replaced if you were to move to a different vendor or bare metal servers. BaaS is a totally different kind of animal. Did Beanstalk work well for you?
  - prodigal_erik 10y ago
    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.
    - nickpsecurity 10y ago
      Exactly. There's slmost no comparison given a proprietary company can straight-up tell you "No, we will no longer sell you the product even if you will pay big $$$ for it. " 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.
      - themihai 10y ago
        Google should be on that list too.
  - beat 10y ago
    Heck, I've done mainframe-to-unix porting. The concerns about "lock-in" raised here are silly and trivial. If you're writing serverless code, it's already stateless and inside a well-defined and well-documented box. The hard stuff, always, is the business logic. 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.
  - nickpsecurity 10y ago
    You can do AWS without lockin. You can do messaging without lockin. You can do Postgres without lockin. You just have a generic way of integrating it with your apps plus a backup option. Then, you can leave at any time with lower costs. 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.
- 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.

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.
      - themihai 10y ago
        I didn't say there is a proprietary language. I just said that the current trend leeds to total lock-in. After BaaS,the programming language is the only open piece of your stack. I hope you can see the difference between licese per core and cloud services. The cloud vendor can render your code/business useless at any time. You control nothing on your stack. Some are comfortable with that but I don't think it's a good thing for the industry or society. Proprietary software is sometimes a necessary evil but it's not really the case with BaaS. At leat not in the current form.
- themihai 10y ago
  Well that's my point! In this particular case(BaaS) the current implementation is not worth it due the lock in. The issue with the lock in is that you can't fix it yourself if it's broken. Maybe if it would be free and my project would be a toy I would consider it but as it is now it's not worth it. I also doubt you jumped on the AWS wagon on its day one. AWS has a wide range of services. With the right abstractions I think most of them can be easily replaced if you were to move to a different vendor or bare metal servers. BaaS is a totally different kind of animal. Did Beanstalk work well for you?
- prodigal_erik 10y ago
  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.
  - nickpsecurity 10y ago
    Exactly. There's slmost no comparison given a proprietary company can straight-up tell you "No, we will no longer sell you the product even if you will pay big $$$ for it. " 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.
    - themihai 10y ago
      Google should be on that list too.
- beat 10y ago
  Heck, I've done mainframe-to-unix porting. The concerns about "lock-in" raised here are silly and trivial. If you're writing serverless code, it's already stateless and inside a well-defined and well-documented box. The hard stuff, always, is the business logic. 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.
- nickpsecurity 10y ago
  You can do AWS without lockin. You can do messaging without lockin. You can do Postgres without lockin. You just have a generic way of integrating it with your apps plus a backup option. Then, you can leave at any time with lower costs. 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.
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.