4 ms·

If we take "Container" to specifically mean OS-level isolation of applications, then there is a strong likelihood that Containers will be replaced by lightweigh

by ch_123 7y ago

If we take "Container" to specifically mean OS-level isolation of applications, then there is a strong likelihood that Containers will be replaced by lightweight VMs. To me, the rise of containers has been about packaging software alongside all its dependencies in a standalone package that is (to varying degrees) isolated from the underlying host. In that sense, lightweight VMs are an evolution of the container model we already use. The author fails to explain how these lightweight VMs would be orchestrated. Maybe Kubernetes sucks, but if something more secure comes along, is that a failure of the container approach, or is it an evolution? All in all, this feels like someone writing a post saying "The aircraft created by the Wright Brothers was terrible, therefore powered flight was a failure". That, an attempt to sell something by bashing popular techs and millennial coders.

eyberg 7y ago
For orchestration: Someone else mentioned this in a different comment, but there was very much a link to firecracker in the article. That - and all the other many tools that you would deploy vms to the public cloud today of which there are numerous production quality options out there. Lastly, this is precisely the point I was trying to address with the "I'm honestly curious - what are the alternatives?" paragraph.
- wmf 7y ago
  You could say Lambda is the orchestration layer for Firecracker but it's based on the serverless/FaaS model that's a lot more restrictive than containers.
  - eyberg 7y ago
    Oh - I'm not saying that Lambda is what I'd personally choose, although there definitely seems to be quite a few people that do like it. As mentioned in the article - the base unit of compute on public cloud is the virtual machine so there are quite a few tools out there to deploy those. Some microvm implementations out there won't boot straight off AWS/GCE but many including Nanos do. It takes ~2min to deploy && boot most applications we are running on GCE - AWS is a bit longer (but I could see that changing in the future). Note - in this case you are actually uploading the entire image - if you are just spinning up/down than it's much much faster.
    - wmf 7y ago
      Yeah, I guess it depends on your goals. Some of the unikernel people talk about VMs even smaller/cheaper than a t3.nano that start faster than any cloud can start a VM. Clearly to run such a thing you would need your own orchestration layer. Maybe that's a niche within a niche though.
      - eyberg 7y ago
        Agreed. I think for our general use case we are looking at people with needs that are using vms or containers today (eg: not necessarily those that want plaid speed boot-times). That's not really something we are currently optimizing for. For something like a database there would be no desire to spin up/down so fast. Also, many frameworks with heavy language vms such as JVM or ruby take a long time to boot regardless so trying to run those in a 5-10ms boot-time doesn't make a ton of sense. Having said that, there most definitely are very very interesting projects like LightVM, http://cnp.neclab.eu/projects/lightvm/ http://cnp.neclab.eu/projects/lightvm/ that do target low latency and NFV would be a great use-case for projects like that.
wmf 7y ago
Yeah, if you look at how lightweight VMs are being used, they're being used to run containers, not unikernels.
eeZah7Ux 7y ago
> packaging software alongside all its dependencies That's why containers are a security disaster. And they also make it impossible to do system administration with reasonable resources.
- ecnahc515 7y ago
  No more a disaster than managing multiple VMs that have their own set of installed packages that you need to securely update regularly.
btilly 7y ago
The author fails to explain how these lightweight VMs would be orchestrated. There are two directions that most organizations can go from containers, and they have opposite answers to this question. The first direction is back to a monolithic application running in a VM. Orchestration no longer exists as a problem. What else do we get? Development is easier. Debugging is easier. We have literally decades of experience figuring out how to make it work. Very, very few of the people reading this post are solving problems harder than ones I was solving decades ago using that kind of stack. Other than the fact that your resume won't look as good, there is zero reason not to do this. The other is, as the post's author recommends, even further into isolating the app. Down to something even simpler than a container. In which case you will need a solution for orchestration, but it won't let you leverage a single running VM to a whole cluster. Limiting the attack area will be good for security. As a bonus things that container folks say work, but don't, will work. For example autoscaling fails in adtech with containers fails hard because the time that it takes to boot up new instances exceeds the time that you are getting flooded by your ad. But if your unikernel boots fast enough, now autoscaling does work. Now there is a third use case. And that is organizations like Google whose codebase is so big that they can't run it monolithically on a single machine. Containers solve that in a distributed environment by letting them run only some of their code on each machine. There is a hidden cost that RPCs over a network are inherently an order of magnitude more expensive (in time, latency, and resources) than a function call inside of a running application. So you order an order of magnitude more hardware, and containers are the sweet spot for you. But that problem is of a kind that very few organizations have. And making it actually work takes a lot of thought and organization that very few in the containerization world seem to understand. Certainly if you read a few blog posts, install Docker and Kubernetes, then start deploying through Helm, I am willing to bet large sums of money that you are almost certainly making rookie mistakes.
- mschuster91 7y ago
  > The first direction is back to a monolithic application running in a VM. Orchestration no longer exists as a problem Of course it does, VMware makes a boatload of money with VM orchestration. Or you setup OpenStack which is free but a nightmare in itself. You do not want a hand-rolled KVM virtualization stack. I've been there, I've seen the horrors.
