[white paper] are containers the future ?

Are

containers the future?

A white paper by Orange Business Services (OCB Innovation) and Orange Silicon Valley

Scope

This paper presents container technology with a particular focus on Docker®, the

company, its technology, comparing containers with the VM approach, its

involvement in the DevOPs and Platform as a service model, and partnerships with

other IT players. It also touches upon the emergence of microservices architecture

along with challenges to enterprise adoption.

Executive summary

Over the years, information technology has evolved from expensive mainframes to

client-servers and now to cloud computing. A process once handled by a single,

large mainframe was then replaced with hundreds of servers until the birth of the

Internet when hundreds became thousands. As the server count increased, power

and cooling needs skyrocketed as well. By laying the foundation for new computing

architecture over the last decade, server virtualization has helped server

consolidation. Yet with so many advancements happening at only the infrastructure

level, application portability has remained the same over the years, leading to a

number of conflicts between development and operations teams.

Virtual servers that were created by virtualizing the operating system are commonly

known as containers and have been around since the early 2000s. DotCloud® built

their company based on Linux container technology and open sourced its software

before being renamed to Docker® in 2013 and renewing life for containers.

Container technology enables any application and its dependencies to be packaged

up as a lightweight, portable, self-sufficient container that can be deployed

anywhere.

Docker®’s rapid growth within such a short amount of time emphasizes how badly

enterprises have been looking for an application portability solution that would span

across different clouds and different environments within the datacenter during the

application lifecycle. Container technology has been instrumental in the renewed

interest in Platform as a Service (PaaS) model for enterprises, primarily because it

acts as a technology enabler. Containers are developer friendly while ensuring an

easy separation of duties and responsibilities for developer and operations teams,

thereby fully supporting the DevOps concept that is the top to-do list item for many

enterprises.

According to Tracxn®, by looking at the last two years alone one can see the rapid

emergence of the Docker® ecosystem as approximately $200 – $250 million dollars

of funding have been injected into different, related companies. The only competitor

to Docker® is CoreOS®, owner of Rocket® container technology. Security and a

lack of tools are the two biggest challenges for enterprise adoption of container

technology. It is not a question of whether enterprises will adopt containers or not,

rather the question is when they will adopt the technology. Virtual machines have

been the defacto standard for all enterprises over the last decade and while

containers are going to challenge that in the long run, in the short run containers will

co-exist with virtual machines.

Birth of containers

Over the last fifteen years many organizations have undergone the journey to cloud,

first by virtualizing dedicated physical machines for applications, and then by

subsequently transitioning to an automated and self-service cloud. On this journey

the primary mover to cloud computing has always been the virtual machine. Server

virtualization is the masking of server resources, including the number and identity

of individual physical servers, processors, and operating systems, from server users.

The server administrator uses a software application to divide one physical server

into multiple isolated virtual environments.

There are three ways of creating virtual servers and each of them possesses

differences in how they allocate

resources to the servers.

Hardware virtualization creates

virtual servers that emulate the

physical hardware.

Paravirtualization presents a

software interface that functions like

underlying hardware to virtual

servers.

Operating system virtualization

creates virtual servers that share an

operating system.

Within the last decade the runaway success of hardware virtualization has laid the

foundation for new computing architecture. Paravirtualization was never a success,

and while OS virtualization was temporarily popular it ultimately lost the race to

hardware virtualization. Virtual servers that were created using OS virtualization are

commonly known as containers. Although only recently popular, containers are not

new and several trending container technologies include chroot®, OpenVZ®,

Parallels®, FreeBSD Jail®, Linux Container LXC®, and libcontainer® several of

which were established in the early 2000s. DotCloud® based their company on

Linux container technology and open sourced their software before renaming the

company to Docker® in 2013 which renewed life for containers.

figure 1 – types of virtualization

Role of containers

The best way to comprehend the role of application containers is by understanding

the analogy between shipping containers and how they revolutionized the

