15 ms·

Am I the only one that thinks severless is about creating a bunch of vendor locked-in technical debt?

unreal37 8y ago
The increase in CPU utilization efficiency (and lower costs) is decreased by lack of portability. Everything has a cost. And so being able to move your code around at will is the cost of saving money.
- WrtCdEvrydy 8y ago
  Actually, most modern FaaS based on Amazon's is portable, it's the other rest of the stack that isn't very portable.
2StepsOutOfLine 8y ago
I would say that broadly categorizing FaaS as vendor lock-in would be disingenuous on its own. Practical FaaS is a simple concept as far as developer implementation is concerned. Write functions, get HTTP context, and return a result. This article really only touches on problems with vendor implementation of FaaS, AWS may have these issues with I/O and lifetime of a function, but there are many open source implementations that you could install on custom hardware that bypasses these issues. Even some of the issues that seem like fundamental issues with FaaS (non-addressable instances, unable to use specialized hardware) are already solved by other open source self-hosted FaaS solutions.
- DATACOMMANDER 8y ago
  Care to elaborate? Edit: to clarify, I’m referring to the assertion at the end of your comment, and I’m genuinely interested.
colllectorof 8y ago
You're not the only one. Some time ago I worked with a bunch of people who staked their careers on moving everything to AWS and converting it to serverless architecture. Here is just one example of how fishy it was. They used Dynamo. During presentations to the outgroup, they constatly praised Dynamo as being flexible, scalable and fast. However, internally they constantly struggled with various limitations of the database, from limitations of indexing to not being able to get certain types of metadata. My point is, the architecture they were designing was heavily bent around Dynamo's strength and weaknesses. Considering how extreme and peculiar those strength and weaknesses are, switching to another database would require heavy re-engineering of the rest of their architecture, much more so than, say, switching between Oracle, MS SQL and Postgress.
- scarface74 8y ago
  If you are actually taking advantage of all of the features of sql server or Oracle, you’re not just going to switch overnight. I’m no fan of DynamoDB and a multi certified AWS fan, but, I know it’s strengths and weaknesses and so should anyone else.
  - vhold 8y ago
    A product that actually uses all the features of Oracle would be naturally hilarious. Oracle's documentation is over 500 megabytes compressed. It's an alternative computing reality. Here is a 5559 page book of error codes. Imagine having a physical copy of this on your desk. https://docs.oracle.com/en/database/oracle/oracle-database/18/errmg/error-messages.pdf https://docs.oracle.com/en/database/oracle/oracle-database/1...
    - seibelj 8y ago
      Holy shit
      - StavrosK 8y ago
        This is exactly right, wow. I am almost speechless.
    - nickstefan12 8y ago
      > alternative computing reality This such the perfect description. I was working on a Django feature last year that had to work on all DBs and testing the oracle stuff was like entering a new reality lol.
    - FireBeyond 8y ago
      And full of such amazing utility, such as: " CLSRSC-00009: No value passed as OLR locations Cause: No value was passed as OLR locations. Action: None "
  - colllectorof 8y ago
    SQL Server and Oracle have different features and idiosyncrasies, but use the same fundamental models of data storage that is a product of decades of research and development and isn't controlled or promoted by a single company. You're not going to suddenly run into some fundamental limitation that will suddenly fuck you over on architectural level. This happens all the time with databases like Dynamo. All of them feel amazing when you use them in the "intended" way, but they also have extreme limitations and those limitations are different for every product. Why? Because they aren't based on some fundamental data storage model, but rather on an aggregation of specific use cases, which are different across different products. Here is a mild practical example: https://blog.codebarrel.io/why-we-switched-from-dynamodb-back-to-rds-before-we-even-released-3c2ee092120c https://blog.codebarrel.io/why-we-switched-from-dynamodb-bac...