kortilla 7y ago
> packaging software alongside all its dependencies in a standalone package that is (to varying degrees) isolated from the underlying host You mean like vmdk or qcow2 images did for nearly a decade before containers rose?
- dharmab 7y ago
  Check out Kata Containers if you're interested in QEMU with a container interface.

by ch_123 7y ago

eyberg 7y ago

For orchestration: Someone else mentioned this in a different comment, but there was very much a link to firecracker in the article. That - and all the other many tools that you would deploy vms to the public cloud today of which there are numerous production quality options out there. Lastly, this is precisely the point I was trying to address with the "I'm honestly curious - what are the alternatives?" paragraph.

wmf 7y ago
You could say Lambda is the orchestration layer for Firecracker but it's based on the serverless/FaaS model that's a lot more restrictive than containers.
- eyberg 7y ago
  Oh - I'm not saying that Lambda is what I'd personally choose, although there definitely seems to be quite a few people that do like it. As mentioned in the article - the base unit of compute on public cloud is the virtual machine so there are quite a few tools out there to deploy those. Some microvm implementations out there won't boot straight off AWS/GCE but many including Nanos do. It takes ~2min to deploy && boot most applications we are running on GCE - AWS is a bit longer (but I could see that changing in the future). Note - in this case you are actually uploading the entire image - if you are just spinning up/down than it's much much faster.
  - wmf 7y ago
    Yeah, I guess it depends on your goals. Some of the unikernel people talk about VMs even smaller/cheaper than a t3.nano that start faster than any cloud can start a VM. Clearly to run such a thing you would need your own orchestration layer. Maybe that's a niche within a niche though.
    - eyberg 7y ago
      Agreed. I think for our general use case we are looking at people with needs that are using vms or containers today (eg: not necessarily those that want plaid speed boot-times). That's not really something we are currently optimizing for. For something like a database there would be no desire to spin up/down so fast. Also, many frameworks with heavy language vms such as JVM or ruby take a long time to boot regardless so trying to run those in a 5-10ms boot-time doesn't make a ton of sense. Having said that, there most definitely are very very interesting projects like LightVM, http://cnp.neclab.eu/projects/lightvm/ http://cnp.neclab.eu/projects/lightvm/ that do target low latency and NFV would be a great use-case for projects like that.

wmf 7y ago

Yeah, if you look at how lightweight VMs are being used, they're being used to run containers, not unikernels.

eeZah7Ux 7y ago

> packaging software alongside all its dependencies That's why containers are a security disaster. And they also make it impossible to do system administration with reasonable resources.

ecnahc515 7y ago
No more a disaster than managing multiple VMs that have their own set of installed packages that you need to securely update regularly.

btilly 7y ago

The author fails to explain how these lightweight VMs would be orchestrated. There are two directions that most organizations can go from containers, and they have opposite answers to this question. The first direction is back to a monolithic application running in a VM. Orchestration no longer exists as a problem. What else do we get? Development is easier. Debugging is easier. We have literally decades of experience figuring out how to make it work. Very, very few of the people reading this post are solving problems harder than ones I was solving decades ago using that kind of stack. Other than the fact that your resume won't look as good, there is zero reason not to do this. The other is, as the post's author recommends, even further into isolating the app. Down to something even simpler than a container. In which case you will need a solution for orchestration, but it won't let you leverage a single running VM to a whole cluster. Limiting the attack area will be good for security. As a bonus things that container folks say work, but don't, will work. For example autoscaling fails in adtech with containers fails hard because the time that it takes to boot up new instances exceeds the time that you are getting flooded by your ad. But if your unikernel boots fast enough, now autoscaling does work. Now there is a third use case. And that is organizations like Google whose codebase is so big that they can't run it monolithically on a single machine. Containers solve that in a distributed environment by letting them run only some of their code on each machine. There is a hidden cost that RPCs over a network are inherently an order of magnitude more expensive (in time, latency, and resources) than a function call inside of a running application. So you order an order of magnitude more hardware, and containers are the sweet spot for you. But that problem is of a kind that very few organizations have. And making it actually work takes a lot of thought and organization that very few in the containerization world seem to understand. Certainly if you read a few blog posts, install Docker and Kubernetes, then start deploying through Helm, I am willing to bet large sums of money that you are almost certainly making rookie mistakes.

mschuster91 7y ago
> The first direction is back to a monolithic application running in a VM. Orchestration no longer exists as a problem Of course it does, VMware makes a boatload of money with VM orchestration. Or you setup OpenStack which is free but a nightmare in itself. You do not want a hand-rolled KVM virtualization stack. I've been there, I've seen the horrors.

kortilla 7y ago

> packaging software alongside all its dependencies in a standalone package that is (to varying degrees) isolated from the underlying host You mean like vmdk or qcow2 images did for nearly a decade before containers rose?

dharmab 7y ago
Check out Kata Containers if you're interested in QEMU with a container interface.