transportation of goods. Prior to World War II, there were several non-standard

methods of containerization across the globe ranging from wooden crates to railway

boxcars. During the war, it was the sheer volume of cargo needed to support the

war effort that led to a standardization of containers. In 1995 the idea of steel box

containers became a reality that allowed stacking in a manner that optimized

efficient loading and unloading of cargo. Over the next few years, ships and ports

changed dramatically to accommodate the shift to containerized transport. Today,

over 90% of bulk cargo travels in standard shipping containers. The use of

containers has shaped not only the landscape of the world’s ports but truck chassis,

pallets and forklift equipment as well as even cranes that have evolved to

accommodate containers.

figure 2 - transportation of goods (source: Docker.io®)

In the IT world, we have different types of applications and services that are

deployed on various hardware environments. The challenge is that every time an

application is written or re-written, it then needs to be deployed or re-deployed to

the different environments with each requiring a unique set of tools. Containers

enable any application and its dependencies to be packaged up into a lightweight,

portable, self-sufficient container that is easily deployable to any location. Docker®

acts as a shipping container for code and some of the key features of shipping an

application in comparison to shipping a container are listed below.

Content agnostic

Shipping container holds any type of cargo

Application container holds any type of payload

Hardware agnostic

Standard shape allows containers to be moved to and from a train, truck,

ship, crane or warehouse

cargo transport pre-1960

cargo transport – today

Application container run on

VMs, bare metals, OpenStack

clusters or public instances

Separation of duties

Shipper worries about what

goes inside and carrier

worries about the external

factors

Developer worries about the

internal and operations

worries about the external.

Docker®

Company history

In early 2008, a company known as DotCloud® was founded on a Platform as a

Service product offered by Salomon Hykes and Sebastien Pahl, who graduated

from Epitech®, France. After a few years, due to lack of market adoption,

DotCloud® was open sourced in 2013 and within several months the company was

renamed to Docker® shifting the focus entirely on Linux container technologies.

Funding

Series D – 95 Million in Mar 2015 led by Insight Venture® partners

Series C – 40 Million in Sep 2014 led by Sequoia®

Series B – 15 Million in Jan 2014 led by Greylock® partners

Numbers

No. of funded startup in Docker® ecosystem: 40

No. of GitHub projects with Docker® in the name: 33,000

Dockerized applications: 100,000

No. of organizations in DockerHub: 10,000

Docker® containers downloaded: 320 million by 4 million developers

No. of employees: 120 and expected to grow to 200 by end of the year

Companies acquired: KiteMatci®, Koality®, SocketPlane®

figure 3 - transportation of application (source: Docker.io®)

Key terminology and concepts

LAYER

In traditional Linux, kernel mounts the

root file system as read only and later

switches to read-write mode. When

Docker® mounts the root file system

it starts as read only, and later

instead of turning into a read-write

file system, it adds a read-write file

system over the read-only file

system. In turn, there can be multiple

read-only file systems stacked on top

of each other. Each of the file

systems is called a layer.

IMAGE

In Docker®, a read only layer is

called an image. Each image depends on another image that forms a layer beneath

it. The lower image is referred to as the parent image. An image without a parent

image is called a base image.

The rebirth of containers has had a telling impact on key concepts like DevOps and

PaaS. It is also aiding the rise of a new microservices architecture.

DevOps

DevOps consists of blending tasks performed by a company's application

development and systems operations teams. The goal of DevOps is to ensure that

both the dev and ops team participate from, the point of idea inception all the way

to the stage of successful service implementation or product roll out. Docker® helps

both the developer and operations team work together as a unit while still allowing

them to separate necessary duties and responsibilities. Some of the DevOps related

key terms are:

AGILE DEVELOPMENT

A software development method within which requirements and solutions evolve

through collaboration between self-organizing, cross-functional teams. It

encourages a rapid and flexible response to change.

CONTINUOUS INTEGRATION

