• Время загрузки виртуальной машины на несколько порядков больше, чем у контейнера. В конце концов, запуск контейнера означает просто запуск нового процесса Linux, а не полномасштабную загрузку и инициализацию виртуальной машины. Относительно медленная загрузка виртуальных машин означает медленную масштабируемость, не говоря уже о важности быстрой загрузки в случае частой поставки нового кода, например несколько раз в день. (Впрочем, обсуждаемая в разделе «Виртуальная машина Firecracker» на с. 144 технология виртуализации Firecracker от Amazon обеспечивает виртуальные машины с очень быстрой загрузкой, порядка 100 миллисекунд на момент написания данной книги.)
• Благодаря контейнерам разработчики могут «создать один раз, выполнять где угодно» быстро и эффективно. Можно, конечно, хотя это и займет немало времени, собрать образ виртуальной машины целиком и запускать его на своем ноутбуке, но данный подход не стал чрезмерно популярным среди разработчиков, в отличие от контейнеров.
• В современных облачных средах при аренде виртуальной машины выбирается CPU и объем оперативной памяти, за которые необходимо вносить арендную плату вне зависимости от того, какая часть этих ресурсов фактически используется работающим в ней кодом приложения.
• Каждая виртуальная машина влечет накладные расходы по выполнению всего ядра целиком. Благодаря совместному использованию ядра контейнеры гораздо рациональнее задействуют ресурсы и демонстрируют высокую производительность.
Безопасность контейнеров. Фундаментальный подход к защите контейнеризированных приложений
·
Лиз Райс