yxhuvud 8y ago
No, it is also about writing fancy stuff in your CV.
perennate 8y ago
You're not the only one, the paper mentions this too :) > As a result, serverless computing today is at best a simple and powerful way to run embarrassingly parallel computations or harness proprietary services. At worst, it can be viewed as a cynical effort to lock users into those services and lock out innovation
scarface74 8y ago
You’re always “locked into” your infrastructure. I shake my head when I see some bushy tailed developer using the repository pattern just in case the corporation decides to abandon their million dollar Oracle installation to go with Postgres. As far as being “locked in” because of serverless. With AWS the only thing you are doing code wise to make your code “serverless” is creating one function as an entry point that takes in two parameters - a JSON object and a lambda context. The only thing your handler should be doing is mapping the event to your domain objects and calling your back end code. I have a c# .Net Core project that can quite easily be deployed as both a lambda that is triggered by an SQS message or as a Windows service. In fact, my CodeBuild step that triggered by a git commit compiles it as both a zip file that is deployed to lambda and a Windows executable - yes you can build a Windows .Net Core executable on Linux and vice versa. People have a dream of making their implementation vendor neutral but wholesale migrations involving major infrastructure changes rarely happens. The risk of regressions is too high and the benefits too low.
- wstrange 8y ago
  Amazon made a pretty big deal of how they finally migrated off of Oracle to get away from their repressive licensing. Being locked in sucks when the vendor can extract monopoly rents. Maintaining a second source is a good business strategy.
  - opless 8y ago
    It's why the military tend to insist on it.
  - scarface74 8y ago
    Yes and Amazon built their own globally distributed infrastructure,DynamoDB and RedShift - a purposefully play on shifting from Oracle - a random company isn’t going to do that. And it took 10 plus years. Again a random company is not going to take on a ten year plan to move from Oracle.
  - StreamBright 8y ago
    Amazon has engineering teams that very few other companies have. Do you think a bank would be able to move out from Oracle like Amazon? I do not think so. Maybe they would be able to move to DB2 or SQLServer with the help of the other vendors, so trading a vendor lock in for an other.
imhoguy 8y ago
Proprietary FaaS is like Stored Procedures in proprietary DBMSes but in the Cloud.
sytse 8y ago
I agree that is a big risk of serverless. But it isn’t inherent to it. GitLab will have serverless on December 22 based on Knative and open source code. But the current state of the industry is that 95%+ of workloads are bound to a specific hyper cloud (AWS, Azure, GCP).
eikenberry 8y ago
I don't find it that concerning for a couple reasons. 1) Much serverless code will be vendor specific anyways. Anecdotally I'd say at least half of all serverless code I've written was to deal/work with vendor services. 2) You can easily write code to be platform independent with a thin wrapper for whichever serverless system you are currently using. This is pretty straightforward unless you are using vendor services, in which case you are locked in anyways due to that dependency.
pier25 8y ago
You can abstract your logic from the infrastructure with the Serverless framework and deploy on any provider. https://serverless.com/ https://serverless.com/
pweissbrod 8y ago
Vendor lock-in is a serious issue. But there is an upside. Say you're building a serverless API. Say you build it using pyhton flask or bottle. You can use a packaging framework such as Zappa such that it can be deployed to serverless hosting or it can run in uwsgi / nginx on a server. Id be delighted to see a universally adopted standard specification for serverless computing including management interfaces and platform compatibility. The sort of specification that competing Cloud providers could implement thus better empowering consumers like myself. I have faith it will come around eventually all of this is relatively new
- StreamBright 8y ago
  Is it though? I think the possibility to move to another solution is the way to deal with vendor lock in. Simple example, one of my clients wanted to move to AWS but they were super afraid of lock in. We had to create exit strategy for them with cost analysis and now they are happily using AWS services knowing they can move to GCP or something else for a certain amount of money.
  - pweissbrod 8y ago
    Glad to hear things worked out for your client. The key thing is, YOU had to create an exit strategy just for your client. If the specifications for the serverless platform were "open" then the client could move their stack to different vendor with insignificant planning/risk. An analogy would be vendors somehow changing machine virtualization such that your code was required to be very hypervisor-aware to function, and porting from vmware to xen imposed significant cost and risk.
    - StreamBright 8y ago
      I am not sure how much of this is not already mitigated with https://serverless.com https://serverless.com. I have never used Lambda without it. For me serverless.com is the solution to avoid vendor lock in. However, Lambda is a tiny fraction of the entire stack we are talking about here. S3 + EMR + ALB + EC2 are all there and they are much more difficult to dodge the vendor lock in bullet with. One particularly sticky vendor lock in for S3 is pricing and reliability. Unfortunately it is almost impossible to beat that. My clients just discovered this, it would be significantly more expensive to move from S3 to HDFS or any other storage solution. This has nothing to do with how open the platform is, yet it is a much more serious lock in.
usaar333 8y ago
Lock in is a massive problem with FAAS, but it certainly isn't about lock-in [1]. It's all about reduction of developer ops - not having to provision (or even scale) servers is quite nice. [1] In fact, for FAAS start-ups (such as my own - PiCloud), the lock-in fear was one of the biggest hurdles.
DATACOMMANDER 8y ago
Uber-nitpick, but I’m pretty sure that you meant to suggest that serverless appears to be about creating vendor lock-in, not about creating “vendor locked-in” technical debt. While technical debt can take the form of vendor lock-in, the two concepts are otherwise unrelated, and they’re both fairly well defined. I can imagine the public cloud providers wanting to create vendor lock-in, but I don’t see why they’d care if doing so creates technical debt for their customers. I say this based on the accepted definition of technical debt, and again, this is a huge nitpick.