In software engineering this is the practice of assembling and packaging all the

working copies of developer code with a shared mainline, several times a day.

figure 4 – Docker® terminology (source: Docker.com®)

figure 6 – IaaS vs PaaS vs Saas

CONTINUOUS DELIVERY

This is a software

engineering approach in

which teams keep

producing valuable

software in short cycles

and ensure that the

software can be reliably

released at any time.

CONTINUOUS DEPLOYMENT

The released software is

automatically deployed into

production.

Cloud computing service models

Docker® has had a huge impact on two of the following three service models,

Infrastructure as a Service and Platform as a Service but not on Software as a

Service. Docker® has also played an instrumental role in the addition of a new

service model: Container as a Service.

INFRASTRUCTURE AS A SERVICE (IAAS)

The cloud provider delivers cloud computing infrastructure like servers, storage,

network, virtual machines, and

operating system as a service.

PLATFORM AS A SERVICE (PAAS)

The cloud provider delivers hardware

and software tools needed for

application development to its users

as a service. PaaS is targeted at

developers to allow them to perform

rapid software development.

SOFTWARE AS A SERVICE (SAAS)

Software is delivered as a service over

the internet with the entire stack

managed by the cloud provider.

CONTAINER AS A SERVICE (CAAS)

Container as a service can be seen as the layer between IaaS and PaaS, where IaaS

provides hardware virtualization and a template for the operating system but the

customer is responsible for managing the operating system. While PaaS provides

language specific application runtime and focuses on what is running inside the

process, CaaS acts as the glue by providing the generic framework necessary to run

any process on any infrastructure.

figure 5 – DevOps lifecycle

figure 8 – Docker® components (source: Docker.com)

figure 9 - client-server architecture

Microservices architecture

In traditional monolithic

applications the major

challenge was deployment of

an application and any

subsequent updates, because

the entire application needed

to be updated in

synchronization with all other

components. Microservices

creates a distributed model for

applications where every

component can be changed

independently without affecting any other components. With Docker® it is easier to

manage individual components separately by running them in different containers

rather than having the entirety of applications components in a single container.

Docker® advocates the use of Microservices architecture while designing container

based applications.

Docker® architecture

Docker® is an open platform for distributing and packaging applications and has

two major components:

DockerEngine - a lightweight

application runtime and packaging

tool

DockerHub - a place holder

for storing and managing Docker®

images

Docker® utilizes a client-server architecture where the client interacts with the

daemon. The client and daemon may both

reside in the same system, or the client can

connect to a remote daemon via restful API’s

or a socket connection. The daemon is

responsible for building, running and

distributing containers created from the

images. Images are stored in Docker® Hub,

a registry which can be set to public or

private viewing with the opportunity for

images to be both uploaded and

figure 7 - monolithic vs microservices

downloaded easily. Docker® is also designed with an open source platform to build,

ship, and run distributed applications.

BUILD-SHIP-RUN

build Docker® daemon uses Dockerfile, a text file that allows the

creation of Docker® images by capturing the Docker® image

creation process in the form of a script. Currently, there are

about a dozen sets of different commands that a Dockerfile can

contain which are then used to build an image. The process to

build a Docker® image includes the following steps:

Select the OS - specify the operating system or base

image to be used

Construct Layers - run different commands as needed,

creating a layer for each command

Set the environment – specify the arguments and

different ports for application configuration

Build image – save the Dockerfile and build an image

Ship Once the image is built, it can then be shared locally or globally

using a private and public repository or registry.

Run Use the image and run containers anywhere regardless of

whether it is on physical, virtual or cloud servers (as long as the

underlying Linux kernel is the same).

figure 11 – dev to prod using Docker®

(source: Thomason.io, Author - James)

Use cases

Docker® advocates eight different use cases out of which three key examples are

explained below.

figure 10 - use cases

DEVELOPER PRODUCTIVITY

Developers are a very expensive

resource; therefore they should

neither wait for infrastructure

