4 ms·

There is no lock-in... you can write an agnostic function for both AWS lambda and azure function.

benatkin 9y ago
I'm aware of tools like Serverless. They help remove the lock-in in some situations. That doesn't mean there's no lock-in to speak of at all.
- philliphaydon 9y ago
  In regards to C# functions, there is no lock-in to AWS, it's a piece of code, you can run that function on AWS Lambda, or in ASP.NET Website, or Azure Function, or console app... It's literally a method which has a single parameter class, and a single class returned... Even if you're using node, java, golang, python. Other than the packaging. How is there any lock in?
  - hueving 9y ago
    Aren't you spending resources setting up your CI/CD pipeline /deployment tooling to talk to Amazon's APIs? Unless all of the providers have the same API to deploy functions, they are all trying to lock you in. So not lock-in at the code level (unless your serverless app talks to S3 or whatever Amazon services), but lock-in of your whole devops process.
    - philliphaydon 9y ago
      So first it's all "Oh you're locked into IIS" and "You're locked into Windows", then "You're locked into AWS" now it's all "You're locked into your CI/CD pipeline" It sounds like, no matter what you do, you're locked in. Using Docker? Ah you're locked into Docker. Wrote your app in PHP, on you're locked into PHP now. I just don't understand this whole 'lock-in' mindset, it's just absurd now.
      - Nullabillity 9y ago
        The vital difference being that Docker and PHP aren't subscription-based, and aren't controlled by a single corporation.
        philliphaydon 9y ago
        Replace Docker and PHP with anything and the same is true tho. If you write your application in any language, or use any framework or library, you're locked in, by today's standards.
        hueving 9y ago
        The difference is that you can't be screwed by a single company deciding to change prices. When people refer to "lock-in", they are referring to being able to be screwed by a single vendor. Nobody cares if they are locked into x86, tcp/ip, and http. If you don't understand this difference as an engineer, you end up causing a big risk to your company (or clients) without even knowing it.
        philliphaydon 9y ago
        Oh so now it’s paying for something that’s lock-in. This lock in sure keeps changing.
      - hueving 9y ago
        >I just don't understand this whole 'lock-in' mindset, it's just absurd now. If you don't understand it, then it's probably not absurd. Look into the whole free software movement and the history behind it (e.g. the evils of Microsoft in the 90s). If a vendor can change a price on something that forces you to pay up or lose your system, you are locked in. This isn't just some open source ideology without impacts either. It should be immediately obvious to anyone with any business acumen why making yourself beholden to the decisions of a single vendor is a bad position to be in.
  - benatkin 9y ago
    If you look at the amount of work Serverless has to do, packaging can generate quite an amount of lock-in. It is hardly any lock-in in the simple cases of grabbing a single function and deploying it where you want.

I'm aware of tools like Serverless. They help remove the lock-in in some situations. That doesn't mean there's no lock-in to speak of at all.

philliphaydon 9y ago
In regards to C# functions, there is no lock-in to AWS, it's a piece of code, you can run that function on AWS Lambda, or in ASP.NET Website, or Azure Function, or console app... It's literally a method which has a single parameter class, and a single class returned... Even if you're using node, java, golang, python. Other than the packaging. How is there any lock in?
- hueving 9y ago
  Aren't you spending resources setting up your CI/CD pipeline /deployment tooling to talk to Amazon's APIs? Unless all of the providers have the same API to deploy functions, they are all trying to lock you in. So not lock-in at the code level (unless your serverless app talks to S3 or whatever Amazon services), but lock-in of your whole devops process.
  - philliphaydon 9y ago
    So first it's all "Oh you're locked into IIS" and "You're locked into Windows", then "You're locked into AWS" now it's all "You're locked into your CI/CD pipeline" It sounds like, no matter what you do, you're locked in. Using Docker? Ah you're locked into Docker. Wrote your app in PHP, on you're locked into PHP now. I just don't understand this whole 'lock-in' mindset, it's just absurd now.
    - Nullabillity 9y ago
      The vital difference being that Docker and PHP aren't subscription-based, and aren't controlled by a single corporation.
      - philliphaydon 9y ago
        Replace Docker and PHP with anything and the same is true tho. If you write your application in any language, or use any framework or library, you're locked in, by today's standards.
        hueving 9y ago
        The difference is that you can't be screwed by a single company deciding to change prices. When people refer to "lock-in", they are referring to being able to be screwed by a single vendor. Nobody cares if they are locked into x86, tcp/ip, and http. If you don't understand this difference as an engineer, you end up causing a big risk to your company (or clients) without even knowing it.
        philliphaydon 9y ago
        Oh so now it’s paying for something that’s lock-in. This lock in sure keeps changing.
    - hueving 9y ago
      >I just don't understand this whole 'lock-in' mindset, it's just absurd now. If you don't understand it, then it's probably not absurd. Look into the whole free software movement and the history behind it (e.g. the evils of Microsoft in the 90s). If a vendor can change a price on something that forces you to pay up or lose your system, you are locked in. This isn't just some open source ideology without impacts either. It should be immediately obvious to anyone with any business acumen why making yourself beholden to the decisions of a single vendor is a bad position to be in.
- benatkin 9y ago
  If you look at the amount of work Serverless has to do, packaging can generate quite an amount of lock-in. It is hardly any lock-in in the simple cases of grabbing a single function and deploying it where you want.