4 ms·

> Sure, it would be nice to have a competitive environment with different providers you can switch between. But that is secondary to usefulness and functionalit

> Sure, it would be nice to have a competitive environment with different providers you can switch between. But that is secondary to usefulness and functionality, because companies are in competition with each other anyway. And the chance of getting the actual providers to agree is pretty close to zero. Everybody goes: “Well, we’re going to differentiate on this or that.” That is exactly the situation with kubernetes and containers, and it is nice indeed, as I can easily switch between providers. In fact, my company got free digital ocean credits and was able to seamlessly host a cluster on DO for free to enhance testing. This is the ultimate. What scares me about serverless is the complete lock-in with the vendor. It’s the same reason google app engine just couldn’t be a game changer. You need that balance between customization and commoditization that serverless I think fails on, unless some protocol like docker comes in to save it.

zlynx 9y ago
From what I've seen with serverless, it doesn't look that hard to build your own runtime for it if you did want to run outside of your vendor and avoid lock-in. It would turn your stuff back into a stack of containers, of course.
- brutopia 9y ago
  That’s the relatively easy part. There’s also a lock-in with all the integrations as you probably need to have some sort of persistent storage and all the other managed services helping to cope with the complete statelessness.
  - k__ 9y ago
    And you have this with containers as with serverless. So no argument here.
    - ec109685 9y ago
      No, with Kubernetes, you specify, for example, that your app needs block store of a certain size or ingress at a certain port. The runtime knows how to satisfy that on each cloud.
      - k__ 9y ago
        What I meant was, when you set up the container and got your data in S3, it is in there, same goes with serverless. Nobody prevents you to write your serverless function so it needs a block store of a certain size or ingress at a certain port.
        ec109685 9y ago
        But there is no standard way to specify those requirements in a cloud agnostic manner.

zlynx 9y ago

From what I've seen with serverless, it doesn't look that hard to build your own runtime for it if you did want to run outside of your vendor and avoid lock-in. It would turn your stuff back into a stack of containers, of course.

brutopia 9y ago
That’s the relatively easy part. There’s also a lock-in with all the integrations as you probably need to have some sort of persistent storage and all the other managed services helping to cope with the complete statelessness.
- k__ 9y ago
  And you have this with containers as with serverless. So no argument here.
  - ec109685 9y ago
    No, with Kubernetes, you specify, for example, that your app needs block store of a certain size or ingress at a certain port. The runtime knows how to satisfy that on each cloud.
    - k__ 9y ago
      What I meant was, when you set up the container and got your data in S3, it is in there, same goes with serverless. Nobody prevents you to write your serverless function so it needs a block store of a certain size or ingress at a certain port.
      - ec109685 9y ago
        But there is no standard way to specify those requirements in a cloud agnostic manner.