AirJD 焦点
AirJD

没有录音文件
00:00/00:00
加收藏

Container as a Service with Docker(容器即服务) by Patrick Chanezon

发布者 docker
发布于 1458175872614  浏览 2891 关键词 微服务, Docker, English 
分享到

第1页

Container as a Service with Docker
Patrick Chanezon, Docker Inc.
@chanezon

第2页

French
Polyglot
Platforms
Software Plumber
San Francisco
Developer Relations
@chanezon

第3页

1995
2015

第4页

“The future is already here — it's just not very evenly distributed”
William Gibson, Neuromancer

第5页

Docker’s mission is to
build tools of mass innovation

第6页

Programmers

第7页

Programmers
a software layer to program the internet

第8页

5
Cloud Market
Public
Hybrid
Private
IT Pros
Devops
Developers
Architects

第9页

Linux Container Ecosystem

第10页

The Docker mission
Build
Ship
Run
Anywhere
Distributed Applications
10
The Docker mission is enable organizations to build, ship and run distributed applications anywhere.

第11页

5
XaaS Pyramid
Platform As A Service
Infrastructure As A Service
Software
As A Service

第12页

第13页

第14页

5
Goldilocks and the 3 XaaS
Just right
Too high
Too low
IaaS
PaaS
CaaS

第15页

5
Goldilocks and the 3 XaaS
Platform As A Service
Infrastructure As A Service
Software
As A Service
Too high
Too low
Just right
Container As A Service

第16页

5
Goldilocks and the 3 XaaS
Container As A Service
Infrastructure As A Service
Software
As A Service

第17页

Docker Containers as a Service (CaaS)
An IT managed and secure application content and infrastructure where developers can self service build and deploy applications

第18页

The Docker Journey: The Power of AND 
18
Leading to the Docker Journey – What we have learned from the millions of developers that have already traveled this journey is that 

The promise of agility (speed and flexibility) drew them to Docker, with how quickly they could setup their development environments to the realization that these new containers were now portable to any environment like never before.  
These two things are what made Docker hugely successful in the developer community with the CI use case. 

But CI only realizes half of the potential value of Docker because the app pipeline just switches back to a “waterfall” or “over the wall” at deployment. In order for the much loved developer platform to gain widespread adoption in an organization, the right management construct was required.

To provide this much needed control, platforms (PaaS) and bundled solutions (i.e. Tectonic) emerged in an attempt to complete the journey but their approach ends up sacrificing portability and agility for the user.  

Thousands of Docker users chose to not adopt those solutions and instead built it themselves with glue code and bash scripts because they didn’t want to forego the agility and portability that drew them to Docker in the first place.  Just a simple search on Github for ‘Docker’ will show the ecosystem of tools written by users and shared with the community

So, where do we go from here?

第19页

Lessons learned: Avoid these pitfalls
Developers don’t adopt locked down systems
Existing “end to end” solutions break the Docker experience
Beware of lock-in and loss of portability
19
To do that, we can accelerate our path by learning from those who have traveled this path before and avoid common pitfalls when investigating solutions.

An environment that is too locked down becomes a hassle for developers and adoption will suffer.  Shadow IT behavior will emerge and developers will start creating new tools and processes to be able to use the languages they need and complete their work.
EXAMPLE:  BBC News had a locked down CI environment that did not include the tooling needed by many of the developers so the team created a side process to use the languages they needed.  That not only went outside the official systems but then added a few days to each CI job.

2) Many of the existing solutions on the market are either too opinionated of a PaaS or are cobbled together solutions with a number of different products.  These solutions can be difficult to deploy and manage over time.  More specifically, many of them support the Docker format or take the Docker code and customize it for their solution environment.  This can break not only the developer experience but also the ops side of the experience because they only supporting parts of the Docker API – so the user will not experience the desired behavior in all situations.  This also breaks the ecosystem because the hundreds of partners building to the API may have compatibility issues against these solutions.

3) Portability is a default requirement for distributed applications.  As the content creator, you must retain control of where that app lives and your ability to move it from environment to environment, to a different team and to different infrastructure providers.  

