1. The document discusses strategies for transitioning an existing system to microservices, containers, and cloud native technologies like Kubernetes over time rather than doing a complete rewrite. 2. It recommends using a "strangler" pattern to slowly subsume the legacy application by writing new features in the new framework and replacing parts of the existing system gradually. 3. Challenges discussed include underestimating the existing system, moving too fast, dealing with changes to tools and processes, and ensuring developers and operations teams have the right skills for the transition.

1. How to eat a Whale? One byte at a
time…
Gettingsoftwaretoabetterplace
— Some Ideas and scar tissue
— Technology Problem
— Educational Problem
— Organizational Problem
1

2. Overall Situation:
— We have an existing system that works but needs new capabilities
— We want to move to Microservices/Containers,Comprehensive
Monitoring,Service Discovery,and Advanced Orchestration
— Need to get to stateless and immutable services
— We don't have time or are scared shitless of a rewrite
(for good reason)
2

3. Potentially Fatal Mistakes
— Underestimating what you have
— Trying to deliver too much at once
— Be Agile even if you weren't
originally
— Not thinking about code,state,and
data together
— Transient technology choices
— Run before walking-complexity
— You get better over time,plan for it
3

4. The “Strangler” Pattern
https://www.martinfowler.com/bliki/
StranglerApplication.html
— A less risky path to modernization by
slowly subsuming a legacy application
— I'm always surprised at how quickly
things move once the ball is rolling
4

5. Strangler in Action
5

6. First Steps:
1. Find a way to run old and new together
— And talk to each other…
2. Write new features in the new
framework
3. Pick stuff to change or replace
4. Put new tools in the context of existing
tools
6

7. A cloud for software not designed for the cloud
— VMware,Solaris (ZFS),Linux
Infrastructure
— Ruby,Python,...
— 50 Developers,12 Ops,11 geographical
regions and growing
— Decision to move (over time) to Docker
Containers and Kubernetes
— Probably 35-45% there now with the
trends clear
7

8. Technology Problem: Dealing with
technical change
— Developers don't like tools to change
— Release management process is
usually built into technical tools you're
already using
— Kube-native vs traditional CI/CD
— Fits new deployment paradigm
exactly
— Require re-education
— Hides complexity
8

9. Skytap CI/CD and Kube
— Started in 2015,at the time there were almost no native kube CI/CD
tools
— We deploy ~ 150 third-party and in-house services on ~ 800 machines
running in 11 georgraphical regions
— We have custom CI/CD tools built on top of Capistrano and Jenkins
— We always did source deployment without artifact generation,we'd
just update source to certain tag
— We went with integrating kubernetes with our existing CI/CD
framework
9

10. Our experience
— All new services since end of 2015 are
running on kubernetes
— All in-house high churn services
converted to kubernetes by now
— We spent around around 1.5
developer/years to adapt kubernetes in
our existing CI/CD
— We didn't have to change our release
process and it looks the same for both
engineers,QA and Operations
10

11. Testability of conversion
— Deployment tools and deployments
themselves are usually hardest to test
— If you have shared test or
preproduction environment and your
deployment failed,you can't get"clean"
reproduction on the same
environment
— Skytap built tool that nightly creates
test/preprod environments from
scratch
— We were able to release our
kubernetes conversion changes early
11

12. Educational problem
— Containers are still new enough that
pushback from core engineers can turn
company against them
— Good education and support for
developers would guarantee smooth
transition
— Retaining CI/CD tools can save bunch
of time regarding re-educating
developers
— New paradigms are still introduced
— Dedicated Slack channel for
12

13. Skytap experience
— Developers directly responsible for image generation,before they
split os image and dependency management with operations team
— Major areas Skytap Tools team had to teach developers were:
— Dependency management,pinning third-party dependencies to
exact versions during build
— Dockerfile syntax and caching of images for faster builds
— Implementing readiness and liveliness health checks for
kubernetes
— Estimating resource usage and setting correct requests and limits
13

14. Organizational problem
— Major challenge is creating a team that
can drive kubernetes changes
— Perfect team members would have:
1. Technical ability to understand
kubernetes internals
2. Architectural knowledge
understand existing release
management and deployment
practices and rationale
— Team should be driven enough not to
give up
14

15. Results
— At this point all the kubernetes enablement is mostly done
— Teams are moving to kubernetes at their own pace
— 2 people on the team consult rest of organization full time
15