3 ms·

Why is it so ridiculous? It's pretty cheap these days.

adeptus 12y ago
It's not ridiculous at all, given production deployments need segmentation to maximize security. Docket may be fine for Dev environments with no real customer data being used, but to deploy to production if you use Docker, you will get shot... by the security guys.
- yebyen 12y ago
  I don't know about this, if you are following best practices and then add "with docker" you don't really change anything for the worse. There's just a whole new layer of best practices with docker that you have to learn, namely single-process container ideas and volume/image separation. If you're using Docker in development and then not using it in production, I hope you're using chef too, or something like it. The point to me is embracing the whole idea of "replaceable, reusable, disposable" components and DRY. If you're repeating by hand any complex steps in production that you also did in your development environment; never mind the time wasted, you now have twice as many chances to make mistakes.
_dark_matter_ 12y ago
There are plenty of wasted resources. Virtualization itself incurs a 30% overhead.
- csixty4 12y ago
  Do you have a citation for that? I did a dry run of a presentation for an engineer and her first question was "exactly how much fewer resources"? Would love to have a source for that in case I get asked again.
  - VLM 12y ago
    http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/ http://www.altechnative.net/2012/08/04/virtual-performance-p... http://serverfault.com/questions/261974/how-much-overhead-does-x86-x64-virtualization-have http://serverfault.com/questions/261974/how-much-overhead-do... These are good examples of there is no such thing as "the" virtualization and even front runners have a near 10:1 ratio of performance. Its like talking about "the" sorting algorithm. Its especially tough since there is no "the" benchmark. So if you're running a compile farm two years ago, the first article is quite relevant, otherwise maybe not. I've done a lot personally and professionally with virtualization and as a gut reaction you can usually justify and afford better specs because not all images will max out CPU at the same time, etc etc so in terms of production "stuff" done per hardware dollar you get a little more done with visualization assuming a sensible architecture. Then again you blow more money and labor and labor is money, on software for virtualization. Then again management and backup is usually simpler with virtualization, except when it isn't like when vmware and the NAS kills your mysql instances on an image when you run a backup and it starves the kernel for 60+ seconds of IO whoops. On average it ends up being about the same performance as non virtualized for a given amount of $$$$ but its much more flexible and responsive to change, which sometimes is worth it.

It's not ridiculous at all, given production deployments need segmentation to maximize security. Docket may be fine for Dev environments with no real customer data being used, but to deploy to production if you use Docker, you will get shot... by the security guys.

yebyen 12y ago
I don't know about this, if you are following best practices and then add "with docker" you don't really change anything for the worse. There's just a whole new layer of best practices with docker that you have to learn, namely single-process container ideas and volume/image separation. If you're using Docker in development and then not using it in production, I hope you're using chef too, or something like it. The point to me is embracing the whole idea of "replaceable, reusable, disposable" components and DRY. If you're repeating by hand any complex steps in production that you also did in your development environment; never mind the time wasted, you now have twice as many chances to make mistakes.

_dark_matter_ 12y ago

There are plenty of wasted resources. Virtualization itself incurs a 30% overhead.

csixty4 12y ago
Do you have a citation for that? I did a dry run of a presentation for an engineer and her first question was "exactly how much fewer resources"? Would love to have a source for that in case I get asked again.
- VLM 12y ago
  http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/ http://www.altechnative.net/2012/08/04/virtual-performance-p... http://serverfault.com/questions/261974/how-much-overhead-does-x86-x64-virtualization-have http://serverfault.com/questions/261974/how-much-overhead-do... These are good examples of there is no such thing as "the" virtualization and even front runners have a near 10:1 ratio of performance. Its like talking about "the" sorting algorithm. Its especially tough since there is no "the" benchmark. So if you're running a compile farm two years ago, the first article is quite relevant, otherwise maybe not. I've done a lot personally and professionally with virtualization and as a gut reaction you can usually justify and afford better specs because not all images will max out CPU at the same time, etc etc so in terms of production "stuff" done per hardware dollar you get a little more done with visualization assuming a sensible architecture. Then again you blow more money and labor and labor is money, on software for virtualization. Then again management and backup is usually simpler with virtualization, except when it isn't like when vmware and the NAS kills your mysql instances on an image when you run a backup and it starves the kernel for 60+ seconds of IO whoops. On average it ends up being about the same performance as non virtualized for a given amount of $$$$ but its much more flexible and responsive to change, which sometimes is worth it.