Other pitfalls…
Developers will run entire application lifecycle outside of infra ops (shadow IT)
Infrastructure-centric “container solutions” break developer experience
Organizational finger-pointing is compounded because of stifled productivity
Legacy applications get overlooked

Gilt also shares the example where emphasizing control lead to a “cycle of suck” where they were taking longer to ship and with less innovation

第20页

The Docker CaaS Platform
20
BUILD
SHIP
RUN
Docker Toolbox
Docker Trusted Registry 
Docker UCP
Docker Hub
Docker Tutum

第21页

Developers
IT Operations
BUILD
Developer Workflows
SHIP
Secure Content & Collaboration
RUN
Deploy, Manage, Scale
Docker CaaS Platform
Local development environments 
Self service app images
Build, Test, Deploy applications
Define app behavior and infra needs

Registry services for image storage,  management and distribution
IT Ops maintains library of secure base content
Manage role based access to repos/images

Management consoles
Provision, manage  infrastructure resources
Monitor, manage, scale infrastructure and applications

第22页

Docker Containers as a Service platform
22
BUILD
Developer Workflows
SHIP
Registry Services
RUN
Management
Docker Toolbox
Docker Trusted Registry 
Docker Universal Control Plane
Docker Hub
Tutum
Docker Engine

第23页

Characteristics of a CaaS: The Power of AND 
23
Docker is the only solution to give you agility, control and portability for all your distributed apps.  The right choice in helping transform your business into an agile business.

The platform is the only commercially supported Docker solution available on the market today.  Other vendors who state they support Docker is not actually providing technical support and maintenance into the Docker product code.  Docker is the only commercial yet open platform that gives you the operational flexibility you need.

And unlike other solutions, Docker is…
Language agnostic: C, Java, Phython, PHP, Go….
Infrastructure agnostic:  on-prem, cloud, virtual, bare metal
All stages: from dev to test to release engineering to production
Any OS:  Linux, Windows, Solaris

Docker enables agile distributed applications in production to create agile companies

第24页

Docker CaaS enables key initiatives
24
So these 

第25页

Use Case: Decentralized CaaS for hybrid and multi cloud portability
Private datacenter for regulated apps
Provision resources
RBAC to VPC / datacenter
Trusted Registry hosted application templates
Cloud for all other apps
VPC 1
VPC2
Cloud 
Portability
App Portability
This leading phahas a hybrid cloud environment and would like to have a portal to completely abstract away the infrastructure details from their app teams.  This way in the portal they request compute resources.  Depending on if the app is regulated or not, the actual provisioning and deployment will happen to either an AWS VPC or their private datacenter.  In addition to the portal, J&J would like to add a central IT managed marketplace to get app templates and images to help the teams get started.  Once provisioned, the actual deployment and ongoing management is de-centralized and owned by the application teams.

Use Cases
 - Developer self service
 - Hybrid cloud portability
 - Multi cloud environment

Why Docker?
App portability is a MUST.  Over time they want the option to move the DC apps to cthe cloud as regulations change.  Additionally they have already added Azure to their environment and would like to be able to move apps to the new clouds.

第26页

Use Case: Centralized CaaS for transformation to DevOps and micro services
App Teams
Universal Control Plane
Portability 
ADP operates in a more traditional centralized IT model where IT manages and operates the application and environment ongoing.  ADP looked at Docker as they began their transition to DevOps.  They were interested in gaining more efficiencies and re-use of code by moving to a shared services model instead of monoliths with a lot of repeat services.  ADP has OpenStack for their private cloud and AWS for their public cloud.  As part of the transition, ADP would will setup a central marketplace where the shared services apps are available for the app teams.  In the ADP example both the environment and ongoing management remains centralized.

Use Cases
 - Transition to Micro services
 - Enable Dev Ops
 - CI/CD

Why Docker?
Need app portability so they can choose to move across AWS / Openstack

第27页

支持文件格式:*.ppt, *.pptx, *.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。