The increase in CPU utilization efficiency (and lower costs) is decreased by lack of portability. Everything has a cost. And so being able to move your code around at will is the cost of saving money.

WrtCdEvrydy 8y ago
Actually, most modern FaaS based on Amazon's is portable, it's the other rest of the stack that isn't very portable.

2StepsOutOfLine 8y ago

I would say that broadly categorizing FaaS as vendor lock-in would be disingenuous on its own. Practical FaaS is a simple concept as far as developer implementation is concerned. Write functions, get HTTP context, and return a result. This article really only touches on problems with vendor implementation of FaaS, AWS may have these issues with I/O and lifetime of a function, but there are many open source implementations that you could install on custom hardware that bypasses these issues. Even some of the issues that seem like fundamental issues with FaaS (non-addressable instances, unable to use specialized hardware) are already solved by other open source self-hosted FaaS solutions.

DATACOMMANDER 8y ago
Care to elaborate? Edit: to clarify, I’m referring to the assertion at the end of your comment, and I’m genuinely interested.

colllectorof 8y ago

You're not the only one. Some time ago I worked with a bunch of people who staked their careers on moving everything to AWS and converting it to serverless architecture. Here is just one example of how fishy it was. They used Dynamo. During presentations to the outgroup, they constatly praised Dynamo as being flexible, scalable and fast. However, internally they constantly struggled with various limitations of the database, from limitations of indexing to not being able to get certain types of metadata. My point is, the architecture they were designing was heavily bent around Dynamo's strength and weaknesses. Considering how extreme and peculiar those strength and weaknesses are, switching to another database would require heavy re-engineering of the rest of their architecture, much more so than, say, switching between Oracle, MS SQL and Postgress.

scarface74 8y ago
If you are actually taking advantage of all of the features of sql server or Oracle, you’re not just going to switch overnight. I’m no fan of DynamoDB and a multi certified AWS fan, but, I know it’s strengths and weaknesses and so should anyone else.
- vhold 8y ago
  A product that actually uses all the features of Oracle would be naturally hilarious. Oracle's documentation is over 500 megabytes compressed. It's an alternative computing reality. Here is a 5559 page book of error codes. Imagine having a physical copy of this on your desk. https://docs.oracle.com/en/database/oracle/oracle-database/18/errmg/error-messages.pdf https://docs.oracle.com/en/database/oracle/oracle-database/1...
  - seibelj 8y ago
    Holy shit
    - StavrosK 8y ago
      This is exactly right, wow. I am almost speechless.
  - nickstefan12 8y ago
    > alternative computing reality This such the perfect description. I was working on a Django feature last year that had to work on all DBs and testing the oracle stuff was like entering a new reality lol.
  - FireBeyond 8y ago
    And full of such amazing utility, such as: " CLSRSC-00009: No value passed as OLR locations Cause: No value was passed as OLR locations. Action: None "
- colllectorof 8y ago
  SQL Server and Oracle have different features and idiosyncrasies, but use the same fundamental models of data storage that is a product of decades of research and development and isn't controlled or promoted by a single company. You're not going to suddenly run into some fundamental limitation that will suddenly fuck you over on architectural level. This happens all the time with databases like Dynamo. All of them feel amazing when you use them in the "intended" way, but they also have extreme limitations and those limitations are different for every product. Why? Because they aren't based on some fundamental data storage model, but rather on an aggregation of specific use cases, which are different across different products. Here is a mild practical example: https://blog.codebarrel.io/why-we-switched-from-dynamodb-back-to-rds-before-we-even-released-3c2ee092120c https://blog.codebarrel.io/why-we-switched-from-dynamodb-bac...

yxhuvud 8y ago

No, it is also about writing fancy stuff in your CV.

perennate 8y ago

You're not the only one, the paper mentions this too :) > As a result, serverless computing today is at best a simple and powerful way to run embarrassingly parallel computations or harness proprietary services. At worst, it can be viewed as a cynical effort to lock users into those services and lock out innovation

scarface74 8y ago

You’re always “locked into” your infrastructure. I shake my head when I see some bushy tailed developer using the repository pattern just in case the corporation decides to abandon their million dollar Oracle installation to go with Postgres. As far as being “locked in” because of serverless. With AWS the only thing you are doing code wise to make your code “serverless” is creating one function as an entry point that takes in two parameters - a JSON object and a lambda context. The only thing your handler should be doing is mapping the event to your domain objects and calling your back end code. I have a c# .Net Core project that can quite easily be deployed as both a lambda that is triggered by an SQS message or as a Windows service. In fact, my CodeBuild step that triggered by a git commit compiles it as both a zip file that is deployed to lambda and a Windows executable - yes you can build a Windows .Net Core executable on Linux and vice versa. People have a dream of making their implementation vendor neutral but wholesale migrations involving major infrastructure changes rarely happens. The risk of regressions is too high and the benefits too low.

