The document discusses the evolution and advantages of cloud application deployment through bare-metal, virtualization, and containerization, specifically highlighting Docker as a management tool for containers. It outlines key pros and cons of both virtualization and container technologies, emphasizing the rapid lifecycle and performance benefits of containers but also acknowledging their security vulnerabilities. Additionally, the document introduces Intel's contributions towards enhancing container capabilities, suggesting a future coexistence of these technologies in IT environments.

1. Bare-metal, Docker Containers, and
Virtualization: The Growing Choices for Cloud
Applications
Nicholas Weaver – Principal Architect, Intel Corporation
DATS004

2. 2
How did we get here?

3. 3

4. 4
mainframe

5. 5
?

6. 6
x86

7. 7
x86
x86
x86

8. 8
x86
x86
x86
x86
x86
x86
x86
x86
x86
x86
x86

9. 9
x86

10. 10
Server
OS
App

11. 11
Server

12. 12
Server
App

13. 13
Server
App
70%

14. 14
Server
App
Server
App
Server
App
70%
25%
33%
43%

15. 15
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App

16. 16
Server
Hypervisor
VM

17. 17
Server
Hypervisor
VM
OS
App

18. 18
Server
VM
App
App
App
VM
VM
App
VM

19. 19
85%

20. 20
App
Compute
Networking
Storage

21. 21
Virtualization -Pros
•Carves hardware into virtual hardware
•Virtual hardware presented as a virtual machine
•Strong isolation between virtual machines
•Allows for running heterogeneous operating systems
•QoS, orchestration, templates, portability
•Live migration, high-availability, resource pooling

22. 22
Virtualization -Cons
•Each virtual machine is a complete stack (OS, patches, applications)
•Hypervisor and supporting management have to be maintained
•Measurable overhead compared to bare-metal

23. 23
Containers

24. 24
Containers
•Existed back in 2004 –Oracle*Solaris*Zones
•Implemented first by LinuX*Containers (LXC)
•Google’s*control implementation with lmctfy (Let Me Contain That For You)
•Modernized control recently introduced by Docker*

25. 25
How does it work?

26. 26
System
(Ubuntu*14.04)

27. 27
Container A
Container B
System

28. 28
Resource Limiting
System
Memory
Container
Memory 1GB
Container
Memory 2GB
Container A
Container B

29. 29
Resource Limiting
System
Storage
Container
Memory 1GB
Container
Memory 2GB
Container A
Block Device
10 MB/s
Block Device
10 MB/s
Block Device
20 MB/s
Container B

30. 30
Resource Limiting
System
CPU
Container
Memory 1GB
Container
Memory 2GB
Container A
Container B
Block Device
10 MB/s
Block Device
10 MB/s
Block Device
20 MB/s
CPU25% Share
CPU75% Share

31. 31
Namespace Isolation –Processes
Container
Memory 1GB
Container
Memory 2GB
Container A
Container B
Block Device
10 MB/s
Block Device
10 MB/s
Block Device
20 MB/s
CPU25% Share
CPU75% Share
PID
1234
1345
1467
PID
1234
1345
1467
Container A’s view of PIDs
Container B’s view of PIDs

32. 32
Namespace Isolation -Networking
Container
Memory 1GB
Container
Memory 2GB
Container A
Container B
Block Device
10 MB/s
Block Device
10 MB/s
Block Device
20 MB/s
CPU25% Share
CPU75% Share
Interfaces
veth0
veth1
Container A’s view of interfaces
Container B’s view of interfaces
Interfaces
veth3

33. 33
Namespace Isolation –Mounts
Container
Memory 1GB
Container
Memory 2GB
Container A
Container B
Block Device
10 MB/s
Block Device
10 MB/s
Block Device
20 MB/s
CPU25% Share
CPU75% Share
Mounts
/dev/sda1
Container A’s view of mounts
Container B’s view of mounts
Mounts
/dev/sda2
/dev/sda3

34. 34
Namespace Isolation –Mounts
Container
Memory 1GB
Container
Memory 2GB
Container A
Container B
Block Device
10 MB/s
Block Device
10 MB/s
Block Device
20 MB/s
CPU25% Share
CPU75% Share
Mounts
/dev/sda1
Container A’s view of mounts
Container B’s view of mounts
Mounts
/dev/sda2
/dev/sda3

35. 35
Namespace Isolation –Users
Container
Memory 1GB
Container
Memory 2GB
Container A
Container B
Block Device
10 MB/s
Block Device
10 MB/s
Block Device
20 MB/s
CPU25% Share
CPU75% Share
Users
neo
morpheustrinity
Container A’s view of users
Container B’s view of users
Usersharry
hermioneron

