Please enable JavaScript.
Coggle requires JavaScript to display documents.
Containerization Strategy (Application Migration Plan: migration plan to…
Containerization Strategy
Feedback from companies / Insights
Feedback from Paypal
Shortly jump to important apps, champion apps
Gives credit for investing more in future on the remaining apps
Metlife follow the same process
Starting with apps which nobody cares
Containerization driven by simplicity and the ability of "works here, works everywhere"
Updates on base image are easier and more manageable (e.g. kernel updates), and allow improvements in the remaining stack product without changing code
Started with 10-12 people
Feedback from Splunk
Containerization started by being used in the QA platform
Started with team of 10, and remain of similar size.
Wish had embracing ops team more soon, since they are key part of the success
Feedback from Metlife
Containerization drived by cost reduction
Ability to unsubscribe several systems
Running more on less
65%-75% reduction on infrastructure cost
Ability to scale up and scale down is crucial for cost reduction, since many periods of time, we don't need all the resources.
Dashboarding is very interesting for business people (splunk, grafana)
Dynamically seeing monitoring (nodes states, real throughput/latencies, etc.)
Training program for operation guys
"War games"
Working together with ops team to improve the process
In one week, team would inflict several different failures and analyse how ops team respond
Random times period of the day, container failures, mongodb went down, DB fill up, worker shut down, master node shut down, shutting down entire fault domains
Process would be iterated and response/recovery time will improve everyday
Much more value than training, since its real practice and they touched in every single part of the product. Made them hands on.
Is realistic, fun and very productive
Last tests on Friday are complete mad, with chaotic failure scenarios
Measures from failure to resolution
Personal note: I believe is a similar approach of Chaos Engineering, famous technique on netflix
Original team was 10 people. Current team is less than 8 people.
Business Case
Develop a scorecard based on application criteria important to you
Build a Return of Investment Use Case
Consider not only technical topics, e.g. team culture
Score each app with the scorecard, to understand what need to be containered
Define the different levels where ROI is lower or higher
Define the criterias important for you
Why?
Agility
Go to Market faster
OpEx
Everything faster, like deployment or tests
CapEx
More efficient, is proved that saves money
Production at Scale
Services Classes
Mission Critical
Support is given, 24/7
Highest levels of availability, performance and security
For mission critical applications, if they go down is really bad
Production
Support is given
Secure
Environments with high performance, HD, secure
For internal applications
Development
Shared infrastructure between development teams
Testing included
CI/CD pipelined included
Multi-Tenant centralized environment
Sandbox
No backups or HA
Self-Service
Environment with low performance and limited features
Good for training, discovery, POCs
Enterprise Organization
Cluster as a Service
Approach usually chosen for production
Container as a Service
Sometimes applied on Dev Cluster
First Applications in Production
Deployment methodology
:four: Go live
:three: Four workstreams
Docker Container Platform Service
Pipeline
Scan images, signed images, promote them all the way out to production
Guarantee a secured supply chain
CI/CD pipeline
Platform
Deploying, guarantee HA, disaster recovery, integrated with your infrastructure
Ops people
Governance
Marketing
T-shirt. stickers
Champion programs
Evangelize within the company, technology workshops
Flyers, docker days (sharing experiences, gains, pains, etc.)
Enforce adoption, by default they will not occur
Support
Level 3: Docker Support
Level 2: Internal Support
Level 1: Knowledge base portal
Operating Model
When you have a lot of applications, you can automate the process of dockerization and deployment
End of life applications can still be handled by Devops/Ops team, independently
Ownership of teams, from siloed to devops mindset
Steps
Code
Dockerize
Deploy
Run
Training
Culture change: pets vs cattle
New pattern: Bring new container, offline/kill the old one, RCA on what happened, new image with fix, deploy new image
Old pattern: debug the app inside the app, patch the container
Docker courses: 100 level, 200 level and 300 level
Usually takes a lot of time
Involves support, training, service level agreements, operating models, marketing and knowledge base
Everything that is non-technical
Applications
After the first app deploy, you just need to execute the Applications workstream
Deploying using the platform and operating model
Docker Compose files
Dockerizating apps
:two: Assessment
Optional: some core training for the team
Choose a pilot application
Measure the maturity levels of customer teams
:one: Proof of Concept
Just to validate that apps can be containerized
Throw away infrasctructure
Application Migration Plan:
migration plan to onboard all apps
General Availability
Available to everybody
All tech staks and all business lines
Phase 2 Applications
Distributed teams
Additional tech stacks
Strategy business lines
Phase 1 Applications
Local teams
Easy to support in case anything goes wrong
Stable tech stacks
Priority applications and with Highest ROI
Based also on the score cards
First Applications in Production
Service Governance Fully Established
First Apps in Prod
Plan (summary)
Build the business case
Innovate
Refactoring with containerization is easier
With ROI of containerization (money) invest in innovation, like microservices (go to cloud strategy), big data, serverless, IoT, etc.
Production at Scale
Give support, training, service level agreements, operating models
Start with one (or a small number) application only
Containerization of apps even on on-premises (on cloud is easier)