wstrange 8y ago
Amazon made a pretty big deal of how they finally migrated off of Oracle to get away from their repressive licensing. Being locked in sucks when the vendor can extract monopoly rents. Maintaining a second source is a good business strategy.
- opless 8y ago
  It's why the military tend to insist on it.
- scarface74 8y ago
  Yes and Amazon built their own globally distributed infrastructure,DynamoDB and RedShift - a purposefully play on shifting from Oracle - a random company isn’t going to do that. And it took 10 plus years. Again a random company is not going to take on a ten year plan to move from Oracle.
- StreamBright 8y ago
  Amazon has engineering teams that very few other companies have. Do you think a bank would be able to move out from Oracle like Amazon? I do not think so. Maybe they would be able to move to DB2 or SQLServer with the help of the other vendors, so trading a vendor lock in for an other.

imhoguy 8y ago

Proprietary FaaS is like Stored Procedures in proprietary DBMSes but in the Cloud.

sytse 8y ago

I agree that is a big risk of serverless. But it isn’t inherent to it. GitLab will have serverless on December 22 based on Knative and open source code. But the current state of the industry is that 95%+ of workloads are bound to a specific hyper cloud (AWS, Azure, GCP).

eikenberry 8y ago

I don't find it that concerning for a couple reasons. 1) Much serverless code will be vendor specific anyways. Anecdotally I'd say at least half of all serverless code I've written was to deal/work with vendor services. 2) You can easily write code to be platform independent with a thin wrapper for whichever serverless system you are currently using. This is pretty straightforward unless you are using vendor services, in which case you are locked in anyways due to that dependency.

pier25 8y ago

You can abstract your logic from the infrastructure with the Serverless framework and deploy on any provider. https://serverless.com/ https://serverless.com/

pweissbrod 8y ago

Vendor lock-in is a serious issue. But there is an upside. Say you're building a serverless API. Say you build it using pyhton flask or bottle. You can use a packaging framework such as Zappa such that it can be deployed to serverless hosting or it can run in uwsgi / nginx on a server. Id be delighted to see a universally adopted standard specification for serverless computing including management interfaces and platform compatibility. The sort of specification that competing Cloud providers could implement thus better empowering consumers like myself. I have faith it will come around eventually all of this is relatively new

StreamBright 8y ago
Is it though? I think the possibility to move to another solution is the way to deal with vendor lock in. Simple example, one of my clients wanted to move to AWS but they were super afraid of lock in. We had to create exit strategy for them with cost analysis and now they are happily using AWS services knowing they can move to GCP or something else for a certain amount of money.
- pweissbrod 8y ago
  Glad to hear things worked out for your client. The key thing is, YOU had to create an exit strategy just for your client. If the specifications for the serverless platform were "open" then the client could move their stack to different vendor with insignificant planning/risk. An analogy would be vendors somehow changing machine virtualization such that your code was required to be very hypervisor-aware to function, and porting from vmware to xen imposed significant cost and risk.
  - StreamBright 8y ago
    I am not sure how much of this is not already mitigated with https://serverless.com https://serverless.com. I have never used Lambda without it. For me serverless.com is the solution to avoid vendor lock in. However, Lambda is a tiny fraction of the entire stack we are talking about here. S3 + EMR + ALB + EC2 are all there and they are much more difficult to dodge the vendor lock in bullet with. One particularly sticky vendor lock in for S3 is pricing and reliability. Unfortunately it is almost impossible to beat that. My clients just discovered this, it would be significantly more expensive to move from S3 to HDFS or any other storage solution. This has nothing to do with how open the platform is, yet it is a much more serious lock in.

usaar333 8y ago

Lock in is a massive problem with FAAS, but it certainly isn't about lock-in [1]. It's all about reduction of developer ops - not having to provision (or even scale) servers is quite nice. [1] In fact, for FAAS start-ups (such as my own - PiCloud), the lock-in fear was one of the biggest hurdles.

DATACOMMANDER 8y ago

Uber-nitpick, but I’m pretty sure that you meant to suggest that serverless appears to be about creating vendor lock-in, not about creating “vendor locked-in” technical debt. While technical debt can take the form of vendor lock-in, the two concepts are otherwise unrelated, and they’re both fairly well defined. I can imagine the public cloud providers wanting to create vendor lock-in, but I don’t see why they’d care if doing so creates technical debt for their customers. I say this based on the accepted definition of technical debt, and again, this is a huge nitpick.