|
|
|
|
|
by eyberg
1582 days ago
|
|
This is very very common misconception. Just yesterday I was helping someone out with a networking issue they were having on AWS stemming from this concept. Coming from k8s/firecracker it is common to think that you need to orchestrate your unikernels with a framework of some kind. In our case (Nanos/OPS) a lot of people think that means spinning up an ec2 linux, sshing in and using 'ops run' on top of that but that is never suggested for prod deploys. Instead we suggest doing an 'image create' followed by an 'instance create'. What does this mean? Essentially every time you hit the deploy button a new ami is made and a brand new ec2 instance spins up without any linux inside. So instead of adding layers through containers we actually subtract them. That means you can still configure the instance to your hearts content but you don't have to manage it - the cloud does for you and this is a huge win for many teams that don't want to deal with all the ops/SRE work that something like k8s brings (or even normal vanilla linux does). It is important to realize that containers extract heavy performance penalties when running on top of existing infrastructure (like the cloud) since they duplicate storage and networking layers. They also have severe security issues - the shared kernel being the main one. |
|