Docker & Apcera Better Together

Editor's Notes

• #4: No more heavy hardware emulation because containers rest on top of a single Linux instance Leave behind the useless 99.9% VM junk, leaving you with a small, neat capsule containing your application Twice as many containers can run on the same hardware Run virtually anywhere - from your laptop to the cloud 1. containers are much lighter-weight vs virtual machines - Each VM on a server contains an entire operating system. That OS will contain all sorts of drivers, utilities, libraries, maybe some runtimes, etc (in addition to the kernel). This translates to lots of large images and as such they consume more disk space, RAM and CPU. With containers, all the containers on a server use the same (very much slimmed down) kernel. Essentially you go from lots of independent, fat operating systems running on a machine, to one very slim kernel that is shared and provides basic services to all containers. This leaves a lot more of a server’s disk, RAM and CPU for running applications - which means many more applications per server using containers vs using VMs. Whereas you may have 10s of VMs on a server you can have 100s of containers. dramatic increase in server utilization. 2. because containers are so light weight they boot much faster than VMs. Apps can be spun up in fractions of a second vs seconds. 3. containers by definition contain the app and all its dependencies (required libraries, runtimes, etc.). This means that (other than the very basic operations that the shared kernel provides) the container contains the app and everything it needs to run. This is very useful as it solves a common problem in the development world. Often when apps move from dev to test (for example) they won’t run properly in the new (test) environment. often after much unfruitful troubleshooting of the app the problem is reported to the developer and he checks the app only to find it’s running perfectly in his development environment. So the problem is the difference between the dev and test environments. A lot of time is wasted trying to (a) keep environments in sync with various patches, updates, libraries, etc. and (b) troubleshooting problems when the environments invariably get out of sync. Big win for containers wrt reducing wasted time and frustration. 4. because an app running in a container has only what it needs to run, its attack surface is much much smaller. In other words all that extra OS code that gets carried around in VMs not only eats CPU, disk and RAM, but it also increases the the possibility of an exploit. the more code you have the greater the possibility that some of it can be exploited. Not only does this increase risk, but also maintenance since someone has to patch all those pieces of code where exploits are found. Bottom line, containers provide many significant benefits vs VMs. This is why Google has been using them for a decade.
• #5: High level overview today and the future
• #6: Today, when a new application is placed in production, a networking team needs to select the appropriate VLAN, open ports, configure load balancing, set up port security through access control lists (ACLs) Containers on routers, switches, load labancers, embedded systems, etc. Free movement of containers and CI/CD into different clouds, but with enterprise-class controls. Companies requiring enterprise-grade reliability and security for all the technologies inside a container as well as the container host environment. Small-footprint operating system Containers as new software delivery model for enterprise applications and hardware Need for a specification for containers Multiple containers topology
• #8: Apcera covers the full solution as a policy governed enterprise offering feature ranging from PaaS, integration with services and hybrid cloud capabilities. 1. Cluster management 2. Container scheduling 3. Container orchestration 4. Policy definition and enforcement 5. Multicloud runtimes - ability to span multiple clouds - with consistent policy across all clouds 6. Workload diversity - ability to run containers, non-containerized workloads and VMs together on same infra. We provide all of the above. The first 3 are provided by lots of others, Mesos, Kubernetes, etc. However, we have unique differentiation with respect to the last 3. Nobody has as complete a policy story as we do, nor can they claim consistent policy across multicloud environments - and I’m not aware of anyone that can run all the workloads we can. Apcera is dedicated to contribute to the Open Source community which innovates in container technologies and sometimes competes Kurma/KurmaOS Orchestration Higher level of abstraction, enables micro-services architecture, repeatable and automatable deployments and software management related to updates/upgrades Usually involves standards (manifests) for describing the application (multiple jobs) Scheduling Features as resource management, cluster management, health monitoring and scaling of workloads (containers) Container engine Container engine allows you to run your containers in isolated context (allocated CPU, RAM, disk, networking) Typically libraries and tooling around Linux kernel features cgroups and namespaces Storage and networking as well as multi-tenancy and isolation capabilities of the engine Operating system is usually integral part of the engine
• #13: Our Docker policy is based upon image tags, which are not strong assertions about an image's contents. By partnering with FlawCheck we can show Continuum using Staging Pipelines to inspect Docker containers for malware and vulnerabilities that could put an organization at risk.