Contenu connexe Similaire à Fast Tracking Dev Teams to Container Adoption (20) Fast Tracking Dev Teams to Container Adoption1. © 2017 IBM Corporation
IBM Hybrid Cloud - DBA
Fast Tracking Dev Teams to
Container Adoption
Marc Velasco
Senior Software Engineer
IBM
2. © 2 0 1 7 IB M C o rp o ra tio n
Motivation
/Goals
Development organization has to support
a large number of clients using a
substational set of product versions
Simplify deployment for all cloud
environments
• IBM Cloud, IBM Cloud Private, AWS, Azure, etc.
Provide scalable, manageable, upgradeable
and maintainable platformfor both on-
premise and cloud environments (public
and private)
Improve profitability of the ECMCloud
Offering by reducing infrastructure costs
and labor costs (maintenance, support, etc.)
• Simplify devops team tools and operations
Reduce turnaround time of providing
customer access to ECMCloud
Environments
3. © 2 0 1 7 IB M C o rp o ra tio n
Development
Approach
Squad approach to
containerization
•Product was
already sold and
developed under a
number of separate
teams
•This allowed
existing teams to
continue their
development
structures but form
a new squad that
could performthe
containerization
work
•“Container” team
can collaborate with
separate teams to
work on
containerization
issues,
recommendations
•This ”Container”
teamcan reach
economy of scale
benefits by
containerizing
additional products
as they become
available
”Legacy Application”
teams
•Application squad,
the traditional on-
premteamstill
developing their
application
•Target a liberty
server, using a
common platformin
their development
and initial testing
•Insulated from
container build
particulars
•Works with
container build
teamon required
features and
configuration
needed for the
container
•Can continue their
individual build
processes
•Already has in
place an existing
build and smoke
test structure
•Output: application
ear/war, run time
files
“Container” Team
•Build base images
for containers with
prereqs needed by
all containers
•Build containers for
each individual
product/service
•Continuous
integration
•Test automation –
run “legacy” team’s
build and smoke
tests to verify
containers
4. © 2 0 1 7 IB M C o rp o ra tio n
Best laid
plans
Initial Containerization
qGetting the base and initial configuration right
• Identify preferequisite tooling needed like logging,
metrics, make it common across all containers
qDefining the required storage volumes
qIdentifying the environment variables exposed
Initial Containerization
Container Development Mindshift
qTroubleshooting a container in general
• The assumption of being able to ssh to a container
or easily get files from it
• The inability to persist state in a container
qPerformance characterization
• Sizing, and performance testing, how to measure if
there’s an “overhead” for container performance
qTesting
• Reusing Legacy tests ended up being problematic,
ran for several hours and didn’t have the ability to
select just a few critical cases to run after container
creation
• Mind shift was needed not just in the application
and containerization but in the testing as well
5. © 2 0 1 7 IB M C o rp o ra tio n
Comparison to Traditional Applications
6. © 2 0 1 7 IB M C o rp o ra tio n
Where we’re at
now
• Success for the first four containers
• Three months later
• Two more platforms and a new
configurator container for
Kubernetes deployment
• 30 containers
• Kubernetes deployment
• 8 development teams in 4
Geos
7. © 2 0 1 7 IB M C o rp o ra tio n
Q&A