OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
Future of Cloud Computing with Containers
1. Future of Cloud Computing with
Containers
Lakmal Warusawithana
Lakmal Warusawithana
Senior Director - Cloud Architecture, WSO2 Inc
lakmal@apache.org / lakmal@wso2.com
Twitter : lakwarus
16th September 2017
2. Agenda
Lakmal Warusawithana
● Compare VM and Containers
● Introduction to Docker
● Does Container a Paradigm Shift?
○ Rapid start ( < 1-2 seconds)
○ No more config-over-code
○ Microservices and birth of the “single function server”
○ No more garbage collection?
○ Immutable
○ DevOps
● Demo - CICD with OpenShift
26. *
Docker Component - Filesystem
● boot file system (bootfs)
○ The boot file system contains the bootloader and the
kernel. The user never makes any changes to the boot file
system
● root file system (rootfs)
○ The root file system includes the typical directory structure
we associate with Unix-like operating systems
Introduction to Docker
27. *
Docker Component - Filesystem
● In a traditional Linux boot, the kernel first mounts the rootfs
as read-only, checks its integrity, and then switches the
whole rootfs volume to read-write mode.
● Docker mounts the rootfs, instead of changing the file system
to read-write mode, it takes advantage of a union mount to
add a read-write file system over the read-only file system
● In Docker terminology, a read-only layer is called an image.
An image never changes.
Introduction to Docker
28. *
Docker Component - Filesystem
● Each image may depend on one more image which forms
the layer beneath it. We sometimes say that the lower image
is the parent of the upper image
● An image that has no parent is a base image.
Introduction to Docker
29. *
Docker Component - Container
● Once you start a process in Docker from an Image, Docker
fetches the image and its Parent Image, and repeats the
process until it reaches the Base Image. Then the Union File
System adds a read-write layer on top.
● That read-write layer, plus the information about its Parent
Image and some additional information like its unique id,
networking configuration, and resource limits is called a
container
Introduction to Docker
30. *
Docker Component - Container
● Containers can change, and so they have state. A container
may be running or exited. When a container is running, the
idea of a “container” also includes a tree of processes
running on the CPU, isolated from the other processes
running on the host
● When the container is exited, the state of the file system and
its exit value is preserved. You can start, stop, and restart a
container. The processes restart from scratch (their memory
state is not preserved in a container), but the file system is
just as it was when the container was stopped.
● You can promote a container to an Image with docker
commit. Once a container is an image, you can use it as a
parent for new containers.
Introduction to Docker
32. *
● Containers can start within milliseconds. If microservice can
start in milliseconds, full service could start within seconds
with infrastructure.
● Scale fast
● Can Container start in the first request call? And do the
tasks, completed and exist. Short lifetime.
● Do we need up and running server any more?
● Serverless Architecture. Amazon Lambda and Google
Function
Rapid start ( < 1-2 seconds)
Containers — A Paradigm Shift
33. *
● Last 20 years has been advocating config-over-code.
● With container and micro services that’s mostly going. Apps
can redeploy a bit of code as much as you can redeploy
config. Config values can be read from environment
variables.
● Why does this matter?
○ Configuration increases the complexity of the code.
○ It’s one more thing for someone working on the code to
understand.
No more config-over-code
Containers — A Paradigm Shift
34. *
● Microservices advocates that a service should perform
exactly one function.
● Single functions lead no deployment concept. No need to
have “context”.
● No artifact deployment concept. Artifacts are burnt to docker
images.
● Can get more controllability. Can control memory and CPU
cycles taken to each and every function by using containers.
● Container overhead is nothing compared to VM. Single
function in single container is now practical than theorizing.
Microservices and the birth of the
“single function server”
Containers — A Paradigm Shift
35. *
● Early days when we are writing a C program we had used
alloc and malloc very carefully otherwise it will lead to
runtime memory leaks.
● JAVA introduced garbage collection and it's helped
developers to reduce memory leaks.
● Does things different with the containers?
No garbage collection?
Containers — A Paradigm Shift
36. *
● When we are running an application inside a container we
can set maximum memory and CPU allowed to use.
● When it hit the max, container will be destroyed and a fresh
container will start by auto healing system.
● What does it mean?
○ Can we pass memory management to container level? I
will open it you to think. :)
No garbage collection...
Containers — A Paradigm Shift
37. *
● Immutable nature of containers are useful in production
deployment.
● Never upgrade your container. Never update your code.
Instead create a new container and throw away the old one!
● Rollback is always by bring back the old container.
● No incremental updates.
● Use BLUE/GREEN or Canary updates
● Kubernetes, Docker Swarm, DC/OS are some Container
Management Softwares to help large scale immutable
container deployments.
Immutable
Containers — A Paradigm Shift
38. *
● In normal app development only application artifacts are
bundled to application delivery pack (downloadable zip etc).
● Then apps in later stages in delivery pipeline will have wide
range of variation, depending on the runtime and the specific
operating environment of the deployment environment.
● But with container, a developer can be bundled the actual
infrastructure (i.e. the base OS, middleware, runtime and the
application) in the same container image.
● Having same environment in development and production
helps to end the famous war between developer/QA/Ops in
the software development life cycle. Result is significantly
increased the velocity.
DevOps
Containers — A Paradigm Shift