resources nor work on issues

pertaining to environment. Here,

containerization has some obvious

technical advantages including better

resource utilization and control of

guest operating systems. One of the

more nuanced benefits however has

to do with abstraction of the

operating system and its resource

dependencies from the application

and its dependencies. The latter

benefit helps enable an idealized

workflow called immutable infrastructure, where the state of the application

configuration and dependencies is preserved from development through testing and

on into production. Containers have a finite life cycle that is optimized for developer

productivity and changes are not made to a production environment but rather to

the container itself, making it possible for the application to work everywhere.

figure 12 – release process using Docker®

figure 13 – virtual machines to Docker®

RAPID DEPLOYMENT

Docker® images are built on union

file systems with changes added as

layers. The steps to build an image

are mentioned in Dockerfile, which is

why deploying containers from

images using Dockerfile takes mere

seconds. Since the same image is

then used across different

environments like development, QA,

staging and production, deployment

is much faster. Also, only changes

are pulled into any environment

rather than the whole image for

continuous deployment. For large

scale deployments many

orchestration tools are evolving to

handle the interdependencies

between containers and how

individual containers can be updated without disrupting the operations of other

containers.

SERVER CONSOLIDATION

Virtual machines (VMs) ushered in the age of consolidation, where servers were

better able to utilize computing power

compared to running applications

directly in a physical server. Unlike

VMs, containers do not need to run a

full version of an operating system,

opening the door to a new level of

consolidation. The consolidation ratio

with containers is better at least by

tenfold compared to consolidation

achieved using virtual machines.

Vendor ecosystem

A rapid emergence of the Docker® ecosystem is obvious when looking at the last

two years alone and seeing approximately $200 to $250 million dollars of funding

injected into related companies.

figure 14 – container market map by investment (source: Tracxn.com®)

Some of the funded companies are listed below.

ClusterHQ®, the company behind open source Flocker® data

volume manager and container manager, is a tool for database

portability and has received $12 million in funding. Flocker®

enables the stateful live migration of an application which is not

feasible using Docker®.

CoreOS® was a partner of Docker®, until they came up with

their own container: Rocket® at the end of 2014. Kubernetes,

Google®’s open source program, allows companies to manage

a cluster of containers as though they were a single system.

CoreOS® also announced Tectonic, a commercial distribution

of CoreOS® and its containers along with Kubernetes.

CoreOS® has received $20 million in funding with $12 million

coming from Google® Ventures and a combined $8 million from

various other ventures.

Shippable® helps companies ship software faster by giving

them a virtual build, test, and deployment environment in the

cloud. It provides a continuous integration platform built natively

on Docker®. They recently received $8 million in funding in

addition to a previously received $2 million.

Zett® has developed the Weave project, focusing on Docker®’s

network issue by providing Docker® containers with a single

virtual network even when they are in different hosts. Existing

internal systems can also be exposed to application containers

irrespective of their location. Zett® has received $5 million in

funding from Accel® Partners.

Mesosphere®, whose founders are from Twitter® and Airbnb®,

has built a data center OS (DCOS) which functions as an

operating system that spans all servers in a physical or cloud-

based data center and runs on top of any Linux distribution.

They received $36 million in funding headed by Khosla®

ventures, proving that even an old company riding the Docker®

wave can make the company appealing to investors.

figure 15 - partner map

VMWare® is partnering with Docker® to ensure

Docker® containers work from the vSphere to

vCloud air using VMWare products and to ensure

interoperability of Docker® images with vCenter,

vCloud automation center and vCloud air.

VMWare® has developed a mutually beneficial

partnership with Google® that allows support of

Kubernetes from inside VMWare products.

Google® plans on replicating the pod based

networking model of open vSwitch to enable

multi-cloud integration.

VMWare®, Pivotal® and Docker® will all work

together in enhancing the libcontainer project with

capabilities from warden.

Red Hat® is working on project atomic, where the

focus is on re-architecting its own operating