36. 36
When things look the same

37. 37
Server
VM
App
App
App
VM
VM
App
VM

38. 38
VM
Widget Scraper Service
Widget Lib
Linux OS
VM
Widget Painter Service
Widget Lib
Linux*OS
VM
Widget Cleaner Service
Widget Lib
Linux OS

39. 39
Widget Scraper Service
Widget Lib
Linux*OS
Widget Painter Service
Widget Cleaner Service
Container A
Container B
Container C

40. 40
VM
Widget Scraper Service
Widget Lib
Linux*OS
Widget Painter Service
Widget Cleaner Service
Container A
Container B
Container C

41. 41
Server
Widget Scraper Service
Widget Lib
Linux*OS
Widget Painter Service
Widget Cleaner Service
Container A
Container B
Container C

42. 42
Some container pros
•Faster lifecycle vs. virtual machines
•Contains what is running within the OS
•Ideal for homogenous application stacks on Linux*
•Almost non-existent overhead

43. 43
Some container cons
•Very complex to configure
•Currently much weaker security isolation than virtual machines(more on that in a bit)
•Applications must run on Linux*

44. 44

45. 45
Docker*
•Open source container management for Linux*
•Adds DevOps-like features
•Developed by dotCloud (now known as Docker*) to help deliver their PaaS product
•An easy button for containers

46. 46
What does Docker*bring?

47. 47
Docker*Images
•Ordered results of actions to build a container
-Add file
-Open port
-Run a command
•DevOps like source code for a deployment image
•Uses a copy-on-write file system (like others)

48. 48
Docker*Images -Dockerfile

49. 49
Images are layers
rootfs
bootfs
run apt-get
set env var
from ubuntu:14.04
cmd = “../apache2”

50. 50
Images are layers
rootfs
bootfs
run apt-get
set env var
from ubuntu:14.04
cmd = “../apache2”
my_app

51. 51
Images are layers
rootfs
bootfs
run git-clone
mount dir
from my_app
cmd = “../apache2”
my_app2

52. 52
Image Registry
•Public Docker registry: Docker*Hub
•Option to deploy your own private Docker Registry

53. 53
Docker*Hub

54. 54
Client => Server
Docker Daemon
Linux
Docker*Client
Linux*/Windows*/OS X*

55. 55
Client => Server
Docker Daemon
Linux
Docker*Client
Linux*/Windows*/OS X*
[docker run web-server]
Container
Web Server
Image

56. 56
Client => Server
Docker Daemon
Linux
Docker*Client
Linux*/Windows*/OS X*
[docker run database]
Container
Web Server
Image
Container
Database
Image

57. 57
Client => Server
Docker Daemon
Linux
Docker*Client
Linux*/Windows*/OS X*
[docker stop database]
Container
Web Server
Image
Container
Database
Image

58. 58
Client => Server
Docker Daemon
Linux
Docker*Client
Linux*/Windows*/OS X*
Container
Web Server
Image

59. 59
Docker*Innovations
•Images
-Like templates for VMs
-Copy-on-write makes them behave like code
-Caching takes advantage of uniformity of platform layer
•API and CLI tools for managing container deployments
-Easy to wire into existing CI systems
-Works well with deployment workflows
•Reduces complexity around deploying and managing containers
•Supports namespace and resource limits

60. 60
Rubber meets road

61. 61
BizApp

62. 62
code
Private Docker*Registry
BizApp
Image
Container
laptop
pull
Version Control System
commit
push

63. 63
code
Private Docker*Registry
Container
laptop
pull
Version Control System
commit
push
pull
Container
CI server
BizApp
Image
BizApp
Image
Build Server
push
test

64. 64
Private Docker*Registry
Docker*+ Containers = Less Friction
BizApp
Docker Daemon
Linux
Docker Daemon
Linux
Docker Daemon
Linux
Docker Daemon
Linux
Docker*Daemon
Linux*
Container
BizApp
Image
Container
BizApp
Image
Container
BizApp
Image
Container
BizApp
Image
Container
BizApp
Image

65. 65
The Gotchas

66. 66
Are containers secure?

67. 67
Payments
Image
Container
physical server
HIPPA
Image
Container
Catalog
Image
Container
Can I trust a container?

68. 68
Answer: it depends
•Root access?
•Special surface needs for the application?
•Patches for host
•Auditing requirements?
•Default settings are dangerous

69. 69
One more option
Payments
Image
Container
virtual server
HIPPA
Image
Container
Catalog
Image
Container
physical server
virtual server
virtual server
Catalog
Image
Container

