\section{Containers}
\begin{frame}
   {Container Basics}
   \begin{figure}[H]
      \includegraphics[height=3.3in]{IMAGES/virt-container}
      \caption{Containers}
   \end{figure}
\end{frame}

\cprotect\note{

   Further integration between the hypervisor and the
   \textbf{Linux} kernel allowed the creation of
   operating system level virtual machines or
   \textbf{Containers}. Containers share many facilities
   in the \textbf{Linux} kernel and make use of some
   recent kernel additions such as \textbf{namespaces}
   and \textbf{cgroups}.  Containers are very light
   weight and reduce the overhead associated with having
   whole virtual machines.

   The first flavor of containers was the \textbf{OS
      container}. This type of container runs an image of
   an operating system with the ability to run \textbf{init}
   processes and spawn multiple applications.

   \textbf{LXC} (\textbf{Linux Containers}) is one example.

}

\section{Application Virtualization}
\begin{frame}
   {Application Virtualization}
   \begin{figure}[H]
      \includegraphics[height=3.3in]{IMAGES/virt-docker}
      \caption{Application Virtualization}
   \end{figure}
\end{frame}

\cprotect\note{

   In an effort to further reduce the overhead associated with
   virtual machines, \textbf{application virtualization} is rising in
   popularity. Application virtualization runs one application
   for each container. Many single application containers are typically
   initialized on a single machine. Using smaller components
   creates a greater flexibility and reduces overhead normally
   associated with virtualization.

   \textbf{Docker} is one such project.

}

\section{Containers vs Virtual Machines}
\begin{frame}
   {Containers vs Virtual Machines}

   \begin{itemize}
      \item Running Processes and Services
      \begin{itemize}
         \item
         VM runs a complete operating system and can run many
         services and applications
         \item
         Container usually runs one thing
      \end{itemize}
      \item VM uses more resources than a container
      \item
      Multiple containers share one OS kernel, each VM has its
      own
      \item
      Containers are more portable
      \item
      Containers can be run inside a VM
      \item
      Containers are harder to secure
      \item
      Containers usually start faster
      \item
      However, Virtual Machines are still often the best
      solution

   \end{itemize}

\end{frame}

\cprotect\note{

   Both Virtual Machines and Containers satisfy important
   needs.  For a while each facility had its day in the sun
   and was seen as the way to go for almost everything.

   Both have long histories:
   \begin{itemize}
      \item
      Main frame computers have had software partitioning and
      virtual machines for decades, in rather specialized
      ways.
      \item
      Operating systems have had \textbf{chroot} and
      \textbf{BSD Jail} implementations for many years, that
      share a basic isolation motivation with containers.
   \end{itemize}

   If a number of different services and applications need to
   be tightly integrated, a virtual machine functioning as a
   service may be the best solution.

   If the applications being run were written expecting a
   complete operating system environment with a wide range of
   services and other libraries and applications, virtual
   machines may be best.

   Scaling workloads is different for containers and virtual
   machines.  \textbf{Orchestration} systems such as
   \textbf{Kubernetes} or \textbf{Mesos} can decide on the
   proper quantity of containers needed, do load balancing,
   replicate images and remove them etc as needed.

}


