Containers won the battle, but will lose the war to serverless

Re:Containers won the battle, but will lose the war to serve... by zlynx on Friday February 23, 2018 @06:57PM (#16450678)

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.

[ Parent | on HN ]

Re:Containers won the battle, but will lose the war to serve... by brutopia on Friday February 23, 2018 @07:31PM (#16450840)

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.

[ Parent | on HN ]

Re:Containers won the battle, but will lose the war to serve... by k__ on Friday February 23, 2018 @08:50PM (#16451147)

And you have this with containers as with serverless. So no argument here.

[ Parent | on HN ]

Re:Containers won the battle, but will lose the war to serve... by ec109685 on Saturday February 24, 2018 @05:31AM (#16452651)

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.

[ Parent | on HN ]

Re:Containers won the battle, but will lose the war to serve... by k__ on Saturday February 24, 2018 @07:25AM (#16452964)

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.

[ Parent | on HN ]

Re:Containers won the battle, but will lose the war to serve... by ec109685 on Tuesday February 27, 2018 @03:18AM (#16471872)

But there is no standard way to specify those requirements in a cloud agnostic manner.

[ Parent | on HN ]