system for the container world.

Red Hat® announced a partnership with Docker®

and intends to use Docker® containers to replace

its own, working together to ensure native support

for Docker®.

Red Hat® partnered with Google® Kubernetes for

integrating Kubernetes into OpenShift.

Red Hat® GearD converts application sources to

Docker® images while OpenShift broker will act

as the glue between OpenShift and GearD.

Microsoft® re-architected its operating system to

come up with a nano server for the container

world.

Microsoft® partnered with Docker® to ensure that

Docker® containers can work in Azure® hosted

Linux machines.

Microsoft® is working with Docker® to have

containers in Windows® as well.

IBM® partnered with Docker® to announce an

integrated solution called Docker® Hub Enterprise

(DHE).

IBM® is working with Docker® to ensure

containers are supported in IBM®s cloud.

IBM® sees an opportunity to support hybrid cloud

to its enterprise customers using containers.

Challenges to enterprise adoption

Server virtualization laid the groundwork for adoption of a new computing

architecture that allowed the creation of multiple virtual machines and helped

consolidate infrastructure resources (servers, storage and network) into a shared

pool. On the other hand, containers, by abstracting applications from VMs to run on

a common OS layer, have recently gathered steam due to their ability to consolidate

the resources even further and thereby increasing both the CAPEX and OPEX

savings.

Even though containers can reduce cost, enterprise adoption is still in the early

stages. According to a survey done by StackEngine® it was found that security and

lack of operational tools are major challenges for enterprise adoption.

Security

Security is one of the top most priorities for any enterprise when selecting newer

technologies, especially when the technology is only two

years old. There are several areas of concern when

planning to deploy containers, for instance: change

control, asset tracking and management, patch

management and configuration management. All these

concerns tie back into security and how people are trained

with respect to handling different processes. Docker®

containers are built upon the Linux container (LXC) that is

not designed to provide security, therefore security related

issues must be addressed outside of Docker®. As a result, the ecosystem is

evolving to provide the required governance and ensure that containers work in a

real multi-tenant environment.

Operational Tools

In the shipping analogy mentioned before, it took several years before the entire

cargo travel industry had transitioned to standard shipping

containers for the transportation of goods. This is because

changes were needed for ships, ports, cranes, trucks,

and forklifts to accommodate the new standard

container. One can extend this analogy further to

application containers and also see that it is going

to take some time for the ecosystem to evolve in a

way that will allow enterprises to feel comfortable

using containers. Docker® containers are good at packaging an application so that

the application can run anywhere, but it is not meant for managing the lifecycle of

the containers at scale. Container Lifecycle management, capacity management,

performance management, cluster management, configuration management and

governance are some of the tools that are evolving with the help of a vendor

ecosystem. Service discovery is another field that is gaining attention with the

emergence of Docker®.

Conclusion

With containers changing the way applications can be transported there will be less

worrying about underlying infrastructure related dependencies, revolutionizing an

application delivery process that had remained stagnant the last few decades. Yet,

even though containers are solving the application delivery process, they do not

possess the same level of security as virtual machines. As a result, virtual machines

compliment containers by providing them with their required isolation. Over the next

few years both virtual machines and containers will co-exist before containers can

be used in a standalone fashion by enterprises. While Docker® is leading the

container race, CoreOS® is the only main competitor with their container

technology, Rocket®.

Want to learn more?

We can organize targeted briefings with our subject matter experts

at Orange Silicon Valley.

Contact your Orange Business Services account manager.

Copyright © Orange Business Services [2015]. All rights reserved. The information contained within this document is the property of the

Orange Group and its affiliates and subsidiary companies trading as Orange Business Services. Orange, the Orange logo, Orange Business

Services and product and service names are trademarks of Orange Brand Services Limited. All other trademarks are the property of their

respective owners. This publication provides outline information only. Product information, including specifications, is subject to change

without prior notice.

[white paper] are containers the future ?

Technology