70. 70
How can Intel help make containers better?
•Security
-Intel® Advanced Encryption Standard New Instructions (Intel® AES-NI)
-Intel® Trusted Execution Technology (Intel® TXT/TCP)
-Intel® SGX
•Performance/Flexibility
-Intel® Virtualization Technology (Intel® VT-x/VT-d/VT-c)
•What if?

71. 71
Summary
•New productivity tools make containers an exciting new tool for IT environments
•Containers are especially powerful where application startup time is crucial (seconds vs. minutes)
•Containers are expected to coexist with other virtualization approaches, and pre-existing IT methods
•The container developers ecosystem is maturing quickly; scale deployment ecosystem naturally takes longer to develop
•Docker adds imaging features and greatly simplifies container management
•Intel is working on enhancing the performance, security, and interoperability of containers

72. 72
Next Steps
•Explore more on containers
-The Docker Book, James Turnball –www.dockerbook.com
-Run Docker on Windows*or OS X*w/ boot2dockerhttps://github.com/boot2docker/boot2docker

73. 73
Additional Sources of Information
•A PDF of this presentation is available from our Technical Session Catalog: www.intel.com/idfsessionsSF. This URL is also printed on the top of Session Agenda Pages in the Pocket Guide.

74. 74
Legal Disclaimer
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS.NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT.EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USEOF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANYPATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.
A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or death.SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY,OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS.
Intel may make changes to specifications and product descriptions at any time, without notice.Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined".Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them.The information here is subject to change without notice.Do not finalize a design with this information.
The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications.Current characterized errata are available on request.
Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your productorder.
Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or go to:http://www.intel.com/design/literature.htm
Intel, Look Inside and the Intel logo are trademarks of Intel Corporation in the United States and other countries.
*Other names and brands may be claimed as the property of others.
Copyright ©2014 Intel Corporation.

75. 75
Risk Factors
The above statements and any others in this document that refer to plans and expectations for the second quarter, the year and the future are forward- looking statements that involve a number of risks and uncertainties. Words such as “anticipates,” “expects,” “intends,” “plans,”“believes,” “seeks,” “estimates,” “may,” “will,” “should” and their variations identify forward-looking statements. Statements that refer to or are based on projections, uncertain events or assumptions also identify forward-looking statements. Many factors could affect Intel’s actual results, and variances from Intel’s current expectations regarding such factors could cause actual results to differ materially from those expressed in these forward-looking statements. Intel presently considers the following to be important factors that could cause actual results to differ materially from thecompany’s expectations. Demand for Intel's products is highly variable and, in recent years, Intel has experienced declining orders in the traditional PC market segment. Demand could be different from Intel's expectations due to factors including changes in business and economic conditions; consumer confidence or income levels; customer acceptance of Intel’s and competitors’ products; competitive and pricing pressures, including actionstaken by competitors; supply constraints and other disruptions affecting customers; changes in customer order patterns including order cancellations; and changes in the level of inventory at customers. Intel operates in highly competitive industries and its operations have high costs that are either fixed or difficult to reduce in the short term. Intel's gross margin percentage could vary significantly from expectations based on capacity utilization; variations in inventory valuation, including variations related to the timing of qualifying products for sale; changes in revenue levels; segment product mix; the timing and execution of the manufacturing ramp and associated costs; excess or obsolete inventory; changes in unit costs; defects or disruptions in the supply of materials or resources; and product manufacturing quality/yields. Variations in gross margin may also be caused by the timing of Intel product introductions and related expenses, including marketing expenses, and Intel's ability to respond quickly to technological developments and to introduce new products or incorporate new features into existing products, which may result in restructuring and asset impairment charges. Intel's results could be affected by adverse economic, social, political and physical/infrastructure conditions in countries where Intel, its customers or its suppliers operate, including military conflict and other security risks, natural disasters, infrastructure disruptions, health concerns and fluctuations in currency exchange rates. Intel’s results could be affected by the timing of closing of acquisitions, divestitures and other significant transactions. Intel's results could be affected by adverse effects associated with product defects and errata (deviations from published specifications), and by litigation or regulatory matters involving intellectual property, stockholder, consumer, antitrust, disclosure and other issues, such as the litigation and regulatory matters described in Intel's SEC filings. An unfavorable ruling could include monetary damages or an injunction prohibiting Intel from manufacturing or selling one or more products, precluding particular business practices, impacting Intel’s ability to design its products, or requiring other remedies such as compulsory licensing of intellectual property. A detailed discussion of these and other factors that could affect Intel’s results is included in Intel’s SEC filings, including the company’s most recent reports on Form 10-Q, Form 10-K and earnings release.
Rev. 4/15/14